What to do when you receive an assertion failed message:
- Record the assertion number and message that appear in the database server messages window or log file. The assertion number and message are important in attempting to determine the cause of the assertion.
- If a pre-SQL Anywhere 16 database server has asserted, shut down the database server, if it is still running. This is very important if multiple databases are running on a single database server. This action protects the other databases running on the database server from potential corruption.
- Make a backup copy of the database file and transaction log. You should also make a backup copy of any old transaction logs that have yet to be deleted. The backup copies of these files should be completed with a straight file-to-file copy (do not use dbbackup or another backup procedure). Old backup copies of the database file and transaction logs should not be overwritten. It is important to maintain the database file and transaction log in the state immediately after the assertion failure for both recovery and root cause analysis purposes.
- Attempt to restart the database server with the database file, as usual.
- If the database starts successfully, validate the database using the Validation utility (dbvalid) or the sa_validate system procedure or the VALIDATE DATABASE statement.
- If the validation reports errors or another assertion failure occurs, then it is possible that the database file is corrupt. In this scenario, the best course of action is to resort to use your database recovery process of your tested backup and recovery strategy (see below). Retain copies of the corrupted database files if you wish to submit the files to SAP Support for a later root-cause analysis of possible sources for the assertion.
- If the validation completes successfully and reports no errors, then the database can be put back into production. If subsequent assertion failures occur, revert to your tested backup and recovery strategy. If you are still experiencing problems after reverting to your tested backup and recovery strategy, contact SAP Support.
- Even if the validation process does not return errors after validating a database, once an assertion condition has been hit, there is still potential for corruption of the database file during runtime. The only way to guarantee removal of all pre-existing corruptions in the database file is to rebuild the database using the unload/reload process. The ability to restart the database file on a database server alone does not guarantee that the database file is free from corruption. See: The rebuild process for SQL Anywhere 10 and later databases
If the database does not start correctly in step 5, use your database recovery strategy to recover from your most recent and viable database backup.
If there is no viable database backup available, then forcing the database to start without the transaction log is an option only if the database is not involved in replication or synchronization(e.g. is being used with MobiLink, SQL Remote, or Replication Server). To have the database start with a new transaction log, shut down the already running database, rename the old transaction log, and then restart the database using the command:
dbengX -f database.db
where ‘X‘ is 50, 6, 7, 8, 9, 10, 11, 12, or 16, depending on the major version of SQL Anywhere being used.
Normally, when the database server goes through automatic recovery it rolls the database file back to the previous checkpoint and then applies all transactions in the transaction log after that checkpoint. Using dbengX -f allows recovery to the last checkpoint without applying the transactions in the transaction log. This is only true if the transaction log is not present in the location where the database file expects the transaction log to be located. If the transaction log is present, then the database server attempts to apply the transactions in the log since the last checkpoint, regardless of whether -f was used on the database server command line. If you suspect that the transaction log is corrupt, then the transaction log must be renamed before using dbengX -f to ensure that the original transaction log does not get used.