Each database includes recovery logs, which are used to recover from application or system errors. In combination with database backups, logs are used to recover the consistency of the database right up to a point in time when an error occurred.
All databases have logs associated with them. These logs keep records of database changes. Some logs, called active logs, prevent a failure (system power, application error) from leaving a database in an inconsistent state. They restore the state of a database to the point before the change. Other logs, called archived logs, enable forward recovery to any point in time before the failure.
Active and archive logging
Active logs contain transactions which have not yet been committed or rolled back, or whose changes have not yet been written to disk. Active logs are located in the database log path directory (see ARS_PRIMARY_LOG_PATH in the ARS.CFG file).
Archive logging enables forward recovery using active and archived logs to any point in time before a failure, rather than only to the point in time of a full backup. With archive logging, active logs are retained and become online, archived logs. In addition, archived logs can be moved off line and still used for roll-forward recovery.
With archive logging, it becomes necessary to pay more attention to the handling of the logs and to ensure their safety. The ability to perform roll-forward recovery of your database is dependent on the integrity of the logs. Performance factors such as the location and size of the logs needs to be evaluated for the impact on overall system performance. In planning for disaster recovery, be sure to remember that log data must be stored off site, or at least safely away from the disaster, in order to recover your database beyond the point of the last full, off line backup.
When all changes in the active log are no longer needed for normal processing, the log is closed and becomes an archived log. An archived log is said to be online when it is stored in the database log path directory.
You also have the ability to store archived logs in a
location other than the database log path directory, by using DB2 Database logging. 
Configuration parameters for database logging
- Log file size. Determines the size of a log file, in 4 KB blocks. The default value (see ARS_LOGFILE_SIZE in the ARS.CFG file) is 1000, which means that each log file is about 4 MB in size.
- The number of active log files. The maximum number of active log files that can be allocated to the database at one time. The default value (see ARS_LOG_NUMBER in the ARS.CFG file) is 40.
Backing up the file system
Back
up your database file systems using the data recovery facilities provided by DB2 or
Oracle. See the SQL Server documentation for details on a backup strategy. You can also use the standard Tivoli® Storage Manager backup commands to do file system backups. See the Tivoli Storage Manager Administrator's Reference for detailed information about the commands that you can use and to schedule backups.
If you use the standard Tivoli Storage Manager backup commands to backup file systems on the server, it is recommended that you exclude the database file systems and the cache file systems from the backup.
While you can store the file system backups in the same optical library as the OnDemand data, you should define different client nodes to hold the file system backups. The client nodes should be assigned to a different domain than the OnDemand data. The retention period of the file system backups will likely be different than the retention period for the OnDemand data.
File system backups generally require re-writable media.
- One for the file system backup.
- One for the OnDemand data.