User's Guide
   PART 4. Database Administration and Advanced Use
     CHAPTER 20. Backup and Data Recovery       

Recovery from system failure

After a power failure or other system failure you should run the system disk verification program:

• For OS/2: Run scandisk with the /autofix option.

• For NetWare: Load the Novell VREPAIR NLM to repair any volume that will not mount due to errors.

• For UNIX: Use chkfsys

• For Windows 3.x, Windows 95, and Windows NT, run the console command:

  chkdsk /f

This fixes simple errors in the file system structure that might have been caused by the system failure. This should be done before running any other software.

After a system error occurs, the server recovers automatically when you restart the database. The results of each transaction committed before the system error are intact. All changes by transactions that were not committed before the system failure are canceled. It is possible to recover uncommitted changes manually (see Recovering uncommitted changes).

  Steps to recover from a system failure

Adaptive Server Anywhere automatically takes three steps to recover from a system failure:

1. Restore all pages to the most recent checkpoint, using the checkpoint log.

2. Apply any changes made between the checkpoint and the system failure. These changes are in the transaction log.

3. Roll back all uncommitted transactions, using the rollback logs. There is a separate rollback log for every connection.

Frequent checkpoints make recovery quicker, but also create work for the server writing out dirty pages.

There are two database options that allow you to control the frequency of checkpoints. CHECKPOINT_TIME controls the maximum desired time between checkpoints and RECOVERY_TIME controls the maximum desired time for recovery in the event of system failure. The RECOVERY_TIME specifies an estimate for steps 1 and 2 only.

     For more information on these options, see General database options.

Step 3 may take a long time if there are long uncommitted transactions that have already done a great deal of work since the last checkpoint.

The transaction log is optional. When you are running with no transaction log, a checkpoint is done whenever any transaction is committed. In the event of system failure, the server uses steps 1 and 3 from above to recover a database file. Step 2 is not necessary because there will be no committed transactions since the last checkpoint. This is, however, usually a slower way to run because of the frequent checkpoints.

  Using a live backup for machine redundancy

You carry out a live backup of the transaction log by using the dbbackup command line utility with the -l command-line option. Live backups provide a redundant copy of the transaction log that is available for restart of your system on a secondary machine in case the machine running the database server becomes unusable.

A live backup runs continuously, terminating only if the server shuts down. If you suffer a system failure, the backed up transaction log can be used for a rapid restart of the system.

  To use a live backup:

1. Periodically, carry out a backup of the database file to a secondary machine.

2. Run a live backup of the transaction log to the secondary machine.

3. If the primary machine becomes unusable, you can restart your database using the secondary machine. The database file and the transaction log hold the information needed to restart.

   To restart, you must first start the database server with the apply transaction log (-a) switch, to apply the transaction log and bring the database up to date:

   dbeng6 asademo.db -a asademo.log

   The database server shuts down automatically once the transaction log is applied. You can then start the database in the normal way. The server will come up normally, and any new activity will be appended to the current transaction log.

Live backups and transaction log mirrors 

There are several differences between using a live backup and using a transaction log mirror:

• In general, a live backup is made to a different machine     Running a transaction log mirror on a separate machine can lead to performance problems, and will stop the database server if the connection between the machines goes down.

  By running the backup utility on a separate machine, the database server does not do the writing of the backed up log file. Therefore, performance impact is less.

• A live backup provides protection against a machine becoming unusable     Even if a transaction log mirror is kept on a separate device, it does not provide immediate recovery if the whole machine becomes unusable.

• A live backup may lag behind the database server     A mirrored transaction log contains all the information required for complete recovery of committed transactions. Depending on the load that the server is processing, the live backup may lag behind and may not contain all the committed transactions.

Live backups and regular backups 

The live backup of the transaction log is always the same length or shorter than the active transaction log. When a live backup is running, and another backup restarts the transaction log (dbbackup -r or dbbackup -x), the live backup automatically truncates the live backup log and restarts the live backup at the beginning of the new transaction log.