Sybase Adaptive Server IQ 12.4.2, Administration And Performance Manual

Page: 328 / 536

Checkpoints, savepoints, and transaction rollback
308
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
-gm
parameter,
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.