Sybase 12.4.2 Manuale Utente

Pagina di 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.