What is Roll-Forward Logging?

In case of a database crash, logged data changes will be applied on a workable operating system backup of your database, to bring the database, for a specific point in time, Online again.

Other RDBMS like Oracle, MS SQL Server 2000, ... keep a transaction log automatically, which will be used to recover a crashed database. This usually takes (a lot of) time until the database is back again.

Due to the Multi-Generational Architectur (MGA) of Firebird and InterBase there isn't a transaction log, which can be applied on a working backup, but in case of a database corruption there is only 'gfix.exe' or some third-party companies like IBPhoenix or Devrace right now.

Roll-Forward Logging and IB LogManager

a) IB LogManager already provides a proven mechanism to log data changes within the database, but due to the nature of Firebird and InterBase triggers, changes can be stored only within the same database, so in case of database corruption, logged changes aren't accessible or simply lost.

b) The IBLM Addon 'IBLMPump' (available for registerd customers) jumps in here, because this command line utility allows you to pump logged data from the main database into an external (transaction log) database by using the Firebird and InterBase two phase commit protocol. Read more about IBLMPump here.

a) and b) already gives you the possibility to keep logged data changes (transaction log) outside the production database. In case of a corrupted production database, you can either try to fix the corruption with 'gfix.exe' or you can roll-forward the logs in the external (transaction log) database on a workable operating system backup of your production database.

IBLMRedo - The IBLM Roll-Forward Log Utility

IBLMRedo executes the following actions:

• Step 1: All executed operations can be monitored (optional)



• Step 2: Connect to the source (transaction log) and destination database



• Step 3: Execute a user-defined SQL script file on the destination database (optional; running in a separate transaction)



• Step 4: Deactivate all currently active triggers in the destination database (optional; running in a separate transaction)



• Step 5: As step 4) needs its own transaction, with step 5) it's possible to store a SQL script file with all necessary DDL statements to activate all triggers if something unpredictable happens during the Roll-Forward (step 6). (optional)



• Step 6: Open the operation log records (in ascending order) in the source (log) database under the consideration of a user-defined WHERE clause and applies all logged operations with their tracked column value changes on the destination database.
  
  IBLMPump v1.0.0.5 and later is able to log the current generator values before executing the pump process (use LogCurrentGeneratorValues=1 in the [Source] section). Logged generator values are reflected as one record in the operation log table using 'IBLM$GENERATORVALUES' as table name and one record in the column log table for each generator/value pair. IBLMRedo is able to interpret an operation log record using 'IBLM$GENERATORVALUES' as table name by either setting the generator values or by moving to the next operation log record without any operation applied.



• Step 7: Activate the trigger deactivated in step 4) (optional; this only happens if step 4) was executed; running in a separate transaction)



• Step 8: Execute a user-defined SQL script file on the destination database (optional; running in a separate transaction)

How to obtain IBLMRedo?

IBLMRedo is free for registered IBLM customers only. If you want to deploy IBLMExport to your customers, who haven't an IB LogManager license, then you can purchase IBLM independent IBLMExport licenses here.