Lesson 1

This course Backup and Recovery Concepts, is the first of three in the Oracle Backup Recovery series.

1. Second Course
2. Third Course

Taken together these three courses will help you to plan and implement a backup and recovery strategy for your Oracle database.
Course Goals:
The first course in this series will provide a good understanding of the issues involved in defining an effective backup and recovery strategy. By the end of this course, you should be able to:

1. List the key issues involved when defining an effective backup and recovery strategy
2. List the Oracle architecture components related to backup and recovery operations
3. List the components of the recovery manager architecture

In this course, you will learn and practice Oracle Backup and Recovery skills using diagrams, exercises and quizzes.

The database files include data segments, redo logs, rollback segments, control files, libraries, and system areas. Each of these files is not a separate entity but is tightly linked to the components. For instance, the data files are repositories for all table data. The data file structure is controlled by the control file, implemented by the system areas, and maintained by a combination of the executables, redo, and rollback segments. Data files reference bfiles^[1] that are tied to external procedures stored in libraries that are referenced in procedures stored in data files. This complexity leads to the requirement of a threefold backup recovery methodology to ensure that data recovery can be made.
Oracle Recovery Manager (RMAN) is the recommended backup tool
Oracle Recovery Manager (RMAN) is the recommended backup tool for Oracle versions 12c to 19c. RMAN provides a more comprehensive and powerful set of backup and recovery features than Oracle Backup Manager
Oracle Backup Manager (OBM) is no longer the primary backup tool for Oracle Database 13c and later.
Here is a table that summarizes the differences between (OBM) and Oracle Backup Manager and RMAN:

Feature	OBM	RMAN
Backup type	Full, incremental	Full, incremental, differential, backup sets
Recovery type	Full, point-in-time	Full, point-in-time, partial
Automation	Limited	Extensive
Features	Basic	Comprehensive

As you can see, RMAN is a more powerful and versatile backup tool than OBM. It is also more closely integrated with Oracle Database 13c and later, which means that it can take advantage of new features and enhancements in these versions. If you are not familiar with RMAN, there are many resources available to help you learn how to use it. Oracle provides extensive documentation, training, and support for RMAN. There are also many third-party books and blogs that can help you get started with RMAN.

Normal system backups, referred to as either

1. hot or
2. cold backups,

are used to protect the system from media failure. Each can and should be used when required. Cold Backups A cold backup, that is, one done with the database in a shutdown state, provides a complete copy of the database that can be restored exactly. The generalized procedure for using a cold backup is as follows:

1. Using the shutdown script(s) provided, shutdown the Oracle instance(s) to be backed up.
2. Ensure that there is enough backup media to back up the entire database.
3. Mount the first volume of the backup media using the proper operating system mount command:

For example on OpenVMS:

$ mount/foreign dev: volume_name 

On UNIX:

$ umount ?orw /dev/rmt0 /tape1 

4. On UNIX:
   

    $ tar ?cvf  /tape1 /ud*/oracle*/ortest1/* 
   

   (for all Oracle data, log and trace files assuming an OFA installation) Where: tar ? this is short for tape archiver and is the default backup command on UNIX, raw volumes may require

   "dd" -cvf ? 
   

   These arguments tell tar to c: create a new archive, v: tell us what it is doing, f: use the device specification which follows (we could have not specified a device and it would default to the default tape drive)
   
   5. Once the backup is complete, be sure all backup volumes are properly labeled and stored, away from the computer. The final volume is dismounted from the tape drive using the appropriate operating system DISMOUNT command:
   
   For example on OpenVMS:
   

   $ DISMOUNT dev:
   

   
   On UNIX:
   

   $ umount /tape1
   

   6. Restart the Oracle instances using the appropriate startup script(s).

A hot backup, or one taken while the database is active, can only give a read-consistent copy^[2] but does not handle active transactions. You must ensure that all redo logs archived during the backup process are also backed up. The hot backup differs from the cold backup in that only sections of the database are backed up at one time. This is accomplished by using the ALTER command to modify a tablespace?s status to backup. Be sure that you restore the status to normal once the database is backed up or else redo log mismatch and improper archiving/rollbacks can occur.
While it is simple to do a cold backup by hand, a hot backup can be quite complex and should be automated.
The automated procedure should then be thoroughly tested on a dummy database for both proper operation and ability to restore prior to its use on the production database(s).
Limitations on hot or on-line backups:

• The database must be operating in ARCHIVELOG mode for hot backups to work.
• Hot backups should only be done during off or low-use periods.
• During the hot backups the entire block containing a changed record, not just the changed record, is written to the archive log, requiring more archive space for this period.

The hot backup consists of three processes:

1. The tablespace data files are backed up.
2. The archived redo logs are backed up.
3. The control file is backed up.

The first two parts have to be repeated for each tablespace in the database. For small databases, this is relatively easy. For large, complex databases with files spread across several drives, this can become a nightmare if not properly automated in operating system specific command scripts. As you can see, this is a bit more complex than a full cold backup and requires more monitoring than a cold backup. Recovery from this type of backup consists of restoring all tablespaces and logs and then recovering. You only use the backup of the control file if the current control file was also lost in the disaster; otherwise, be sure to use the most current copy of the control file for recovery operations.
In a number of computer facilities backups are kept close at hand, sometimes in the same room as the computer.
Question: What would happen if a site disaster destroyed the computerroom? Not only the hardware, but all of the system backups and your data could be lost. Store backups in another building or even totally off-site somewhere. This assures that come fire, flood, or typhoon, you should be able to get backup one way or another.
UNIX of course requires a different scripting language and command set. One problem with a canned script for hot backup is that they don?t automatically reconfigure themselves to include new tablespaces, or redo logs. The script shown below is an example of how to let Oracle build its own hot backup script using dynamic SQL and the data dictionary. This script is excerpted from Oracle Administrator from RevealNet, Inc.Version 99.2 (an online reference product).
The next lesson describes the prerequisites to this course.

[1]bfile: A bfile, is contained within the file system but outside the database.

[2]read-consistent copy: In the context of Oracle backups, a read-consistent copy is a backup of an Oracle database that is in a state that is consistent with the data that was visible to users at the time the backup was created. This means that the backup can be restored without any loss of data or data corruption.