Overview of New Backup and
Recovery Capabilities for Oracle8™
An Oracle Technical White Paper
June 1997
INTRODUCTION
Very large database systems impose stringent requirements for backup and recovery operations. In many cases, the physical action of copying the database files can take many hours, due to the large size and number of files. Backups are an absolutely necessary part of managing a database system. Imagine the magnitude of lost revenue, not to mention customer dissatisfaction, if the production database of a point-of-sale system could not be recovered after a media loss. Key customer transactions, such as new orders, would be lost if there were no backups. Those orders would only be recoverable by manually re-entering them, if you were lucky enough to have a paper trail of all the lost orders.
Additionally, backup operations in many cases must be performed without any interruption to the business functions. Recovery operations must also be performed with minimal impact on the business processing. Due to the large size of databases, backup file sizes need to be proportional to the size of transactional changes on the system, not proportional to the size of the datafiles. Recovery time must also be proportional to the amount of data being recovered. These requirements are mandated to maintain a large production database system with maximum availability, scalability and reliability. A key to avoiding serious revenue and data loss, and avoiding extra expense of manual re-entry of data is to have a well defined backup and recovery strategy.
The new backup and recovery functionality of Oracle8 solves the problems of managing the backup and recovery operations.
Oracle8 provides an integrated method for creating, managing, and restoring backups of a database. A key objective of these improvements is to provide greater ease of management and administration of the backup and recovery operations, while maintaining superior performance and increased availability of the database. By incorporating the backup and recovery processing within the Oracle8 server, the server-managed backup and recovery feature provides these benefits:
Figure 1: Oracle8 backup architecture
AUTOMATES PROCESS OF BACKUP AND RECOVERY
In Oracle8 a key benefit of the backup and recovery feature is that it is fully managed by the server. This greatly minimizes the likelihood of database administrator (DBA) error in the backup or recovery steps, and frees the DBA from a substantial administrative task. The Oracle8 Recovery Manager utility manages the processes of creating backups and restoring and recovering from them. All of this work is done inside the Oracle8 system. In other database management systems, the backup and restore operations are manual tasks with limited functionality, done at the operating system level, and the DBA has to spend considerable time managing this process.
Restoring the database, or part of it, for recovery is very straightforward in Oracle8 because Recovery Manager finds the appropriate backups and restores them as needed. Recovery Manager automatically restores any archivelogs needed for recovery as well.
Eases Management of the Backup Process
Recovery Manager is a component of the backup and recovery system that manages backup creation, restoration, and recovery operations. With Recovery Manager, database administrator productivity goes up, and the frequency and severity of human errors goes down, because the database system is controlling and managing the backup and recovery operations. The work of actually creating backups and recovering with them is done inside the Oracle8 server itself. Recovery Manager maintains a recovery catalog that holds information about the backup files and archived redo log files, thereby freeing the DBA from having to track all the backup copies and archive logs. It then uses the recovery catalog to automate both restore and recovery operations, so there is no chance of accidentally restoring from the wrong backup.
Recovery Manager provides a way to:
NO SINGLE POINT OF FAILURE
Recovery Manager can maintain a recovery catalog containing information about the backup files and archived redo log files. This greatly simplifies the backup management for the DBA, since the database system is now keeping track of all the backups. The recovery catalog minimizes the likelihood of administrator error, since the system determines which backups to restore from, and which archivelogs are needed to recover with that backup. The recovery catalog is used as a repository of information to automate both backup and restore operations, as well as recovery operations. Oracle8 can use one recovery catalog to manage multiple (local or remote) Oracle8 databases, thereby eliminating any possible single point of failure in the backup strategy.
The recovery catalog is stored in an Oracle8 database. The recommended approach is to use an alternate database to contain the recovery catalog for the target database being backed up. That way, a media loss on one database does not affect the recovery catalog, since it resides on a different database. For example, a production database can be backed up and managed with a recovery catalog that resides on a work station database, and that database can be backed up and managed with a recovery catalog that resides on the production database. This way, the work station and production databases can provide comprehensive backup facilities for each other. It is critical that the recovery catalog be backed up also, to avoid any possibility of it being a single point of failure. It can then be backed up and recovered using the Recovery Manager facility of Oracle8, since it resides in an Oracle8 database.
Larger sites with multiple Oracle8 systems installed may create one recovery catalog to maintain backup and recovery information for all their Oracle8 databases. This greatly simplifies maintenance and administration of multiple databases. The recovery catalog can also be located in a remote site, separate from the target database or databases. This helps minimize the impact of any failure, since it is then very unlikely that a recovery operation will be needed on the target database while there is a simultaneous failure of the remote recovery catalog database. The database server performs various integrity checks on the backup files used for a restore operation.
COMPREHENSIVE REPORTS DESCRIBE BACKUP STATUS
Reports can be run against the recovery catalog to see, for example, which files need backing up and which backups are no longer required.
The recovery catalog contains:
SIMPLIFIED FOR SMALL DATABASES
The recovery catalog is optional in the backup and recovery strategy. Recovery Manager supports an operational mode where it obtains the recovery information needed from the control file. This mode is appropriate for small databases where installation and administration of another database to serve as the recovery catalog, would be burdensome, or in a case where the additional capabilities provided by the recovery catalog are not desired.
Some features are not available when operating without a recovery catalog:
BACKUP TYPES
Oracle8 supports three basic methods of backups:
A backup set contains one or more input files of the same type, either datafiles or archivelogs. This greatly simplifies backup file management, since multiple files may be backed up into one output file, so there are fewer files to store and manage. A particular backup file from the backup set must then be extracted with a restore operation by the Recovery Manager. Backup sets can be full or incremental backups of the files, taken while the database was open or closed.
A backup is made up of one or more datafiles that contains all blocks of the datafile that have ever been used. Oracle8 allows you to create and restore full backups of datafiles, tablespaces, archivelogs, control files, and the database in its entirety, for maximum manageability and flexibility.
An incremental backup is a backup of one or more datafiles that contains only those blocks, at the same or a lower level, that have been modified since a previous backup. File size of backups is greatly reduced, since only modified blocks need to be backed up, instead of all blocks of the datafiles. Oracle8 allows you to create and restore incremental backups of datafiles, tablespaces, and the database.
A datafile copy contains a single input datafile that can be used as-is to perform recovery. No restore operation is needed to use it, thereby saving the time normally needed to restore the file. Sites that require true high availability benefit from this feature, as this allows the system to become available for work as quickly as possible. This type of file is created by Recovery Manager as a "fuzzy" copy of a single file, taken, if desired, while the database is being updated. Simply point the control file directly at the backup copy and media recovery is performed to make the copy current. This type of backup is only allowed to disk, so the copy can be used "as is," without a restore operation. The recovery catalog is then updated to indicate that the copy has been "consumed," in other words, is no longer available for any future use as a backup. Not having to restore the backup file saves a great deal of time, and therefore makes the recovered data available faster. The only additional down time needed is the time required to do the actual recovery operation on that backup file. Operating system generated backups, created externally to Oracle are fully supported and usable under Oracle8 as well.
INCREASES AVAILABILITY WITH INCREMENTAL BACKUP AND RESTORE
The time it takes for backup and restore operations is relative to the amount of transactional data changed, not to the size of the datafiles themselves. This substantially reduces the time needed to take backups of very large datafiles, since there is no need to copy the entire file. Once a baseline level 0 backup has been taken, subsequent backups need only copy the changed portions of the datafiles, rather than copying the whole file whether data has been modified or not. These types of backups are called incremental backups.
Incremental backups are taken as part of a backup set. It contains a backup of one or more datafiles that contains only those blocks that have been modified since a previous backup at the same or lower level. The multi-level incremental backup feature allows you to create different levels of incremental backups. Each level is indicated by an integer, with level 0 being used to backup all used datafile blocks. An incremental backup at any particular level consists of those blocks that have been modified since the last backup at that level or lower.
Creating cumulative incremental backups reduces the work needed for a recovery operation. These backups ensure that you need only one incremental backup from any particular level at recovery time. However, cumulative backups require more space and time to create because they duplicate the work done by previous backups at the same level.
REDUCES BACKUP AND RECOVERY TIME WITH PARALLELIZATION OF OPERATIONS
When backing up multiple datafiles, Recovery Manager automatically reads them in parallel. This is important to keep an output device streaming continuously, helping minimize the time needed for the backup operation.
Recovery Manager uses asynchronous I/O to read the files and write to the output devices, if the platform supports it. You can use I/O slaves to take advantage of this performance improvement even in platforms that donÝt support asynchronous I/O.
Multiple backup or recovery sessions can be executed concurrently. Recovery Manager may parallelize its operation, establishing multiple logon sessions and conducting multiple conversations in parallel. Concurrent sessions must operate on disjoint sets of database files.
Parallelization of backup, copy, and restore commands is handled automatically by the Recovery Manager. Recovery Manager establishes one database connection to the target database for each sequential I/O device. The administrator only needs to specify a list of one or more sequential I/O devices, and the objects to be backed up, copied, or restored. Parallelism is exploited within the context of a single command. So, if copies of 10 datafiles are needed, it is better to issue a single COPY command that specifies all 10 copies, instead of 10 separate copy commands.
INCREASES AVAILABILITY WITH POINT IN TIME TABLESPACE RECOVERY
With Oracle8, you can perform a point in time recovery on a single tablespace, instead of taking the whole database back in time logically. This allows some applications to continue to operate while some other part of the database is being recovered, thereby allowing greater availability of the data. It is strongly recommended that this feature be used with the guidance of Worldwide Support, since it is possible that human error will cause database inconsistency when a tablespace point in time recovery is performed.
EASES THE USE OF ADMINISTRATION TOOLS
Oracle® Enterprise Manager supports all the Recovery Manager facilities and provides a graphical user interface (GUI) to make it easier to use the Recovery Manager commands. This helps save database administrator time. It also allows scheduling of backups during off-periods of the system. Backups can then be scheduled at night, when there may be less activity on the system.
A number of third-party vendors are integrating their products to support the Recovery Manager capabilities of Oracle8 using GUI interfaces to make working with Recovery ManagerÝs recovery processes easier and to make handling backups to disk and tape easier at the operating system (O/S) level.
MEDIA MANAGEMENT INTERFACE
Backing up files to tape is required in most backup scenarios. This minimizes expensive disk consumption and facilitates sending backups elsewhere for disaster recovery. Copying a sizable database to disk is prohibitively expensive in many cases. Backing up to tape is the reasonable alternative. Also, backup tapes of the database can then be sent to a secondary location for long term storage, so they are available in the event of a major failure at the primary site. Recovery Manager supports an application programming interface (API) for data movement between Oracle and other vendors' products. This provides the integration with tape management systems necessary for backup and recovery.
In most cases, there is no need to invest in new media management software packages. Oracle8Ýs backup and recovery facilities interface with most existing media management packages.
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
+1.415.506.7000
Fax +1.415.506.7200
http://www.oracle.com
Contributors:
Editors:
Copyright © Oracle Corporation 1997
All Rights Reserved
This document is provided for informational
purposes only, and the information herein is subject to change without
notice.
Please report any errors herein to Oracle Corporation. Oracle
Corporation does not provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark and Enabling the Information Age, Oracle8, and Oracle Enterprise Manager are trademarks of Oracle Corporation.
All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective