Roll-forward Recovery

Derby supports roll-forward recovery to restore a damaged database to the most recent state before a failure occurred. Derby restores a database from full backup and replays all the transactions after the backup. All the log files after a backup are required to replay the transactions after the backup. By default, the database keeps only logs that are required for crash-recovery. For roll-forward recovery to be successful, all log files should be archived after a backup. Log files can be archived using the backup function calls that enable log archiving.

In roll-forward recovery the log archival mode ensures that all old log files are available. The log files are available only from the time that the log archival mode is enabled.

Derby uses the following information to restore the database:

• The backup copy of the database
• The set of archived logs
• The current online active log

You cannot use roll-forward recovery to restore individual tables. Roll-forward recovery recovers the entire database.

To restore a database using roll-forward recovery, you must already have a backup copy of the database, all the archived logs since then, and the active log files. All the log files should be in the database log directory.

There are two types of log files in Derby: active logs and online archived logs.

Active Logs:

Active logs are used during crash recovery to prevent a failure from leaving a database in an inconsistent state. Roll-forward recovery can also use the active logs to recover to the end of the log files. Active logs are located in the database log path directory.

Online Archived Logs

Log files that are stored for roll-forward recovery use when they are no longer needed for crash recovery. Online Archived logs are also kept in the database log path directory.

Enabling Log Archival Mode

Online archive logs are available only if the database is enabled for log archival mode. You can use the following system procedure:

SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
(IN BACKUPDIR VARCHAR(32672), IN SMALLINT DELETE_ARCHIVED_LOG_FILES)

The input parameters for the above calls are the location where the backup should be stored and to indicate to the database whether or not to keep online archived logs for the backup. Existing online archived log files before this backup will be deleted if the input parameter value for deleteOnlineArchivedLogFiles is non-zero. The log files are deleted only after a successful backup.

Note:

Make sure to store the backup database in a safe place when you choose the log file removal option.

Disabling Log Archival Mode:

Once you enable log archival mode, the database will always have the log archival mode enabled even if it is subsequently booted or backed up. The only way to disable the log archive mode is to call:

SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(IN SMALLINT DELETE_ARCHIVED_LOG_FILES )

This system procedure disables the log archive mode and deletes any existing online archived log files if the input parameter DELETE_ARCHIVED_LOG_FILES is non-zero.

Performing Roll-Forward Recovery:

By using the full backup copy , archived logs and active logs, the database can be restored to its most recent state by performing roll-forward recovery. Roll-forward recovery can be performed by specifying a connection URL attribute rollForwardRecoveryFrom=<BackupPath> at boot time. This brings the database to most recent state using full backup copy , archived logs and active logs. All the log files should be in the database log path directory.

In the following example a database named 'wombat' is backed up to d:/database directory with log archive mode enabled and restored using roll-forward recovery after a media failure:

Backing Up a Database:

connect 'jdbc:derby:wombat;create=true';
 
create table t1(a int not null primary key);
------------------DML/DDL Operations
CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
('d:/backup', 0);
insert into t1 values(19);
create table t2(a int);
-----------------DML/DDL Operations
-----------------Database Crashed (Media Corruption on data disks)

Restoring a Database Using Roll-Forward Recovery:

connect 'jdbc:derby:wombat;rollForwardRecoveryFrom=d:/backup/wombat';
select * from t1;
---------------DML/DDL Operations

The following attribute can be specified in the JDBC boot time connection URL:

rollForwardRecoveryFrom=<Path>

For more information see the rollForwardRecoveryFrom=<Path> section in the Derby Reference Manual.

After a database is restored from full backup, transactions from the online archived logs and active logs are replayed.

The roll-forward recovery mechanism only helps to restore a database to the most recent point of time if the log files are available. It is very important to make sure that log data is not damaged due to a disk crash. You should use some form of disk fault tolerance method. Generally, this is accomplished through the use of a disk array. A disk array consists of a collection of disk drives that appear as a single large disk drive to an application. Disk arrays involve disk striping, which is the distribution of a file across multiple disks, the mirroring of disks, and data parity checks.