Logging

Question 1

Logging

Answer 1

Writes down important things that happens during transactions, like states etc.

Question 2

Logging with system failure

Answer 2

Logging should work even if the system fails, but sometimes logging is not enough.
Therefore we rely on undo logging, redo logging and combinations of both.

Question 3

Operations for Log Manager

Answer 3

• writing x just writes to the buffer
• output(x) -> copy database item x from buffer to the database itself
• flush_log -> write log entries that are residing in main memory to the log

Question 4

Undo Logging

Answer 4

Undo logging logs activities with the goal of restoring a previous database state.

Question 5

Log Records for Undo Loggging

Answer 5

• <START>
  </START>
• <COMMIT>
  </COMMIT>
• <ABORT>
  </ABORT>
• <T, X , v>

Question 6

<START>
</START>

Answer 6

Transaction t has started.

Question 7

<COMMIT>
</COMMIT>

Answer 7

Transaction t has committed.

Question 8

<ABORT>
</ABORT>

Answer 8

Transaction t was aborted.

Question 9

<T, X, v>

Answer 9

Transaction t has updated value of database item x, with the old value being v.

Question 10

Rules for Undo Logging

Answer 10

• If transaction t updates item x and old value was v, then T, X, v must be written to the log on disk before x is written to disk.
• If transaction t commits, commit t must be written as soon as all database elements changed by t have been written to disk.

Question 11

System Failure with no commits

Answer 11

If the system fails and we have not committed (and if there is no abort for the specific transaction, which means it would have already been reverted), we have to undo all changes done, with each v replacing x which was recorded on the logs. If it has committed, then no changes are required.

Question 12

Recovery Manager

Answer 12

The recovery manager restores the last consistent database state in an error occurs, traversing the undo log backwards.
Once all undone, we write abort t for each uncommitted transaction t that was not previously aborted (when traversing back through the undo log, if we also have an aborted transaction, we do not have to write up that transaction again) and call flush_log.

Question 13

Redo Logging

Answer 13

Logs activities with the goal of restoring committed transactions.

Question 14

Log Records for Redo Logging

Answer 14

Only one record has changed:

<T, X , v> -> transaction t has updated value of database item x, with the NEW value being v.
Essentially, we intend to get a value which has been committed, not undoing a value.

Question 15

Rules for Redo Logging

Answer 15

Rules:
- T first writes all log records for all updates
- T writes commit t to the log on disk
- T writes all committed updates to disk

Question 16

Main Objective of Redo Logging

Answer 16

The main point of redo logging is to do the reverse of undo logging.

Question 17

Combining Redo and Undo Logging

Answer 17

<T, X, v, w> -> v is the old value, w is the new value.

Question 18

Undo without Redo

Answer 18

• ensures atomicity
• can ensure durability with Force (forces writing of updates to disk before committing)

Question 19

Redo without Undo

Answer 19

• ensures durability
• can ensure atomicity using No Steal (uncommitted data may not overwrite committed data on disk)

Question 20

ACID Logging

Answer 20

Can ensure durability and atomicity without logs but instead with No Steal and Force, but is overall very expensive.

Question 21

No Steal

Answer 21

Don’t allow buffer-pool frames with
uncommitted updates to overwrite committed data on disk.

Question 22

Force

Answer 22

Make sure that every update is on disk before committing.