1. Backup and Recovery (1)
Oracle 10g
Hebah ElGibreen
CAP364

2. Outline Introduction Backup and Recovery, Why?
Principle of Backup and Recovery
Backup
Backup Solutions: Overview
Backup Methods
Backup Strategies (Choosing the right backup)
Configuring for Recoverability
Enterprise Manager:
Configuring Backup
Schedule Backup
Managing Backup
Viewing Backup Job
Practice
Recovery (Next Lecture…)
CAP364
Hebah ElGibreen

3. Introduction
Backup and recovery refers to the various strategies and procedures involved in protecting your database against data loss and reconstructing the database after any kind of data loss.
CAP364
Hebah ElGibreen

4. Backup and Recovery, Why?
The database administrators goal is to ensure that the database is open and available when users need it.
Failures can generally be divided into the following categories:
Statement failure
User process failure
Network failure
User error
Instance failure
Media failure
• Statement failure: A single database operation (select, insert, update, or delete) fails. DBA’s may be needed to correct errors with user privileges or database space allocation.
• User process failure: A single database session fails. DBA’s action is not usually needed to resolve user process failures. Instance background processes roll back uncommitted changes and release locks.
• Network failure: Connectivity to the database is lost. Solution provided by changing on network connections.
• User error: A user successfully completes an operation, but the operation (dropping a table or entering bad data) is incorrect. DBA may need to assist the users in recovering from the error.
• Instance failure: The database instance shuts down unexpectedly. DBA’s involvement is usually limited to restarting the instance and working to prevent future occurrences. Recovering from instance failure is automatic (i.e. need for automatic recovery).
• Media failure: One or more of the database files are lost (that is, the files have been deleted or the disk has failed). DBA is required to restore and recover the missing files (i.e. need for backup and recovery).
CAP364
Hebah ElGibreen

5. Principle of Backup and Recovery
Reconstructing the contents of all or part of a database typically involves two phases:
Retrieving a copy of the data file from a backup.
Reapplying changes to the file, to bring the database to a desired SCN since the last backup.
Retrieving:
To restore a data file or control file is to retrieve the file onto disk from a backup location on tape, disk or other media, and make it available to the database server.
Reapplying:
To recover a data file is to take a restored copy of the data file and apply to it changes recorded in the database's redo logs.
CAP364
Hebah ElGibreen

6. Principle of Backup and Recovery
In this example a full backup of a database (copies of its datafiles and control file) is taken at SCN 100. Redo logs generated during the operation of the database capture all changes that occur between SCN 100 and SCN 500. Along the way, some logs fill and are archived.
At SCN 500, the datafiles of the database are lost due to a media failure.
The database is then returned to its transaction-consistent state at SCN 500, by restoring the datafiles from the backup taken at SCN 100, then applying the transactions captured in the archived and online redo logs and undoing the uncommitted transactions.
CAP364
Hebah ElGibreen

7. Backup Solutions: Overview
Backups can be performed by using:
Recovery Manager
Oracle Secure Backup
A user-managed scenario
Recovery Manager (RMAN) is the recommended method of backing up Oracle database. The backup tool Recovery Manager, known more commonly as RMAN, provides many advantages over other forms of backup.
Oracle Secure Backup complements existing functionality by adding backup to tape and network backup capabilities.
User- managed Backups are based on scripts, which a DBA would have to write. This option is not preferable because it is more labor intensive.
CAP364
Hebah ElGibreen

8. Backup Methods Logical Backup (User level)
Export Backup
Import Backup
Physical Backup (DBA centric)
Offline Backup (cold backup)
Online Backup (hot backup)
Oracle supports many different forms of backup and recovery. Some of them can be managed at the user level; most of them are strictly DBA-centric and using operating system commands or the RMAN utility.
Logical Backup of a database involves reading a set of database records and writing them to a file. These records are read independently of their physical location. In Oracle, the Data Pump Export utility performs this type of database backup.
Export/Import Backup is considered a logical backup, because the underlying storage characteristics of the tables are not recorded, only the table metadata, user privileges, and table data.
For restoring from a database export, the import command takes a binary format file created by export and imports it into the database with the assumption that the users in the exported database tables exist in the database where the import command is performed.
Physical backups involve copying the files that constitute the database. These backups are also referred to as file system backups because they involve using operating system file backup commands. It consists of two modes: Offline and Online.
Offline backup occur when the database has been shut down normally (that is, not due to instance failure). Once the copy operation is complete, the database instance can be started.
Online Backup: If a database is in archivelog mode, it is possible to do online backups of the database. The database can be open and available to users even while the backup is in process. The procedure for doing online backups is as easy as placing a tablespace into a backup state, backing up the datafiles in the tablespace with operating system commands, and then taking the tablespace out of the backup state.
When Oracle is run in ARCHIVELOG mode, the Archiver background process makes a copy of each redo log file before overwriting it. These archived redo log files are usually written to a disk device. The database can be fully recovered from an online backup, and it can, via the archived redo logs, be rolled forward to any point in time before the failure. When the database is then opened, any committed transactions that were in the database at the time of the failure will have been restored, and any uncommitted transactions will have been rolled back.
CAP364
Hebah ElGibreen

9. Backup Strategies … Choosing the right backup
Tape vs. Disk Backups
Physical vs. Logical Backups
Whole vs. Partial Backups
Consistent vs. Inconsistent Backups
Full vs. Incremental Backups
Hot vs. Cold Backups
Image Copies vs. Backupsets
An appropriate backup strategy is one that meets the needs of the business while remaining cost- effective.
RMAN supports a number of different backup methods, depending on your availability needs, the desired size of your recovery window, and the amount of downtime you can endure while the database or a part of the database is involved in a recovery operation.
CAP364
Hebah ElGibreen

