ref：https://blog.csdn.net/whyangwanfu/article/details/1926367
Primitive operations Affairs
In the run transactional systems which, there are three elements of the address space for storage:
- disk space
- Buffer
- Local address space affairs.
A simple read, modify the operation of the processes of the element X: read transaction into the buffer element X, if hit, read transaction and returns a local address space, if a miss, the associated first read from disk into the page buffer . Services modified in its local address space element X, then the write buffer, and then written to the disk buffer. Of course, the buffer may not be immediately copy the data into the disk, depending on the specific buffer management strategy.
For ease of description, we describe four primitive operations:
- The INPUT (X) : X database elements including a block copy to disk memory buffer
- The READ (X, T) : X element copy database transaction to the local variable t. More specifically, if the memory buffer is not in the database containing the element X in the block, is executed first INPUT (X). Then the local variable is assigned the value of X t.
- The WRITE (X-, t) : the value of the local variable t is copied to the buffer memory database element X. More specifically, if the memory buffer is not in the database containing the element X in the block, is executed first INPUT (X). The value of t will be copied into the buffer X.
- The OUTPUT (X) : X buffer containing copies back to disk.
undo log
If the system crashes, Recovery Manager is activated, check the logs to rebuild a database of consistent state. When restored, the transaction will redo some work, write them to the new value of the database will be rewritten again. Other matters to work will be undone, the database is restored, will perform as if these transactions had never been the same.
1 Overview
Undo log is a log type, only the second log such restorations. For the transaction to be undone because it was not sure whether to modify the database has been written to disk, so all updates to the transaction will be undone, restore the database to a previous state of affairs occurred.
2. Logging
Log only write data in an additive fashion. Log block originally created in main memory, also the same as the data block, when the determined time, the log block is written to the buffer manager from the buffer to disk.
About undo record in the form of four:
- <The START T> : This record represents the beginning of a transaction T
- <COMMIT T> : Transaction T has been completed.
- <ABORT T> : Transaction T can not be executed successfully.
- <T, X, V> : T changes the value of the database transaction element X, the element X of the original value v.
3.undo Log Rules
To get undo log enable us to recover from a system failure, the transaction must follow two rules.
Rule 1) If the transaction database element X T changes, then the form <T, X, v> log record must be written in the new value of X is written to the disk before the disk
Rule 2) if the transaction commits, it COMMIT log record must be written to disk in all elements of the transaction database changes are written to disk before, but it should be as soon as possible.
Brief summary, undo logging system in the following order:
1) as specified in the logging database elements change
database element 2) altered self
3) COMMIT log record.
4. Static checkpoints
1) stop accepting new transactions
2) waits for all currently active transaction is committed or terminated, and write COMMIT or ABORT recorded in the log file.
3) the log flushed to disk
4) writes logging <CKRT> , and refresh the record again.
5) start accepting new transactions.
When restoring, scanned <CKRT> the log, there is no need to continue the scan log record.
5. Dynamic Checkpoint
The disadvantage of static checkpoints with, you may need to wait a long time to complete active transactions in the user's system appears to be still. Non-static checking overcome this drawback, allowing new transaction enters when making a checkpoint. The following steps:
1) write log records <START CKPT (T1, ......, Tk)> wherein T1, ......, Tk is an active transaction.
2) Wait T1, ......, Tk each transaction is committed or aborted, but allows other transactions begin.
3) When T1, ......, Tk are completed, write log records <END CKPT> and flushes the log.
When the system fails to start scanning the log from the tail of the log. The scanning process to meet <END CKPT> records or <START CKPT (T1, ......, Tk)> record, there are two cases.
1) If the first to meet the <END CKPT> records. All outstanding transactions <START CKPT (T1, ......, Tk)> after the recording start, as long as the scanned <START CKPT (T1, ......, Tk)> there is no need to continue the scan. <START CKPT (T1, ......, Tk)> record is truncated before.
2) if the first encounter <the CKPT the START (Tl, ......, Tk)> , then a crash occurs in the checkpoint process. The transaction may not be completed only reach <START CKPT (T1, ......, Tk)> before those encounters, as well as T1, ......, those Tk before the crash unfinished. So long as it continues to scan the earliest transaction that the transaction is not completed in the beginning of the line.
A general rule, once <END CKPT> record to the disk, we can put on a <START CKPT> log before recording deleted.
redo log
1 Overview
Undo is a strategy to recover, but not the only strategy.
Undo log a potential problem is: before all modified data is not written in the disk, not allowed to commit the transaction.
Sometimes, the changes to the data pages temporary buffer in main memory, can save disk IO; whenever there is a crash in the log used to restore.
Rules 2.redo log
Redo log indicates that the update data elements with new values, and undo log using the old values. Redo log <T, X, v> represents: writing a new value v T transaction database element X.
Redo log system of rules is only one:
Rule 1: Before modifying any database element X on disk, to ensure that all the modifications related to X logging, including updating records <T, X, v> and <COMMIT T> record , must appear on the disk.
Redo log sequence as follows:
1) modified elements are indicated log
2) COMMIT log
3) changed data element itself.
3. Use the recovery redo log
For redo logs, according to Rule 1, we can not know if the log <COMMIT T> record, modify the transaction T is doing all the updates did not reflect on the disk, like the transaction T has never happened.
If you find that record <COMMIT T> record, but can not guarantee that all database changes have been reflected in the disk, which is the opposite and undo logs. We have to redo the transaction T once.
Use redo log recovery process is as follows:
1) determine the transaction is committed
2) scanning the log from the start of the header, for each encountered <T, X, v> Record:
- If the transaction is uncommitted T, do nothing
- If T is submitted tasks, compared with the database on disk elements to the value v
3) For each transaction T is not completed, the log is written in a <ABORT T> recording and flushes the log