Starting a Server in Forced Recovery Mode

Forced recovery allows the server to start if the allocation map is inconsistent.

If you cannot start a server or database in a multiplex, forced recovery may be needed. Use forced recovery only when normal database recovery fails to restore the database to a running state, and only if you see s_buf or free list errors during recovery. Never use forced recovery in response to SQL Anywhere errors, such as SA transaction log replay failure.

If you have followed documented recovery procedures and SAP Sybase Technical Support recommends forced recovery, follow these steps:

Shut down all secondary nodes using stop_iq.

Start the server with the -iqfrec and -iqmpx_sn 1 flags:

start_iq -n my_server -x 'tcpip(port=7934}' 
-gd dba -gm 1 -iqmpx_sn 1 -iqfrec 
my_db /database/my_db.db

Connect to the server and run:

sp_iqcheckdb 'dropleaks database'
checkpoint

Correct errors and rerun sp_iqcheckdb. Repeat until no errors result.
Shut down and restart the server normally (without the flags in Step 2).

If you cannot start your server in forced recovery mode, contact SAP Sybase Technical Support.

Using Forced Recovery without a Follow On sp_iqcheckdb

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 in dropleaks mode, 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.