|
|
|
Transaction control by definition requires logging all database changes to persisted storage. Of course, transaction control is highly desirable for recovery of the database in the event of system failure. It also makes available other valuable features such as replication. However, this comes with a direct and measurable performance cost.
The new Delayed Durability feature can greatly enhance performance; however, should a system fail, database recovery could take considerable time if the transaction logs held substantial volumes of data not yet flushed to data and index files.
This leads to an additional challenge of how to balance data integrity using transactions against performance and recovery. Certain classes of applications can restore to known points in time. Consider the simple case of a bulk load. Should anything fail during loading, the load process can usually be restarted. If this known position could be coordinated with a c-treeACE server transaction log position, one could architect a very effective recovery process.
To this end, a new Restore Point feature has been introduced. A Restore Point is a position in a transaction log to which FairCom Server’s automatic recovery can roll back the system in event of system failure.
The Restore Point is used for restoring a system to a point in time coordinated with the application as a known good state. After restoring the system to a Restore Point, the application can be architected to perform work that was not recovered. For example, those applications maintaining their own journal of operations. By coordinating a known good state in time between the application and the server’s transaction logs, these applications can quickly recover back to a point in time when absolutely needed.
See Transaction Restore Points for Application Recovery.
