Checkpointing is used to improve database recovery time. It periodically writes uncommitted transaction logs and dirty database pages to stable storage. This allows transactions committed before the last checkpoint to be ignored during recovery. Recovery involves undoing uncommitted transactions and redoing committed ones since the last checkpoint using the write-ahead logging protocol to ensure crash consistency. Shadow paging is an alternative technique that maintains a shadow page table to recover the pre-transaction state if needed. Automated backups and mirroring can further improve availability.

1. Presentation Topic:
Backing Up and
Recovery Procedure
1

2. Contents
• Backup and Recovery
• Checkpoints
• Action performed during checkpoints
• Log -Record Buffering
• Write -Ahead Log Protocol
• Shadow Paging Technique
• Recovery Facilities
• Recovery and Restart Procedures
2

3. 3

4. Stay Strong
Because
Recovery is Possible
4

5. Backup and Recovery
Backup and recovery is brought to
mind whenever there is potential
outside threats to a database.
Backup management refers to the
data safety.
5

6. Checkpoints
• To recover the database after some failure
we must consult the log record to determine
which transaction needs to be undone and
redone. For this we need to search the entire
log to determine this information. There are
two major problems with this approach.
1. The search process is time-consuming.
2. Most of the transactions need to redone
have already written their updates into the
database.
6

7. Checkpoints
• Although redoing them will cause no harm, but it
will make recovery process more time
consuming.
• To reduce these types of overhead, we introduce
Check points. The system periodically performs
Checkpoints.
• The log file may grow too big to be handled at all.
• Checkpoint is a mechanism where all the
previous logs are removed from the system and
stored permanently in a storage disk.
7

8. Actions Performed During
Checkpoints
• Output onto stable storage all log records currently residing in
main memory.
• Output on the disk all modified buffer blocks.
• The presence of a <checkpoint> record makes recovery process
more streamline.
• Consider a transaction Ti that committed prior to the
Checkpoint, means that <Ti, Commit> must appear in the log
before the<checkpoint> record.
• Any database modifications made by Ti must have been
written to the database either prior to the checkpoint or as
part of checkpoint itself.
8

9. Actions Performed During
Checkpoints
• Thus, at recovery time, there is no need to perform a redo
operation on Ti.
• The checkpoint record gives a list of all transactions that
were in progress at the time the checkpoint was taken.
Thus, the checkpoints help the system to provide
information at restart time which transaction to undo and
which to redo.
9

10. 10

11. Example (contd..)
• A system failure has occurred at time tf
• The most recent checkpoint prior to time tf was taken at time tc
• Transactions of type T1 completed (successfully) prior to time tc
• Transactions of type T2 started prior to time tc and
completed(successfully) after time tc and before time tf
• Transactions of type T3 also started prior to time tc but did not
complete by time tf
• Transactions of type T4 started after time tc and
completed(successfully) before time tf.
• Finally, transactions of type T5 also started after time tc, but did
not complete by time tf
11

12. Example (contd..)
• It should be clear that, in case of immediate modification
technique those transactions that have <Ti, start> and <Ti,
commit> must be redo and those transactions that have only
<Ti, start> and no <Ti, commit> must be undo.
• Thus, when the system is restarted in case of immediate
database modification, transactions of types T3 and T5 must
be undone, and transactions of types T2 and T4 must be
redone. Note, however that transactions of type T1 do not
enter in the restart process at all, because their updates were
forced to the database at time tc as part of the checkpoint
process.
12

13. Log-Record Buffering
• As, we assumed earlier that every log record is output to
stable storage at the time it is created. This assumption
imposes a high overhead on system execution for the
following reasons:
• Output to stable storage is performed in units of blocks. In
most cases, a log record is much smaller than a block. Thus,
the output of each log record translates to a much larger
output at the physical level.
13

