The algorithm of fail recovery of a DBMS must be provided necessary with the UNDONE operation if The algorithm of management of the buffer of memory is of type “no steal page” The algorithm of management of the buffer of memory is of type “no force writing” Concurrent transactions are allowed Long transactions are allowed.
The algorithm of fail recovery of a DBMS must be provided necessary with the REDONE operation if The algorithm of management of the buffer of memory is of type “no steal page” The algorithm of management of the buffer of memory is of type “no force writing” Concurrent transactions are allowed Long transactions are allowed.
A DBMS that implements immediate update of dirty pages, the first rule of Write-Ahead Loging, WAL#1: It is necessary to guarantee the atomicity It is necessary if the algorithm of management of the buffer of memory is of type “steal page” It allows the implementation of the operation UNDONE He does not prevent committed transactions from being able to get lost.
A DBMS that implements immediate update of dirty pages, the second rule of Write-Ahead Loging, WAL#2: It is necessary to guarantee the atomicity It is necessary if the algorithm of management of the buffer of memory is of type “steal page” It allows the implementation of the operation UNDONE He does not prevent committed transactions from being able to get lost.
With Regard to ARIES, it is posible to affirm that: The dirty pages are recorded in the data file In the checkpoints It is an algorithm of fail recovery adapted for a strategy of the data buffer of type “force” It is an algorithm of fail recovery adapted for a strategy of the data buffer of type “steal” During the undo step, it is required to back up to reaching the first event that did that some page were noted down as dirty.
Regarding the redo phase in ARIES: It redoes only and exclusively those events that still have not been stored in the data file It redoes both those events of committed and not committed transactions It uses the lastLSN value stored in every trace to redo more efficiently "undo" is the previous step.
Regarding the undo: It redoes only and exclusively those events that still have not been stored in the data file It redoes both those events of committed and not committed transactions It uses the lastLSN value stored in every trace to redo more efficiently “analysis" is the previous step.
Regarding ARIES, It is possible to affirm that the database is exactly in the state that was in the moment of the fail: At the end of the analysis phase At the end of the "redo“ phase At the end of “undo” phase Never
.
|