10. Backup Strategies … Choosing the right backup
Tape vs. Disk Backups
A common practice is to make backup copies on disk when possible and have them copied to tape in a separate operation.
Physical vs. Logical Backups
A logical backup can be much smaller than physical backup.
Logical backups cannot be used to restore the database; they can only be used to re-create the data.
If the database is restored from physical backups, then the redo logs can be used to recover all modifications to the data made since the physical backup was initiated.
If a logical backup is used to re-create data, any modifications to the data made after the logical backup was initiated are lost (i.e. “point in time” backup).
CAP364
Hebah ElGibreen

11. Backup Strategies … Choosing the right backup
Whole vs. Partial Backups
If the database is very large, we may not have the time and resources to create a backup of the entire database in a single operation.
Instead, we might spread the activity over the course of a week and create a backup of just a portion of the database every night.
Consistent vs. Inconsistent Backups
Consistent backups are taken when the database is shut down normally or in a MOUNT state.
A database must be in ARCHIVELOG mode to use an inconsistent backup method.
Whole vs. Partial Backups
A whole database backup includes all data files and at least one control file.
Partial database backups may include zero or more tablespaces, zero or more data files, and may or may not include a control file.
Consistent vs. Inconsistent Backups: A physical backup can be classified by being a consistent or an inconsistent backup.
In a consistent backup, all datafiles have the same SCN (i.e. all changes in the redo logs have been applied to the datafiles). Because an open database with no uncommitted transactions may have some dirty blocks in the buffer cache, it is rare that an open database backup can be considered consistent.
Inconsistent backup is performed while the database is open and users are accessing the database. Because the SCNs of the datafiles typically do not match when an inconsistent backup is taking place, a recovery operation performed using an inconsistent backup must rely on both archived and online redo log files to bring the database into a consistent state before it is opened.
CAP364
Hebah ElGibreen

12. Backup Strategies … Choosing the right backup
Full vs. Incremental Backups
A distinct advantage to using an incremental backup in a recovery strategy is that archived and online redo log files may not be necessary to restore a database or tablespace to a consistent state.
Full vs. Incremental Backups
Full backup: Full backups make a copy of each data block that contains data and which is within the files being backed up. Either RMAN or an operating system command can be used to perform a full backup.
Incremental Backup: Incremental backups make a copy of all data blocks that have changed since some previous backup.
Oracle Database 10g supports two levels of incremental backup (0 and 1).
A level 0 or baseline backup, like a full backup, contains all data blocks.
A level 1 incremental back up can be one of two types: cumulative or differential.
A cumulative backup backs up all changes since the last level 0 backup.
A differential backup backs up all changes since the last incremental backup (which could be a level 0 or a level 1).
CAP364
Hebah ElGibreen

13. Backup Strategies … Choosing the right backup
Hot vs. Cold Backups
Cold backups are similar to export backups because they are point-in-time backups and therefore of less value if up-to-the minute recovery of the database is required and the database is not in archivelog mode.
Another downside to cold backups is the amount of downtime necessary to perform the backup; any one will not be able to access the database during it.
Hot backups are inconsistent because, with the database open, there is no guarantee that the data files are synchronized with the control files. Inconsistent backups require recovery in order to be used.
Hot vs. Cold Backups
Hot backup are generally considered synonymous with inconsistent backup, while cold backup are considered synonymous with consistent backup. However, if the database was not shut down gracefully, a cold backup also may contain inconsistencies.
CAP364
Hebah ElGibreen

14. Backup Strategies … Choosing the right backup
Image Copies vs. Backupsets
Backup sets use less space on the disk or tape and it can be compressed to further reduce the space requirements of the backup.
Backupsets can be created and restored only with RMAN.
Image copies are full backups created by almost any backup environment (e.g. RMAN or operating system commands).
Backup set
Data file #1
Data file #2
Data file #3
Data file #4
Data file #5
Data file #6
Image copies
Data file #1
Data file #4
Image Copies vs. Backupsets
Image copies are duplicates of data or archived log files.
Backup sets are collections of one or more binary files that contain one or more data or archived log files.
Data file #2
Data file #5
Data file #3
Data file #6
CAP364
Hebah ElGibreen

15. Configuring for Recoverability
To configure your database for maximum recoverability, you must:
Schedule regular backups
Multiplex control files
Multiplex redo log groups
Retain archived copies of redo logs
Control files
Group 1
Group 2
Group 3
Disk 1
Disk 2
Member 1
Member 2
Schedule regular backups
Oracle provides an “easy” button for backups. If you do not enable backups when the database is created, you can use Enterprise Manager later to do so.
Multiplex control files
Since all control files within a database are identical then recovery is a simple matter of copying one of the other control files.
Multiplex redo log groups
You can multiplex your redo log by adding a member to an existing log group. It is recommended that you store members on separate drives to protect against total loss of the redo log entries in the event of a disk failure.
Retain archived copies of redo logs
To preserve redo information, create archived copies of redo log files. Database must be in ARCHIVELOG mode.
Online redo log files
Archive log files
CAP364
Hebah ElGibreen

16. References
“Beginning Oracle Database 11g Administration: From Novice to Professional”, By Iggy Fernandez, Apress.
Backup and Recovery Basics 10g Release 2, By Antonio Romero, Lance Ashdown, Oracle® Database, 2005.
Oracle Database 10g: Administration Workshop I, student guide.
CAP364
Hebah ElGibreen