14. Log-Record Buffering
• To do so, we write log records to a log buffer in main memory,
where they stay temporarily until they are output to stable
storage.
• Multiple log records can be gathered in the log buffer and
output to stable storage in a single output operation. The
order of log records in the stable storage must be exactly the
same as the order in which they execute.
• The cost of performing the output of a block to storage is
sufficiently high that it is desirable to output multiple log
records at once.
14

15. Log-Record Buffering
• Due to the use of log buffering a log record may reside in only
main memory (volatile storage) for a considerable time before it
is output to stable storage. Since such log records are lost if the
system crashes, we must impose additional requirements on the
recovery techniques to ensure transaction atomicity.
• Transaction Ti enters the commit state after the <Ti commit> log
record has been output to stable storage.
15

16. Log-Record Buffering
• Before the <Ti commit> log record can be output to stable
storage, all log records pertaining to transaction Ti must have
been output to stable storage.
• Before a block of data in main memory can be output to the
database (in nonvolatile storage), all log records pertaining to
data in that block must have been output to stable storage.
The latter rule is called the write-ahead logging (WAL) rule.
16

17. Write-Ahead Log Protocol
• Before writing a transaction to disk, every update log
record that describes a change to this page must be
forced to stable storage.
• This is accomplished by forcing all log records to
stable storage before writing the transaction to disk.
• WAL is the fundamental rule that ensures that a
record of every change to the database is available
while attempting to recover from a crash. 17

18. Write-Ahead Log Protocol
• In computer science, write-ahead logging (WAL) is
a family of techniques for providing
atomicity and durability (two of
the ACID properties) in database systems. Usually
both redo and undo information is stored in the
log.
• Note that the definition of a committed
transaction is effectively “a transaction whose log
records, including a commit record, have all been
written to stable storage”.
18

19. page 3
page 2
page 4
page 1
page 5
page 6
Recovery: Shadow Paging
Technique
• The database is considered to be
made up of a number of n fixed-
size disk blocks or pages, for
recovery purposes.
• Current page table points to most
recent current database pages on
disk.
• When transaction starts both page
tables are identical for that
transaction.
2
1
3
4
5
6
Shadow page
table
Current
Page table
19

20. page 5 (old)
page 1
page 4
page 2 (old)
page 3
page 6
page 2 (new)
page 5 (new)
2
1
3
4
5
6
Currentpage table
(after updating pages
2,6)
Database data pages (blocks)
2
1
3
4
5
6
Shadowpage table
(notupdated)
Shadow Paging Technique
When a transaction
begins executing
– Once the operations(
write or update) are
completed the current
page table is copied into
a shadow page table.
– shadow page table is
then saved
– shadow page table is
never modified during
transaction execution.
– Current page may
changed during
transaction execution.
20

21. Shadow Paging Technique
• To recover from a failure
– the state of the database before
transaction execution is available
through the shadow page table
– free modified pages
– discard current page table
– that state is recovered by reinstating
the shadow page table to become
the current page table once more
• Committing a transaction
– discard previous shadow page
– free old page tables that it
references
• Garbage collection
page5(old)
page1
page4
page2(old)
page3
page6
page2(new)
page5(new)
2
1
3
4
5
6
Currentpagetable
(afterupdating pages
2,6)
Databasedata pages (blocks)
2
1
3
4
5
6
Shadowpagetable
(notupdated)
21

22. Shadow paging Technique
• 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.
• writes operations—new copy of page is created and current
page table entry modified to point to new disk page/block.
22

23. Shadow Paging Technique
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
• If the shadow is stored in nonvolatile memory and a system
crash occurs, then the shadow page table is copied to the
current page table. This guarantees that the shadow page
table will point to the database pages corresponding to the
state of the database prior to any transaction that was active
at the time of the crash, making aborts automatic.
23

24. Shadow paging Technique
--
Advantages:
-No overhead of writing log records
-Recovery is faster
Disadvantages:
-Copying the entire page table is very expensive
24

