Release 2 (9.2)
Part Number A96519-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Backup and Recovery Concepts Release 2 (9.2) Part Number A96519-01 |
|
This chapter introduces database concepts that are fundamental to backing up a database.
This chapter includes the following topics:
Backups of Oracle data are either physical or logical.
This section contains these topics:
In contrast to logical backups, physical backups are backups of physical database files: datafiles and control files. If you run the database in ARCHIVELOG mode, then the database also generates archived redo logs. You can back up the datafiles, control files, and archived redo logs. Backups of online redo logs are not supported, as explained in "Avoiding the Backup of Online Redo Logs".
Physical backups are divided into two categories: image copies and backups in a proprietary format. An image copy is an exact duplicate of a datafile, control file, or archived log. You can create image copies of physical files with operating system utilities or the RMAN COPY command, and you can restore them as-is without performing additional processing by using either operating system utilities or the RMAN RESTORE command.
|
Note: Unlike operating system copies, the RMAN |
The RMAN BACKUP command generates a backup set, which is a logical object containing one or more backup pieces. Each backup piece is a physical file in a proprietary, binary format. You must use RMAN to restore a backup set.
In contrast to physical backups, logical backups are exports of schema objects into a binary file. Import and Export are utilities used to move Oracle data in and out of Oracle schema. Export writes data from an Oracle database to binary operating system files. These export files store information about schema objects, for example, tables and stored procedures. Import is a utility that reads export files and restores the corresponding data into an existing database.
Although Import and Export are designed for moving Oracle data, you can also use them as a supplemental method of protecting data in an Oracle database. You should not use Import and Export as the sole method of backing up your data.
| See Also:
Oracle9i Database Utilities to learn more about logical backups |
This section includes these topics:
| See Also:
Oracle9i Database Utilities for information about logical backups |
A whole database backup includes backups of the current control file along with all datafiles. Whole database backups are the most common type of backup.
Whole database backups do not require you to operate the database in a specific archiving mode. Before performing whole database backups, however, be aware of the implications of backing up in ARCHIVELOG and NOARCHIVELOG modes (refer to "Database Archiving Modes").
Figure 2-1 illustrates the valid configuration options given the type of backup that is performed.
A whole database backup is either a consistent backup or an inconsistent backup. Whether or not a backup is consistent determines whether you need to apply redo logs after restoring the backup.
You can make backups of the entire database with the following methods:
BACKUP DATABASE commandCOPY DATAFILE command run against each datafile in the database, and the COPY CURRENT CONTROLFILE command run against the control fileA tablespace backup is a backup of the datafiles that constitute the tablespace. For example, if tablespace users contains datafiles 2, 3, and 4, then a backup of tablespace users backs up these three datafiles.
Tablespace backups, whether online or offline, are valid only if the database is operating in ARCHIVELOG mode. The reason is that redo is required to make the restored tablespace consistent with the other tablespaces in the database.
The only time a tablespace backup is valid for a database in NOARCHIVELOG mode is when the tablespace is currently read-only or offline-normal. These cases are exceptions because no redo is required to recover them.
For example, take the scenario depicted in Figure 2-2:
Because there were no changes to the offline tablespace between t + 5 and t + 10, no media recovery is needed. If you make the tablespace read/write at t + 15 and then subsequently attempt to restore the t + 5 backup, however, Oracle requires media recovery for the changes after t + 15. Hence, you can only open the database if all necessary redo is located in the online redo logs.
You can make backups of an individual tablespace with the following methods:
BACKUP TABLESPACE commandCOPY DATAFILE command run against each datafile in the tablespace
| See Also:
Oracle9i Recovery Manager User's Guide to learn how to make RMAN backups and copies, and Oracle9i Recovery Manager Reference for |
A datafile backup is a backup of a single datafile. Datafile backups, which are not as common as tablespace backups, are valid in ARCHIVELOG databases. The only time a datafile backup is valid for a database in NOARCHIVELOG mode is if:
You can make backups of an individual datafile using these methods:
BACKUP DATAFILE commandCOPY DATAFILE command, which produces a datafile copy
| See Also:
Oracle9i Recovery Manager User's Guide to learn how to make RMAN backups and copies, and Oracle9i Recovery Manager Reference for |
Backing up the control file is a crucial aspect of backup and recovery. Without an accessible control file, you cannot mount or open the database.
If you use RMAN as your backup and recovery solution, and if you run the CONFIGURE CONTROLFILE AUTOBACKUP command, then RMAN automatically backs up the control file whenever you run backup and copy jobs. This backup is called a control file autobackup. Because the autobackup uses a default filename, RMAN can restore this backup even if the RMAN repository is unavailable. Hence, this feature is extremely useful in a disaster recovery scenario.
You can make manual backups of the control file by using the following methods:
BACKUP CURRENT CONTROLFILE creates an RMAN-specific backup of the control file, and the COPY CURRENT CONTROLFILE command creates an image copy of the control file.ALTER DATABASE BACKUP CONTROLFILE makes a binary backup of the control file.ALTER DATABASE BACKUP CONTROLFILE TO TRACE exports the control file contents to a SQL script file. You can use the script to create a new control file. Trace file backups have one major disadvantage: they contain no records of archived redo logs, offline ranges for datafiles, and RMAN backups and copies. For this reason, binary backups are preferable.
| See Also:
Oracle9i Recovery Manager User's Guide to learn how to make RMAN backups and copies, and Oracle9i User-Managed Backup and Recovery Guide to learn how to make user-managed control file backups |
Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a backup through the most recent log, every log generated between these two points must be available. In other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then you must halt recovery at log 172 and open the database with the RESETLOGS option.
Because archived redo logs are essential to recovery, you should back them up regularly. If you use a media manager, then back them up regularly to tape.
You can make backups of archived logs by using the following methods:
BACKUP ARCHIVELOG commandBACKUP ... PLUS ARCHIVELOG commandCOPY ARCHIVELOG command
| See Also:
Oracle9i Recovery Manager User's Guide to learn how to back up archived logs, and Oracle9i User-Managed Backup and Recovery Guide to learn how to make user-managed archived log backups |
You can use RMAN or operating system commands to make an inconsistent backup or a consistent backup.
An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has shut down abnormally.
A consistent backup is a backup of one or more database files that you make after the database has been closed with a clean SHUTDOWN command. Unlike an inconsistent backup, a consistent, whole database backup does not require recovery after it is restored.
Whether you make consistent or inconsistent backups depends on a number of factors. If your database must be open and available all the time, then inconsistent backups are your only option. If there are recurring periods of minimal use, then you may decide to take regular consistent backups of the whole database and supplement them with online backups of often-used tablespaces.
A consistent backup of a database or part of a database is a backup in which all read/write datafiles and control files are checkpointed with respect to the same system change number (SCN). Oracle determines whether a restored backup is consistent by checking the datafile headers against the datafile header information contained in the control file.
The only way to make a consistent whole database backup is to shut down the database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or you issue a SHUTDOWN ABORT statement, then the database's datafiles are always inconsistent--unless the database is a read-only database. Instance recovery will be required at open time.
Oracle makes the control files and datafiles consistent to the same SCN during a database checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to them.
The important point is that you can open the database after restoring a consistent whole database backup without applying redo because the data is already consistent: no action is required to make the data in the restored datafiles correct. Hence, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery.
A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency. In NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs may not exist on disk.
An inconsistent backup is a backup in which all read/write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one read/write datafile header may contain an SCN of 100 while other read/write datafile headers contain an SCN of 95 or 90. Oracle cannot open the database until all of these header SCNs are consistent, that is, until all changes recorded in the online redo logs have been applied to the datafiles on disk.
If the database must be up and running 24 hours a day, 7 days a week, then you have no choice but to perform inconsistent backups of a whole database. For example, a backup of an offline tablespace in an open database is inconsistent with other tablespaces because portions of the database are being modified and written to disk while the backup of the tablespace is progressing. The datafile headers for the online and offline datafiles may contain inconsistent SCNs. You must run your database in ARCHIVELOG mode to make online backups of online datafiles.
If you run the database in ARCHIVELOG mode, then you can construct a whole database backup using backups of online datafiles taken at different times. For example, if your database contains seven tablespaces, and if you back up the control file as well as a different tablespace each night, then in a week you will back up all tablespaces in the database as well as the control file. You can consider this staggered backup as a whole database backup.
You have the option of making inconsistent closed backups if a database is backed up after a system crash or SHUTDOWN ABORT. This type of backup is valid if the database is running in ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.
|
Caution: Oracle strongly recommends that you do not make inconsistent, closed database backups in |
If you run the database in NOARCHIVELOG mode, then only back it up when you have closed it cleanly with the IMMEDIATE, NORMAL, or TRANSACTIONAL options. Inconsistent whole database backups of databases running in NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you restore it--an unlikely occurrence.
The reason that NOARCHIVELOG inconsistent backups are not recommended is that the datafile headers of the backed up files contain different SCNs (a normal shutdown guarantees the consistency of these SCNs), and because the database is in NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow you to back up a database that has been running in NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery.
The basic guideline is: if you run your database in NOARCHIVELOG mode, always have a backup that is usable without performing any recovery. This aim is defeated if you need to apply redo from logs to recover a backup.
After an online backup or inconsistent closed backup, always ensure that you have the redo necessary to recover the backup by archiving the unarchived redo logs. When the database is open, run the following SQL statement to force Oracle to switch out of the current log and archive it as well as all other unarchived logs:
ALTER SYSTEM ARCHIVE LOG CURRENT;
When the database is mounted, open, or closed, you can run the following SQL statement to force Oracle to archive all noncurrent redo logs:
ALTER SYSTEM ARCHIVE LOG ALL;
When the database is mounted, open, or closed, you can run the following SQL statement to archive a specific group, where integer is the number of the group:
ALTER SYSTEM ARCHIVE LOG GROUP integer;
After open or inconsistent closed backups, Oracle recommends backing up all archived logs produced during the backup, and then backing up the control file after the backup completes. If you do not have all archived redo logs produced during the backup, then you cannot recover the backup because you do not have all the redo records necessary to make it consistent. Having a control file backup generated after the completion of the database backup is helpful when using RMAN because the control file contains a record of the backup.
This section contains these topics:
You can back up all or specified datafiles of an online tablespace while the database is open, but only when the database runs in ARCHIVELOG mode. In this case, Oracle can write changes to the online datafiles while the backup is occurring. A backup of online datafiles is called an online backup.
One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that either RMAN or an operating system utility reads the entire block while database writer is in the middle of updating the block. In this case, RMAN or the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. In this case, the block is a fractured block, meaning that the data contained in this block is not consistent.
During an RMAN backup, an Oracle server session reads the datafiles, not an operating system utility. The server session reads whole Oracle blocks and determines whether the block is fractured by comparing the header and footer of each block. If the session detects a fractured block, then it rereads the block until it gets a consistent picture of the data.
When you back up an individual datafile or online tablespace with an operating system utility (rather than with RMAN), you must use a different method to handle fractured blocks. You must first place the online tablespace in backup mode with the ALTER TABLESPACE BEGIN BACKUP statement. As a result, Oracle stops recording checkpoints to the tablespace's datafiles. You must put a tablespace in backup mode to make user-managed backups of datafiles in an online, read/write tablespace. After an online backup is completed, Oracle advances the file header to the current database checkpoint, but only after you run the ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP statement to take the tablespace out of backup mode.
When you restore a datafile from an operating system backup, the datafile header has a record of the most recent datafile checkpoint that occurred before the online tablespace backup, not any that occurred during it. As a result, Oracle asks for the appropriate set of redo log files to apply should recovery be needed.
An offline backup is performed while the tablespace or datafile is offline. You can take tablespaces offline with the ALTER TABLESPACE OFFLINE statement by using any of three different options: NORMAL, TEMPORARY, or IMMEDIATE. Taking an offline backup with the NORMAL option ensures that after the backup is complete, you do not have to perform recovery to bring the tablespace or datafile back online. In this way, you can perform necessary backups on datafiles and tablespaces without ever having to shut down the database or perform recovery.
This section contains these topics:
RMAN backups are stored in a different format from user-managed backups. You generate an RMAN backup by running the BACKUP command from within the RMAN interface, as in the following example:
RMAN> BACKUP DATABASE;
The BACKUP command generates either a backup set or a proxy copy and writes it to the operating system or a third-party media manager (if used). A backup set is a logical construction composed of one or more backup pieces. A backup piece is a file in a proprietary format composed of the blocks from one or more input datafiles, control files, or archived redo logs.
The format of a backup piece is "proprietary" in the sense that only RMAN can generate backup sets, and only RMAN can restore them. A proxy copy is a special type of RMAN backup whose data transfer is managed by a third-party media vendor.
In contrast to the BACKUP command, the RMAN COPY command generates a datafile, control file, or archived log image copy that can be restored by an operating system utility. An image copy is an exact duplicate of the input file. For example, this command copies datafile 1 to df1.copy on the operating system:
RMAN> COPY DATAFILE 1 TO 'df1.copy';
The COPY command only copies to disk. However, you can use the BACKUP command to back up image copies to tape.
Whenever you use RMAN to make a backup or copy, it records the action in the target database control file. If you use a recovery catalog, then RMAN pulls the metadata from the control file into the catalog. When you want to restore the backups or copies, run the RESTORE command. RMAN queries the metadata and then chooses among the available backups and copies and restores them.
| See Also:
Oracle9i Recovery Manager User's Guide to learn how to make RMAN backups, and Oracle9i Recovery Manager Reference for |
You must use operating system utilities to make user-managed backups. The available commands are operating system specific. For example, on a UNIX system you can back up a datafile using dd as follows:
% dd if=/oracle/dbs/df1.f of=/backup/df1.bak bs=1024k
On Windows NT, you can back up a datafile by pressing CTRL+C and then CTRL+V, by dragging and dropping, or by running a COPY command at the Command Prompt as in the following example:
C:\> COPY df1.dbf F:\BACKUP\df1.dbf
One major difference between user-managed backups and RMAN backups is that in the former there is no automatic metadata record of the backup. In other words, you must manually keep records of what you back up and where you back it up.
| See Also:
Oracle9i User-Managed Backup and Recovery Guide to learn how to make backups using operating system utilities |
|
 Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|