Forced recovery allows the server to start if the allocation map is inconsistent. In this mode, options display information about inconsistencies. You can also specify options to repair such inconsistencies.
Follow this procedure only if you see s_buf or free list errors during failure recovery. If SQL Anywhere recovery errors occur, -iqfrec will not correct the problem.
Restricting access gives the DBA greater control over inadvertent opens of the database during forced recovery. Sybase recommends using two server startup switches to restrict access:
Use -gd DBA so that only users with DBA authority can start and stop databases on a running server. (Note that the client must already have a connection to the server to start or stop the database, so this switch does not prevent connections.)
Use -gm 1 to allow a single connection plus one DBA connection above the limit so that a DBA can connect and drop others in an emergency.
An alternate way to restrict connections is to specify
sa_server_option('disable_connections', 'ON')
just after you start the connection where you are performing forced recovery and
sa_server_option('disable_connections', 'OFF')
on the same connection after recovery. The disadvantage is that this method precludes emergency access from another DBA connection.
Starting 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_iq command. For example:
start_iq -n my_server -x 'tcpip(port=7934}' -gd dba -gm 1 -iqfrec my_db /database/my_db.db
Forced recovery starts the server in single-node mode. Stop all secondary servers first.
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.
If desired, you can run sp_iqcheckdb to check for leaked blocks. For details, see “Analyzing allocation problems”.
Stop the server after it has started successfully. To stop the server, use stop_iq on UNIX or the shutdown button in the console window on Windows.
Restart the server using your usual method, without the -iqfrec option.
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 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.
See the section “Recovering leaked space” for details on using sp_iqcheckdb to reclaim lost or leaked space.