25. Backup Facilities
• The facilities provided by DBMS is to produce a back-up
copy (or save) of the entire database.
• DBMS normally provides a COPY utility for backup
• The back-up facility should create a copy of related
database objects including the database indexes, source
libraries, and so on
Recovery Facilities
25

26. Backup Facilities
• It should be periodic. and produced a back-up copy at
least once per day.
• The copy should be stored in a secured location where it
is protected from loss or damage.
• The back-up copy is used to restore the database in the
event of hardware failure, catastrophic loss, or damage.
Recovery Facilities
26

27. Backup Facilities
• Some DBMSs provide back-up utilities for the DBA;
• And some systems assume the DBA will use the operating
system commands, export commands, or SELECT ... INTO
SQL commands to perform backups.
Recovery Facilities
27

28. Backup Facilities
• Performing the nightly backup for a particular database is
repetitive, creating a script that automates regular backups will
save time.
• In a large databases, regular full backups may be impractical,
because the time required to perform the backup may exceed
that available.
Recovery Facilities
28

29. Backup Facilities
• Cold backup–database is shut down during backup
• Hot backup–selected portion is shut down and backed up at a
given time
Recovery Facilities
29

30. Recovery Manager
• It is a module of the DBMS that restores the database to a
correct condition when a failure occurs and then resumes
processing user requests.
• The type of restart used depends on the nature of the failure.
Recovery Facilities
30

31. Recovery and Restart Procedures
• Disk Mirroring
• Restore/Rerun
• Maintaining Transaction Integrity
• Backward Recovery
• Forward Recovery
Recovery Facilities
31

32. Recovery and Restart Procedures
Disk Mirroring
• To be able to switch to an existing copy of
the database, the database must be mirrored.
• At least two copies of the database must be
kept and updated simultaneously. When a
media failure occurs, processing is switched to
the duplicate copy of the database.
• This technique allow the faster recovery.
Recovery Facilities
32

33. Recovery and Restart Procedures
Disk Mirroring
Recovery Facilities
33

34. Recovery and Restart Procedures
 Restore/Rerun
• It involves reprocessing the day's transactions (up
to the point of failure) against the back-up copy of
the database or portion of the database being
recovered.
• First, the database is shut down, and then the most
recent copy of the database or file to be recovered
(say, from the previous day).
Recovery Facilities
34

35. Recovery and Restart Procedures
 Restore/Rerun
• Advantages
• Simplicity
• No need to create a database change journal or log
file.
• Disadvantages
• New transaction can not performed until the
recovery is completed.
Recovery Facilities
35

36. Recovery and Restart Procedures
 Transaction Integrity
• A DBMS provides facility of transaction boundary
for maintaining transaction integrity.
• Transaction boundaries are logical beginning and
end of transactions.
• If the transaction are successful then they are
commits and if transaction fails at any point then
they are aborted.
Recovery Facilities
36

37. Recovery and Restart Procedures
 Backward Recovery
• It is a recovery technique in which unwanted
changes made to database are undo.
• Rollback: apply before images
• When certain transactions are abnormally
terminated then DBMS recover the database to an
earliest state by applying images records.
Recovery Facilities
37

38. Recovery and Restart Procedures
 Backward Recovery
Recovery Facilities
38

39. Recovery and Restart Procedures
 Forward Recovery
(Roll Forward)–apply after images
• Starts with an earlier copy of the database. After-
images (the results of good transactions) are
applied to the database, and the database is
quickly moved forward to a later state.
Recovery Facilities
39

40. Recovery and Restart Procedures
Forward Recovery
Recovery Facilities
40

41. 41

42. References
• http://www.scribd.com/doc/52981523/Datab
ase-Recovery
• http://enggedu.com/tamilnadu/university_qu
estions/question_answer/be_nd_2007/5th_se
m/cse/CS1301/part_b/14_b_2.html
• http://www.scribd.com/doc/52981523/Datab
ase-Recover
42