Backup and Recovery Techniques

1

• Backup and Recovery Techniques
• Need for Recovery
• Whenever a transaction is submitted to a DBMS for
  execution, the system is responsible for making
  sure that either
• All the operations in the transaction are
  completed successfully and their effect is
  recorded permanently in the database or
• The transaction has no effect whatsoever on the
  database or on any other transactions.
• The DBMS must not permit some operations of a
  transaction T to be applied to the database while
  other operations of T are not.
• This may happen if a transaction fails after
  executing some of its operations but before
  executing all of them.

2

• Types of Failures
• There are several possible reasons for a
  transaction to fail in the middle of the
  execution. They are
• 1. A computer failure (system crash)
• A hardware, software, or network error occurs in
  the computer system during transaction execution.
• Hardware crashes are usually media failures like
  main memory failure.

3

• 2. A transaction or system error
• Some operation in the transaction may cause it to
  fail, such as integer overflow or division by
  zero.
• Transaction failure may also occur because of
  erroneous parameter values or because of a
  logical programming error.
• In addition the user may interrupt the
  transaction during its execution.

4

• 3. Local errors or exception conditions detected
  by the transaction
• During transaction execution, certain conditions
  may occur that necessitate cancellation of the
  transaction.
• For e.g. data for the transaction may not be
  found.
• Notice that an exception condition, such as
  insufficient account balance in a banking
  database may cause a transaction, such as money
  withdrawal to be cancelled.
• This should be programmed in the transaction
  itself and hence would not be considered a
  failure.

5

• 4. Concurrency control enforcement
• The concurrency method may decide to abort the
  transaction, to be restarted later, because it
  violates serializability or because several
  transaction are in a state of deadlock.
• 5. Disk Failure
• Some disk blocks may lose their data because of a
  read or write malfunction or because of a disk
  read/write head crash.
• This may happen during a read or a write
  operation of the transaction.

6

• 6. Physical problems and catastrophes
• This refers to an endless list of problems that
  includes power or air conditioning failure, fire,
  theft, sabotage, overwriting disks or tapes by
  mistake and mounting of a wrong tape by the
  operator.

7

• Recovery Algorithms
• Recovery algorithms are techniques to ensure
  database consistency and transaction atomicity
  and durability despite failures.
• Recovery algorithms have two parts
• Actions taken during normal transaction
  processing to ensure enough information exists to
  recover from failures.
• Actions taken after a failure to recover the
  database contents to a state that ensures
  atomicity, consistency and durability.

8

• Storage Structure
• Volatile storage
• Information residing in volatile storage does not
  usually survive system crashes.
• examples main memory, cache memory.
• Access to volatile storage is extremely fast.
• Nonvolatile storage
• Information residing in non volatile storage
  survives system crashes.
• examples disk, tape, flash memory, non-volatile
  (battery backed up) RAM .
• Stable storage
• a mythical form of storage that survives all
  failures.
• approximated by maintaining multiple copies on
  distinct nonvolatile media.

9

• Stable-Storage Implementation
• Stable storage maintains multiple copies of each
  block on separate disks.
• Copies can be at remote sites to protect against
  disasters such as fire or flooding.
• Failure during data transfer can result in
  inconsistent copies.
• Block transfer can result in
• Successful completion.
• Partial failure destination block has incorrect
  information.
• Total failure destination block was never
  updated.

10

• One solution for protecting storage media from
  failure during data transfer is to execute output
  operation as follows (assuming two copies of each
  block)
• Write the information onto the first physical
  block.
• When the first write successfully completes,
  write the same information onto the second
  physical block.
• The output is completed only after the second
  write successfully completes.

11

• Copies of a block may differ due to failure
  during output operation. To recover from failure
• First find inconsistent blocks
• Expensive solution Compare the two copies of
  every disk block.
• Better solution
• Record in-progress disk writes on non-volatile
  storage (Non-volatile RAM or special area of
  disk).
• Use this information during recovery to find
  blocks that may be inconsistent, and only compare
  copies of these.
• If either copy of an inconsistent block is
  detected to have an error (bad checksum),
  overwrite it by the other copy. If both have no
  error, but are different, overwrite the second
  block by the first block.

12

• Data Access
• Physical blocks are those blocks residing on the
  disk.
• Buffer blocks are the blocks residing temporarily
  in main memory.
• Block movements between disk and main memory are
  initiated through the following two operations
