1. Database Backup and recovery
CSD305 Advanced Databases

2. Agenda Why recover? Simple backup strategy
Why we need a better strategy
Static checkpoints
The Log file
Rolling back a transaction
Rolling back multiple transactions
Journals and the Archiver process
Rolling forward
Summary
CSD305 Advanced Databases

3. Why recover? Transaction level problems System level problem
program failure
user abandons processing
client becomes disconnected
System level problem
database server failure
power failure
Really nasty problems
physical disk damage
database inconsistencies that aren’t detected immediately
CSD305 Advanced Databases

4. Simple backup strategy
backup process
find quiet point in database activity
close down the database
copy the database files to another device
preferably to a medium you can store in a fire safe
restart the database
in case of failure
copy the database files back
restart the database server
cycle your backup media to keep multiple backup versions
CSD305 Advanced Databases

5. Why we need a better strategy
we can only recover to the last backup
database don’t always have quiet points
we’re relying on the OS file system for security
database system is an integrated collection of data (files aren’t)
A better strategy will
allow the DBMS to co-ordinate backup and recovery
allow backups to be taken at any time
recover from any individual transactions which fail
recover to any moment in time
CSD305 Advanced Databases

6. Static checkpoints A checkpoint is a static snapshot of your database
It’s controlled by database server processes
It will wait for transactions to complete to establish a quiet point
Multiple versions are catered for
Checkpoint files should be stored on a different device from database files
ROLLFORWARDDB will restore the database to the last checkpoint state
CSD305 Advanced Databases

7. The Log File
a log file is used to record the effects of update transactions
a single system-wide file controlled by the run-time DBMS
the file contains a collection of before-images and after-images that can be used to aid recovery
the log file is periodically inspected by an archiver process that:
removes records relating to committed transactions
transfers after-images to journal file if required
CSD305 Advanced Databases

8. Log file example
CSD305 Advanced Databases

9. Rolling back a transaction
If a program fails or a user aborts a transaction: the before-images in the log file are used to “undo” the effects of the transaction
inserted records are deleted
updates are undone
deleted records are reinstated
CSD305 Advanced Databases

10. Rolling back multiple transactions
In the case of a system failure (e.g. powercut) where no damage has been done to persistent data: the log file is used to “undo” all uncommitted transactions
CSD305 Advanced Databases

11. Journals and the Archiver process
The Archiver process removes completed transactions from the log file
If journaling is switched on for a database
a journal file will be created for the database
log entries will be copied to the journal before deletion from the log file
CSD305 Advanced Databases

12. Rolling forward
With journals in place the database can be recovered to its last consistent state
ROLLFORWARDDB recovers the database by:
restoring the database from the last checkpoint
applying the journal records to the database
CSD305 Advanced Databases

13. Summary
Database systems provide sophisticated facilities to enable recovery from failure
These facilities require careful management within a well-planned recovery strategy
Systems differ in their recovery requirements. The Database Administrator must decide:
how often to take checkpoints
whether journaling is required
what devices are used for recovery
where media are stored and when they are re-used
how often databases are checked for internal consistency
and much more ...
CSD305 Advanced Databases