|
|
|
Transaction control is intended primarily for protection of data. System failures can occur during processing, which can gravely corrupt valuable data. These include everything from a software or OS failure to hardware failure, including power loss. Frequently, COBOL applications must rebuild all tables after such an event to recover as much data as possible and to bring their indexes back to a consistent state with the data.
When FairCom DB is started, one of the very first tasks it processes is to detect and determine if it was properly shut down from the previous run. If not, it undergoes a process called automatic recovery.
During recovery, the FairCom RTG server examines the current state of the transaction log and begins scanning and rebuilding all transactions up to and including the last committed transaction to the database. Once complete, all data and index files are in a clean consistent state ready for immediate operations by the application. This process is usually very quick and results in very little downtime for an application and the organization.
When the application crashes while instructions are being processed, the application will detect that a problem has occurred the next time it starts up. The transaction management logic will then automatically reset the database back to the last, most complete state that it can using the transaction log. Transactions committed before the crash will be redone, while those not yet committed will be undone. Only files which include a full transaction mode with logging enabled are able to be recovered.
Occasionally, tables do not remain on disk when recovery runs. Recovery stops as it can’t recover the referenced tables in the transaction logs. If it is ok to do so,FairCom RTG can skip the recovery of those tables. Only use this option when you absolutely know you need it.
There are options to improve recovery performance for very large environments.
