Question & Answer
During a lengthy Backward phase of crash recovery or 'HADR Takeover', how can the database be accessed?
If a database is interrupted unexpectedly before all transactions (or units of work) are committed, or before the changes associated with committed transactions are fully written to disk, then the database is left in an inconsistent state. When the database is restarted or an 'HADR Takeover by Force' is performed, these transactions are rectified during a process called crash recovery (see the 'Related Information' section at bottom for more information). During crash recovery, the changes associated with these transactions are first replayed from the transaction logs - we often refer to this as the Forward or Redo phase of crash recovery. Transactions which were not yet committed at the time of the database failure (or 'HADR Takeover by Force') are then rolled back - we often refer to this as the Backward or Undo phase of crash recovery.
Prior to Version 220.127.116.11, the database was only accessible after the full completion of crash recovery. This was not ideal, since a very large transaction could require a lengthy Backward phase, leaving the database entirely inaccessible until it completed.
In Version 18.104.22.168, as a technical preview for testing in non-production environments, the database can be configured to allow accessibility during the backward phase of crash recovery.
This behaviour can be enabled using the following undocumented database registry variable:
Beginning in Version 22.214.171.124, this behaviour is now fully supported for production environments.
This behaviour can now be enabled using it's official name:
(Changes to this variable do not require the database instance to be restarted.)
Please see the Knowledge Center page "Database accessibility during backward phase of crash recovery or HADR takeover" for full details:
16 June 2018