Checking Database Integrity Use the DBCC CHECKDB procedure to check for database errors. This procedure should be run on all databases at regular intervals to check for errors. Errors are common after hard failures of the database server. An SQL scheduled task should be set up to run and check for errors weekly, or this can be done using the database maintenance plan. The database administrator should set this up. The check should also be run manually each time there is a known hard failure of the system. the following example is a CHECKDB procedure: Use master DBCC CHECKDB ('Adventureworks') GO Note: These checks can take some time to run (especially for the object database, due to its size). Therefore, they can lock or block the database while running. They should be run at non-peak times to minimize performance impact. If CHECKDB reports errors, it is best to correct them immediately. All Tivoli(R) Business Systems Manager services and the SQL server agent should be down when repairing a corrupt database. Use the REPAIR_REBUILD option to minimize data loss when repairing the database. If there is database damage, and especially if a data loss repair option was used to correct it, note this in any future calls to IBM Software Support. Note: Using any DATA LOSS repair options can lead to other problems. This is not recommended. If data loss is required, the database should be restored from a backup made prior to the corruption, rather than repaired. This is an example of commands that can be used to repair errors in the object database. Before running this or a similar procedure, you should shut down all Tivoli Business Systems Manager services: PRINT 'check and repair Object database' exec sp_dboption 'Object',single,true DBCC CHECKDB ('Object',REPAIR_REBUILD) exec sp_dboption 'Object',single,false