• input(B) transfers the physical block B to main
  memory.
• output(B) transfers the buffer block B to the
  disk, and replaces the appropriate physical block
  there.

13

• Each transaction Ti has its private work-area in
  which local copies of all data items accessed and
  updated by it are kept.
• Ti's local copy of a data item X is called xi.
• We assume, for simplicity, that each data item
  fits in, and is stored inside, a single block.

14

• Transaction transfers data items between system
  buffer blocks and its private work-area using the
  following operations
• read(X) assigns the value of data item X to the
  local variable xi.
• write(X) assigns the value of local variable xi
  to data item X in the buffer block.
• both these commands may necessitate the issue of
  an input(BX) instruction before the assignment,
  if the block BX in which X resides is not already
  in memory.
• Transactions
• Perform read(X) while accessing X for the first
  time
• All subsequent accesses are to the local copy.
• After last access, transaction executes write(X).
• output(BX) need not immediately follow write(X).
  System can perform the output operation when it
  deems fit.

15
Example of Data Access
buffer
input(A)
Buffer Block A
X
A
Buffer Block B
Y
B
output(B)
read(X)
write(Y)
x2
x1
y1
work area of T2
work area of T1
disk
memory
16
Recovery and Atomicity

• Modifying the database without ensuring that the
  transaction will commit may leave the database
  in an inconsistent state.
• Consider transaction Ti that transfers Rs.50 from
  account A to account B goal is either to
  perform all database modifications made by Ti or
  none at all.
• Several output operations may be required for Ti
  (to output A and B).
• A failure may occur after one of these
  modifications have been made but before all of
  them are made.

17

• To ensure atomicity despite failures, we first
  output information describing the modifications
  to stable storage without modifying the database
  itself.
• There are two approaches
• log-based recovery, and
• shadow-paging
• We assume (initially) that transactions run
  serially, that is, one after the other.

18

• Log-Based Recovery
• A log is kept on stable storage.
• The log is a sequence of log records, and
  maintains a record of update activities on the
  database.
• There are several types of log records.
• An update log record describes a single database
  write, and has the following fields

19

• When transaction Ti starts, it registers itself
  by writing a ltTi startgtlog record.
• Before Ti executes write(X), a log record ltTi, X,
  V1, V2gt is written, where V1 is the value of X
  before the write, and V2 is the value to be
  written to X.
• Log record notes that Ti has performed a write on
  data item Xj Xj had value V1 before the write,
  and will have value V2 after the write.
• When Ti finishes it last statement, the log
  record ltTi commitgt is written.

20

• Two approaches using logs
• Deferred database modification
• Immediate database modification

21

• Deferred database modification
• The idea behind deferred update technique is to
  defer or postpone any actual updates to the
  database until the transaction completes its
  execution successfully and reaches its commit
  point.
• During transaction execution, the updates are
  recorded only in the log and in cache buffers,
• After the transaction reaches its commit point
  and the log is written to the disk, the updates
  are recorded in the database.
• If a transaction fails before reaching its commit
  point there is no need to undo any operation
  because the transaction has not effected the
  database in any way.

22

• This is implemental only if transactions are
  short and each transaction changes few items.
• For other types of transactions , there is
  potential for running out of buffer space because
  transaction changes must be held in the cache
  buffers until the commit point.
• We can state a typical deferred update protocol
  as follows
• 1. A transaction cannot change the database on
  disk until it reaches its commit point.
• 2. A transaction does not reach its commit point
  until all its update operations are recorded in
  the log and the log is written to disk.

23

• With this protocol the database is never updated
  on disk until after the transaction commits,
  there is never a need to UNDO any operations.
• Hence this is known as NO UNDO/REDO recovery
  algorithm.
• REDO is needed in case the system fails after a
  transaction commits but before all its changes
  are recorded in the database on disk.
• In this case, the transaction operations are
  redone from the log entries.

24

• Immediate database modification
• In these techniques, when a transaction issues an
  update command, the database can be updated
  immediately, without any need to wait for the
  transaction to reach its commit point.
• In these techniques, however , an update
  operation must still be recorded in the log (on
  disk) before it is applied to the database.
• Provisions must be made for undoing the effect of
  update operations that has been applied to the
  database by a failed transaction.
• This is done by rolling back the transaction and
  undoing the effect of the transactions
  write_operations.

25

• Theoretically we can distinguish two main
  categories of immediate update algorithms
