Database file corruption may not be apparent until the database server tries to access the affected part of the database. As part of your data protection plan, you should periodically check that your database has no errors. You can do this by validating the database using tools such as the Validate Database Wizard in Sybase Central, or the Validation utility (dbvalid). You should validate your database both before and after you perform a backup. You must have VALIDATE authority to perform validation activities. See VALIDATE authority.

When you start a backup copy of a database to validate it, you can use the -ds database option to specify the location of dbspace files, as well as the transaction log. This allows you to start the backed up copy of the database on the same computer as the original database while the original database is still running. See -ds database option.

Depending on the options you specify, validation can include checksums, correctness of index data, and whether all table pages belong to objects in the database.

Validation requires exclusive access to the object being validated. For this reason, it is best to validate when there is no other activity on the database. Database validation does not validate data, continued row structure, or foreign key relationships if you perform an express validation using the -fx option.

If you can be sure that no transactions are in progress when the backup is being made, the database server does not need to perform the recovery steps. In this case, you can perform a validity check on the backup using the read-only database option. See -r server option.

If a base table in the database file is corrupt, you should treat the situation as a media failure, and recover from your previous backup. If an index is corrupt, you may want to unload the database without indexes, and reload.

See also

• Validating a database
• Validating a transaction log
• Validating a single table
• VALIDATE statement
• Improving performance when validating databases