An allocation map is used by the server to determine if a page is in use or not in use within IQ. Either through system failure or as a result of opening a database with forced recovery, a database's allocation map may not reflect the true allocation of its usage. When this occurs, we say that the database has “leaked” storage or “leaked blocks.” In general, you need not be concerned about small numbers of leaked blocks. If you have many megabytes of leaked blocks, you probably want to recover that space.
Sybase IQ IQ lets you recover leaked storage using the -iqdroplks server startup option in conjunction with the sp_iqcheckdb stored procedure. The -iqdroplks option allows sp_iqcheckdb to recover leaked storage space within the specified database.
When leaked storage is being recovered, other transactions that alter the allocation map are shut out. Such operations include checkpoints and commands that modify the database.
You can recover leaked storage and force recovery either at the same time or separately. To recover leaked space within a database without doing a forced recovery, follow the procedure in the section “Repairing allocation problems”. To recover leaked space within a database after doing a forced recovery, follow the procedure in the next section “Recovering leaked space using forced recovery”.
If the procedure in the section “Repairing allocation problems” fails to recover leaked storage, then use the following procedure to recover leaked storage.
To recover leaked space using forced recovery:
Start the server with the -iqdroplks and -iqfrec options
in the start_asiq command. For example:
start_asiq -n my_db_server -x 'tcpip{port=7934}'
-gd dba -iqdroplks my_db
-iqfrec my_db /work/database/my_db.db
You specify the database name twice in a row, once to specify it as the database you are starting, and once to specify it as the database undergoing forced recovery. Both the -iqfrec and -iqdroplks options require the database name.
Sybase strongly recommends that you start the IQ server with the -gd option set to restrict access to the server to the DBA. Forced recovery operates in all modes, but restricted access gives the DBA greater control over inadvertent opens of the database.
Connect to the database you are recovering.
Run the stored procedure sp_iqcheckdb in allocation mode:
sp_iqcheckdb 'allocation database'
If there are no errors and sp_iqcheckdb displays the message “Freelist Updated,” you have recovered leaked space and forced recovery. Continue to the next step.
If inconsistency is found, follow the instructions in the section “Dropping inconsistent indexes, tables, or columns” to drop inconsistent objects. Then run sp_iqcheckdb again to recover leaked space.
Issue a checkpoint.
Stop the server using your usual method.
Restart the server using your usual method, and proceed with normal processing.
