1. Database recovery contd…

2. RECAP
RECAP

3. Database Backup Causes of failure:
Transaction failure
System/processor failure
Media failure
When secondary media (disk) fails, data may become unreadable.
We typically rely on backing up the database to cheaper magnetic tape or other backup medium for a copy that can be restored.
Challenge:
When an DBMS is running, it is not possible to backup its files (data files, system logs, redo logs, etc.) as the resulting backup copy on tape may be inconsistent.
“old practice”:
Shut down the DBMS (and thus all applications), do a full backup, copy everything on to tape. Then start up again.

4. Types of back up Logical (Hot or Cold)
Export facility
Physical (with or without a Recovery manager)
File system and SQL statements back up
Incremental versus full back up
Other than data, Other parts of the database to be backed up include the log files and any control files that monitor the state of the database

5. Follows something like:
Incremental
An Incremental backup will backup only those data changed or added since the last full backup. Sometimes called a delta backup.
Follows something like:
Weekend: Do a shutdown of the DBMS, and full backup of the database onto a fresh tape(s).
Nightly: Do an incremental backup onto different tapes for each night of the week.

6. Other parts of the database to be backed up include the log files and any control files that monitor the state of the database.
As with data files, it is not possible to obtain a consistent backup of these files while the database is live.
Most modern DBMS allow various portion of the database (such as an entire table space) to be taken off-line for backup purposes.
Oracle implements Archived Redo logs and table spaces that can be taken off- line:
At each database checkpoint, logs are copied to an archive.
Archived logs can be backed up while the database is running.
While the database is running, a table space can be taken off-line which prevents any updates from being applied to the associated data files.
Backups of data can be done in full or incremental mode.

7. Please see Database Backup Examples from the notes
MS Access
Microsoft SQL Server
Oracle

8. Discussion slides

9. Scenario:
You are a new hiring at a company – you realize that there isn’t a database back up strategy in place. What do you do?

10. Advisory note to your superior / ICT director may include/highlight:
Objectives of DB backup
Uses of a DB back up
Information of how to develop a back up and recovery strategy

11. Advisory note to your superior / ICT director may include/highlight:
Objectives of DB backup
Protect the database from numerous types of failures
Increase Mean-Time-Between-Failures (MTBF)
Decrease Mean-Time-To-Recover (MTTR)
Minimize data loss

12. A database backup will enable:
Archive historical data
Save table definitions (with or without data) to protect from user error failure
Move data between machines and databases or versions of a server (e.g. Oracle server)
Transport tablespaces between databases

13. Normally in binary formats
Data
Base
File *.dmp
Exp
Data
Base
Imp

14. Steps in developing a back up and recovery strategy
Identify the business requirements
E.g. Evolutionary process
Identify technical requirements
Hardware, software, man power and time
Database configurations
Transaction volume
Frequency of backups
Define operational requirements
7-day / 24-hour operations
Testing and validating backups

15. Back up and recovery strategy considerations
Identify critical data from the rest
Assess tolerance for data loss - Recovery Point Objective (RPO)
Assess tolerance for downtime - Recovery Time Objective (RTO)
Determine backup retention policy
Assess data protection requirements
What are example questions that you can raise for each consideration?

16. Back up and recovery strategy considerations
Identify critical data from rest
Design recovery requirements around data criticality
Assess tolerance for data loss - Recovery Point Objective (RPO)
How frequently should backups be taken?
Point-in-time recovery required?
Assess tolerance for downtime - Recovery Time Objective (RTO)
Downtime: Problem identification + recovery planning + systems recovery
Tiered RTO per level of granularity, e.g. database, tablespace, table, row

17. Backup and recovery strategy considerations
Determine backup retention policy
Onsite, offsite, long-term
Assess data protection requirements
Physical: Disasters, outages, failures, corruptions
Logical: Human errors, application errors

19. Your homework! Home work / self research Form groups for research
In your group, research and report in the next class what the following DBMSs in the market address recovery
MS Access
Oracle
MS SQL (Server)
MySQL
PostgreSQL
Due next week (a small write up + 5minutes presentation)
After the written CAT

20. Thanks