Lecture
It is clear that to restore the last consistent state of the database after a hard failure of the database change log is not enough. The basis of recovery in this case are the log and an archive copy of the database.
Recovery begins with a reverse copy of the database from an archive copy. Then, for all completed transactions, redo is executed, i.e. operations are repeated in the literal sense.
More precisely, the following happens:
In fact, since the hard failure is not accompanied by the loss of RAM buffers, you can restore the database to such a level that even the execution of incomplete transactions can be continued. But usually this is not done, because recovery from a hard failure is a fairly long process.
Although there are special requirements for maintaining a journal in terms of reliability, in principle its loss is also possible. Then the only way to restore the database is to return to the backup copy. Of course, in this case it will not be possible to get the last consistent state of the database, but this is better than nothing.
The last question, which we will consider briefly, relates to the production of archival copies of the database. The easiest way is to archive the database when the log is full. The so-called "yellow zone" is entered in the log, when this is achieved, the formation of new transactions is temporarily blocked. When all transactions are completed, and therefore, the database comes in a consistent state, you can archive it, and then start to fill the log again.
You can back up the database less often than the log is full. If the log is full and all started transactions are finished, you can archive the log itself. Since such an archived journal is, in fact, required only to recreate an archive copy of the database, the journal information can be significantly compressed during archiving.
Comments
To leave a comment
Databases IBM System R - relational DBMS
Terms: Databases IBM System R - relational DBMS