• If the recovery technique ensures that all
  updates of a transaction are recorded in the
  database on the disk before transaction commits,
  there is never a need to REDO any operations of
  the committed transactions
• This is called the UNDO/NO-REDO recovery
  algorithm.
• On the other hand if the transaction is allowed
  to commit before all its changes are written to
  the database, we have the most general case,
  known as the UNDO/REDO recovery algorithm.

26

• Checkpoints
• Problems in recovery procedure are
• searching the entire log is time-consuming.
• we might unnecessarily redo transactions which
  have already.
• output their updates to the database.
• Streamline recovery procedure by periodically
  performing checkpointing.
• Output all log records currently residing in main
  memory onto stable storage.
• Output all modified buffer blocks to the disk.
• Write a log record lt checkpointgt onto stable
  storage.

27

• During recovery we need to consider only the most
  recent transaction Ti that started before the
  checkpoint, and transactions that started after
  Ti.
• Scan backwards from end of log to find the most
  recent ltcheckpointgt record .
• Continue scanning backwards till a record ltTi
  startgt is found.
• Need only consider the part of log following
  above start record. Earlier part of log can be
  ignored during recovery, and can be erased
  whenever desired.
• For all transactions (starting from Ti or later)
  with no ltTi commitgt, execute undo(Ti). (Done only
  in case of immediate modification.)
• Scanning forward in the log, for all transactions
  starting from Ti or later with a ltTi commitgt,
  execute redo(Ti).

28

• Example of Checkpoints
• T1 can be ignored (updates already output to disk
  due to checkpoint)
• T2 and T3 redone.
• T4 undone

Tf
Tc
T1
T2
T3
T4
system failure
checkpoint
29

• Shadow Paging
• Shadow paging is an alternative to log-based
  recovery this scheme is useful if transactions
  execute serially.
• Idea maintain two page tables during the
  lifetime of a transaction the current page
  table, and the shadow page table.
• Store the shadow page table in nonvolatile
  storage, such that state of the database prior to
  transaction execution may be recovered.
• Shadow page table is never modified during
  execution
• To start with, both the page tables are
  identical. Only current page table is used for
  data item accesses during execution of the
  transaction.
• Whenever any page is about to be written for the
  first time
• A copy of this page is made onto an unused page.
• The current page table is then made to point to
  the copy
• The update is performed on the copy

30
Sample Page Table
31
Example of Shadow Paging
Shadow and current page tables after write to
page 4 .
32

• To commit a transaction
• 1. Flush all modified pages in main memory to
  disk
• 2. Output current page table to disk
• 3. Make the current page table the new shadow
  page table, as follows
• keep a pointer to the shadow page table at a
  fixed (known) location on disk.
• to make the current page table the new shadow
  page table, simply update the pointer to point to
  current page table on disk
• Once pointer to shadow page table has been
  written, transaction is committed.
• No recovery is needed after a crash new
  transactions can start right away, using the
  shadow page table.
• Pages not pointed to from current/shadow page
  table should be freed (garbage collected).

33

• Advantages of shadow-paging over log-based
  schemes
• no overhead of writing log records
• recovery is trivial
• Disadvantages
• Copying the entire page table is very expensive
• Can be reduced by using a page table structured
  like a B-tree.
• No need to copy entire tree, only need to copy
  paths in the tree that lead to updated leaf nodes
• Commit overhead is high even with above
  extension.
• Need to flush every updated page, and page table.
• Data gets fragmented (related pages get separated
  on disk).
• After every transaction completion, the database
  pages containing old versions of modified data
  need to be garbage collected.
• Hard to extend algorithm to allow transactions to
  run concurrently.
• Easier to extend log based schemes.

34

• Failure with Loss of Nonvolatile Storage
• So far we assumed no loss of non-volatile storage
• Technique similar to checkpointing used to deal
  with loss of non-volatile storage
• Periodically dump the entire content of the
  database to stable storage
• No transaction may be active during the dump
  procedure a procedure similar to checkpointing
  must take place
• Output all log records currently residing in main
  memory onto stable storage.
• Output all buffer blocks onto the disk.
• Copy the contents of the database to stable
  storage.
• Output a record ltdumpgt to log on stable storage.

35

• To recover from disk failure
• restore database from most recent dump.
• Consult the log and redo all transactions that
  committed after the dump.
• Can be extended to allow transactions to be
  active during dump known as fuzzy dump or online
  dump.