Sybase 12.4.2 manual How transaction information aids recovery, 308

Checkpoints, savepoints, and transaction rollback

During Adaptive Server IQ database recovery, any uncommitted transactions are rolled back, and any disk space used for old versions is returned to the pool of available space. At this point, the database contains only the most recently committed version of each permanent table.

During recovery from a system failure, Adaptive Server IQ reopens all connections that were active at the time of the failure. If the -gmparameter, which sets the number of user connections, was in effect at the time of the failure, you need to restart the IQ server with at least as many connections as were actually in use when the failure occurred. Temporary table contents are not recoverable.

If a failure occurs, try to restart the database server and database. If you have trouble starting a server or database, or if users are unable to connect to it, see Adaptive Server IQ Troubleshooting and Error Messages Guide for information on how to proceed. You will need information from your server log and IQ message log to recover.

Sybase recommends that you run the stored procedure sp_iqcheckdb after a system failure, preferably before allowing users to connect. This procedure checks every block in your database, and produces statistics that allow you to check the consistency and integrity of your database. For details, see Adaptive Server IQ Troubleshooting and Error Messages Guide.

How transaction information aids recovery

Adaptive Server IQ’s recovery mechanism is designed for the data warehouse. Typically in this environment, few transactions occur, but each transaction can be quite time consuming.

To best suit this model, Adaptive Server IQ performs database updates by making them on a copy of the actual database page, and then writes the data to disk whenever a write transaction commits. It also records the following information:

•The location and quantity of changed data for each transaction. It stores this information in a transaction log.

•The location of any version pages and free space on disk. It uses this information to free up space when versions are no longer needed. All versions created throughout the duration of a write transaction become obsolete when the write transaction commits or rolls back. Individual versions can be released at a savepoint.

308