Try OpenEdge Now
skip to main content
Database Administration
Protecting Your Data : Recovering a Database : Introduction to recovery mechanisms : Crash recovery
 
Crash recovery
Crash recovery occurs automatically. With this feature, the database engine uses information from the primary recovery (BI) log to recover from system failures.
The BI files are a vital part of the database. You should treat the files as an integral part of the database unit. When you back up and restore the database, back up and restore the DB and BI files together. Never manually delete the BI files.
While the database is running, database transaction information exists in three areas:
*The database on disk
*The buffer pool in memory
*The BI files on disk
When database records are modified, the changes occur first in memory. When a transaction is committed, the change is recorded to the BI file. Over time, the database engine makes the change to the database file on disk. If the system fails, the information stored in the buffer pool is lost. The database engine performs crash recovery using the information logged to the BI file to re-create lost transactions and undo transactions that were not committed.
Before updating the database, the database engine makes a copy of the current information and writes it to the BI file. This activity begins at the end of an update operation. If the system fails during the transaction, the engine uses the information in the BI file to restore the database to its pretransaction state. The engine also uses the information in the BI files during normal processing to undo transactions.
For example, suppose you run the following ABL (Advanced Business Language) procedure:
FOR EACH customer:
  UPDATE customer.name customer.max-credit.
END.
You update customers 1 and 2, and while you are updating customer 3, the system fails. When you restart the database, messages appear in the database .lg file, similar to the following (be aware that the timestamp, PID, and thread ID is removed from the beginning of the line to facilliate easier reading of the messages):

I DBUTIL : (18186) Crash Recovery Status Interval (-crStatus): 5 seconds
I DBUTIL : (18187) Crash Recovery Transaction Display (-crTXDisplay): ON
I DBUTIL : (5326) Begin Physical Redo Phase at 64 .
I DBUTIL : (7161) Physical Redo Phase Completed at blk 4 off 718 upd 226.
I DBUTIL : (13547) At end of Physical redo, transaction table size is 128.
I DBUTIL : (12080) Begin Replication Redo Phase for 5 live transactions from 64 .
I DBUTIL : (12081) Replication Redo Phase completed at block 1800, offset 7328.
I DBUTIL : (7163) Begin Physical Undo 6 transactions at block 4 offset 754
I DBUTIL : (5331) Physical Undo Phase Completed at 220 .
I DBUTIL : (7162) Begin Logical Undo Phase, 5 incomplete transactions are being backed out.
I DBUTIL : (11231) Logical Undo Phase begin at Block 220 Offset 116.
I DBUTIL : (12095) Logical Undo Phase completed at block 29568, offset 450.
I DBUTIL : (7129) Usr 0 set name to shannon.
I DBUTIL : (123) .bi file truncated.
I DBUTIL : (15109) At Database close the number of live transactions is 0.
I DBUTIL : (15743) Before Image Log Completion at Block 56773 Offset 3841.
The messages indicate the necessary phases of crash recovery performed by the database engine to bring the database to the consistent state that existed prior to the system failure. Since the engine performs crash recovery every time you open the database, not all of the recovery phases are logged in the database .lg file. For example, the engine performs and logs the Physical Redo phase unconditionally, but the Physical Undo and Logical Undo phases are only performed and logged when outstanding transactions are found. Similarly, the Replication Redo phase is only for a replication-enabled database.
When you rerun the same procedure, customers 1 and 2 remain updated, but the database engine has used the BI file to restore customer 3 to the state it was in before you began the update.
With a larger database with more activity, crash recovery can take longer than a few seconds to run. Two startup parameters can help you monitor the progress of your crash recovery by logging status messages to the screen:
*crStatus — Displays the phase progress as an estimate of percent complete. For example, the following is displayed to the screen during crash recovery with -crStatus 5:
Logical Undo 9% at block 2967. 2926 blocks processed in 5 seconds.
Logical Undo 19% at block 5744. 5653 blocks processed in 10 seconds.
Logical Undo 29% at block 8916. 8881 blocks processed in 15 seconds.
Logical Undo 38% at block 11543. 11502 blocks processed in 20 seconds.
Logical Undo 48% at block 14294. 14255 blocks processed in 25 seconds.
Logical Undo 56% at block 16850. 16819 blocks processed in 31 seconds.
Logical Undo 65% at block 19545. 19500 blocks processed in 36 seconds.
Logical Undo 75% at block 22587. 22474 blocks processed in 41 seconds.
Logical Undo 84% at block 25138. 25043 blocks processed in 46 seconds.
Logical Undo 93% at block 27725. 27704 blocks processed in 51 seconds.
Logical Undo 100% at block 29568. 29573 blocks processed in 54 seconds.
For more information about crash recovery progress messages, see Crash Recovery Status (-crStatus).
*crTXDisplay — Displays transaction IDs and adds counters to the -crstatus output. For example:
Transaction 2048 by user 15 at 2015/08/06@16:53:49. Counter: 202
Transaction 5771 by user 12 at 2015/08/06@16:55:15. Counter: 459
Transaction 24 by user 7 at 2015/08/06@16:52:49. Counter: 1
Transaction 5801 by user 10 at 2015/08/06@16:55:15. Counter: 460
Transaction 5802 by user 14 at 2015/08/06@16:55:16. Counter: 463
Transaction 5683 by user 18 at 2015/08/06@16:55:15. Counter: 459
Logical Undo 10% at block 3205. 3200 blocks processed in 5 seconds. Counter: 413
Logical Undo 21% at block 6427. 6378 blocks processed in 10 seconds. Counter: 363
Logical Undo 30% at block 9038. 9015 blocks processed in 15 seconds. Counter: 322
Logical Undo 38% at block 11581. 11464 blocks processed in 20 seconds. Counter: 283
Logical Undo 44% at block 13148. 13097 blocks processed in 25 seconds. Counter: 258
Logical Undo 50% at block 14994. 14963 blocks processed in 31 seconds. Counter: 229
Logical Undo 58% at block 17502. 17447 blocks processed in 36 seconds. Counter: 190
Logical Undo 64% at block 19210. 19195 blocks processed in 41 seconds. Counter: 163
Logical Undo 71% at block 21264. 21237 blocks processed in 46 seconds. Counter: 131
Logical Undo 82% at block 24412. 24361 blocks processed in 51 seconds. Counter: 82
Logical Undo 90% at block 27070. 26951 blocks processed in 56 seconds. Counter: 41
Logical Undo 100% at block 29568. 29573 blocks processed in 60 seconds. Counter: 1
For more information, see Crash Recovery Transaction Display (-crTXDisplay).
Crash recovery protects you from system failures, but it does not protect you from loss of media. In the event of media loss, you must restore from a backup, and either manually re-enter the lost transactions or use the roll-forward recovery mechanism to re-create the transaction.