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 third-party companies like IBPhoenix.
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 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 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)
IBLMRedo is free for registered IBLM customers only. If you want to deploy IBLMRedo to your customers, who haven't an IB LogManager license, then you can purchase IBLM independent IBLMRedo licenses here.

