If a server fails to start with an exception or an assert during the opening of the database, then the server should be started with forced recovery. Forced recovery allows the server to start and recovers the database, if the allocation map or checkpoint information is inconsistent.
Forced recovery should only be used when normal
database recovery fails to restore the database to a running state.
The -iqfrec server startup option is used to start the server in forced recovery mode. The database specified in the -iqfrec option is marked as in use and is restored to its last consistent state.
Forced database recovery differs from normal database recovery in these ways:
Forced recovery marks all storage within the database as in use. In order to recover a potentially inconsistent allocation map, all storage within the database is marked as in use. You can use the server startup option -iqdroplks with the sp_iqcheckdb stored procedure to reset the allocation map to the correct state. For more details, see the sections “Leaked space recovery” and “Recovering leaked space using forced recovery”.
Incremental backups are disabled. After the database is opened in forced recovery mode, incremental backups are disabled. The next backup must be a full backup. Doing a full backup reenables incremental backups.
The forced recovery parameter applies to all opens of the database while the server is up. Therefore, after the database is opened, the DBA needs to bring the server back down, and then restart the server without the forced recovery flag, to be sure that subsequent opens run in regular mode. Repeated opens of the database with forced recovery on do not harm the database, but could be confusing to the DBA. Each time you open the database in forced recovery mode, all the storage within the database is marked as in use.
If the server fails to start due to an allocation map or checkpoint problem, follow this procedure:
To start a server in forced recovery mode:
Start the server with forced recovery (to mark all pages as used), using the -iqfrec server startup option in the start_asiq command. For example:
start_asiq -n my_server -x 'tcpip(port=7934}' -gd dba -iqfrec my_db /database/my_db.db
WARNING! You must specify the override startup switch (-iqmpx_ov 1) and start in single node mode (-iqmpx_sn 1) when starting a multiplex write server after any failure. Never use multiplex mode (the default) for recovery.
You specify the database name twice, once to specify the database undergoing forced recovery and once to specify the database to start. The -iqfrec server startup option requires the database name. Note that this is the physical database name, which is case sensitive. Do not use select_dbname to determine the database name, as it returns the logical name assigned by the -n startup option.
Sybase strongly recommends that you start the IQ server with the -gd option set, to restrict server access to the DBA. Forced recovery operates in all modes, but restricted access gives the DBA greater control over inadvertent opens of the database.
Stop the server after it has started successfully. To stop the server, use stop_asiq on UNIX or the shutdown button in the console window on Windows.
Start the server with the drop leaks option -iqdroplks. See the section “Leaked space recovery” for more details.
start_asiq -n my_server -x "tcpip(port=2638)" -gd dba -iqdroplks my_db /database/my_db.db
Run sp_iqcheckdb in allocation mode to free up unallocated pages.
sp_iqcheckdb 'allocation database';
Stop the server after sp_iqcheckdb finishes.
Restart the server using your usual method, without the -iqfrec and -iqdroplks options.
If you are unable to start your server in forced recovery mode, contact Sybase Technical Support.
Running forced recovery starts the database in a valid, but fully allocated mode. In other words, you should be able to do all operations, but no permanent main dbspace is left. Before you do anything else, you must either recover the lost dbspace by running sp_iqcheckdb with the -iqdroplks flag, or add a new dbspace. Note that queries should also run successfully, since they do not need additional permanent dbspace; however, you cannot load, insert, or delete data.
WARNING! Running queries without verifying the database will not cause any inconsistency in your data. However, if there is a problem in the data that caused the server to fail, the server could fail again or produce incorrect results.
See the sections “Leaked space recovery” and “Recovering leaked space using forced recovery” for details on using sp_iqcheckdb to reclaim lost or leaked space.
