Oracle's Recovery Manager, also known as RMAN, should be your tool of choice when it comes to backing up Oracle databases. RMAN was first introduced in Oracle 8.0 and has come a long way since then. This chapter shows how RMAN has been improved specifically in Oracle Database 10g. It also offers some practical tips that you can use in configuring and using RMAN for both backup as well as recovery. Before we launch into the details, however, let's look at some basics of RMAN and try to understand why using RMAN is a good idea. Especially if you are new to RMAN, you might want to read this introduction. Simply stated, RMAN is an excellent way to provide a physical backup of your Oracle database. This is in contrast to export/import and Data Pump, which provide logical backups. In all Oracle database versions, in addition to the Export and Import utilities, Oracle has provided a way of backing up an open database that is currently being used, provided the database is in ARCHIVELOG mode. Such a backup, known as a hot backup, is performed by backing up database files using an operating system utility such as tar in UNIX or OCOPY in Microsoft Windows after placing the associated tablespaces in BACKUP mode. When a tablespace is placed in this mode, the redo information being written to logs is changed to write whole blocks rather than just the changed information, as is done normally. The redolog files are copied out to archive logs when they are full. A physical backup of the database files, along with a backup of the archive logs, can then be used to re-create the database to a specified point in time.
In Microsoft Windows platforms, you will need to use the OCOPY command rather than the COPY command because the former can be used to back up files that have been opened by another process. Note that when a database is open, the data file would have been held open by the oracle.exe process. Difference Between RMAN and Hot BackupThe reason full-block logging occurs when a tablespace is in BACKUP mode is to compensate for the difference between operating-system blocksize (normally 512 bytes) and the database blocksize (anywhere from 2KB to 32KB). This is a crucial difference between RMAN and the hot backup method. Full-block logging avoids a phenomenon known as fractured block read. In other words, the database could be writing an 8KB block as a whole, while the operating-system backup utility could have backed up an older version of a portion of the block in an earlier read. The next read would then read a modified version of another portion of the same block. The operating-system backup would have otherwise been inconsistent, except for the fact that the whole block, which was previously logged in redo, is written back during recovery. This makes the block consistent at recovery and thus avoids the fractured block read phenomenon. RMAN, on the other hand, is not an operating-system utility but an Oracle Databaseaware product. Hence, all reads by RMAN for the purpose of backup are performed using the block size of the database block itself, thus avoiding fractured block reads. When RMAN does encounter inconsistencies while reading blocks, RMAN notes these errors in the alert log and re-reads the block as may be required. Although a few extra blocks of redo and ultimately more archive logs is normally not an issue in small, less-active databases, it quickly becomes a problem when the databases are large and more active. Larger databases usually mean tablespaces with a large number of large files that have to be kept for long periods in BACKUP mode, increasing the chances of extra redo related to backup. Large databases also normally support a large, active user community, and the amount of redo increases with activity. If you have this combination in a database, you should consider using RMAN to back up that database in order to avoid this extra overhead for redo during backups. Advantages of RMAN over Hot BackupRMAN also has other major advantages that are listed here. These advantages apply even if you are considering RMAN for versions below Oracle Database 10g.
These reasons should be enough to convince you to move all your Oracle backups to RMAN, or at least consider using it in a few databases to begin with. The only time we would recommend using hot backups is when using SAN (Storage Area Network) disk mirror technology such as EMC's BCV (Business Continuity Volume) or Hitachi Data Systems' ShadowImage to offload backup I/O onto the mirror copy rather than the production volumes. In this case, the whole database is placed in hot-backup mode and the mirror image is broken to produce a database image copy that can then be mounted back and backed up separately. This operation takes place in a matter of a few seconds, after which the tablespaces are again placed in normal mode. The amount of full-block redo is minimal in this case. This technique is well suited for large, active databases hosted on SANs that support such disk mirroring; you want to offload the backup I/O to the mirror copy.
Note that Oracle Database 10g supports the ALTER DATABASE BEGIN BACKUP and ALTER DATABASE END BACKUP commands to place the entire database in backup mode all at once. You will not have to code BEGIN BACKUP and END BACKUP per tablespace in this case. For offline backups, RMAN needs a database to be mounted but not open. In the case of operating-system backups, an offline backup, also known as a cold backup, needs the database to be shut down and offline. A Sample RMAN Backup SessionRunning an RMAN backup is as simple as issuing a BACKUP DATABASE command, as shown in Listing 9.1. Commands entered by the user is shown in bold. Listing 9.1. A Simple RMAN Backup[View full width] $ rman Recovery Manager: Release 10.1.0.2.0 - 64bit Production Copyright (c) 1995, 2004, Oracle. All rights reserved. RMAN> connect target; connected to target database: TS10G (DBID=845721274) using target database controlfile instead of recovery catalog RMAN> backup database; Starting backup at 07-MAY-05 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00003 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/sysaux01.dbf input datafile fno=00001 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/system01.dbf input datafile fno=00005 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/example01 .dbf input datafile fno=00002 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/undotbs01.dbf input datafile fno=00004 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/users01.dbf channel ORA_DISK_1: starting piece 1 at 07-MAY-05 channel ORA_DISK_1: finished piece 1 at 07-MAY-05 piece handle=/u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset /2005_05_07/o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:05:55 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset including current SPFILE in backupset channel ORA_DISK_1: starting piece 1 at 07-MAY-05 channel ORA_DISK_1: finished piece 1 at 07-MAY-05 piece handle=/u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset /2005_05_07/o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 07-MAY-05 RMAN> list backup; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 28 Full 3G DISK 00:05:46 07-MAY-05 BP Key: 28 Status: AVAILABLE Compressed: NO Tag: TAG20050507T154504 Piece Name: /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G /backupset/2005_05_07/o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp List of Datafiles in backup set 28 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 13802579 07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /system01.dbf 2 Full 13802579 07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /undotbs01.dbf 3 Full 13802579 07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /sysaux01.dbf 4 Full 13802579 07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /users01.dbf 5 Full 13802579 07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /example01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 29 Full 2M DISK 00:00:00 07-MAY-05 BP Key: 29 Status: AVAILABLE Compressed: NO Tag: TAG20050507T154504 Piece Name: /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G /backupset/2005_05_07/o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp Controlfile Included: Ckp SCN: 13802773 Ckp time: 07-MAY-05 SPFILE Included: Modification time: 07-MAY-05 RMAN> sql 'alter system archive log current'; sql statement: alter system archive log current In this case, we did not connect to a RMAN catalog database. Instead, we connected to the target database that needed to be backed up. You can connect to this database named TS10G using the CONNECT TARGET command from the RMAN utility, which was invoked from the operating-system command line using the oracle account. This special account owns the software and the database, and thus did not need a user name and password to be able to log in to RMAN. The TS10G database was run in ARCHIVELOG mode and was open and active during the backup. Note that we did not have to use the BEGIN BACKUP and END BACKUP commands to place the tablespaces in hot-backup mode. The simple RMAN BACKUP DATABASE command was sufficient to execute the backup. We followed this up with a LIST BACKUP command that listed the current backups available. RMAN backs up all the files needed for recovery in the event of a failure. RMAN's BACKUP command supports backing up these types of files:
Other files needed for operation, such as network configuration files, password files, and the contents of the Oracle home, cannot be backed up with RMAN. The backup can be stored as image copies as well as backup sets. Image copies are equivalent to operating-system copies of database and other files but are cataloged by RMAN and thus known to the system. A backup set is a logical structure that holds data from database files, control files, redologs, and archive files as well as system parameter files. A backup set consists of one or more physical files known as backup pieces. These files can be read only by RMAN and contain data multiplexed from one or more data files, control files, archivelog files, and redolog files. In Oracle Database 10g, all RMAN backup-related files are created in the flash recovery area by default. The backup set piece file created by the BACKUP DATABASE command can be seen in Listing 9.2. Listing 9.2. Listing of RMAN Backup Pieces and File Sizes[View full width] SQL> select file_name, bytes/1024/1024 size_mb 2 from dba_data_files; FILE_NAME SIZE_MB ----------------------------------------------------------------- ---------- /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/users01.dbf 5 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/sysaux01.dbf 2690 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/undotbs01.dbf 85 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/system01.dbf 590 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/example01.dbf 150 ---------- sum 3520 $ pwd /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset/2005_05_07 $ ls -lrt total 6309424 -rw-rw---- 1 oracle dba 3227467776 May 7 15:50 o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp -rw-rw---- 1 oracle dba 2949120 May 7 15:51 o1_mf_ncsnf_TAG20050507T154504_17t714dq_ .bkp If you match the names of the files in Listing 9.2 to the descriptive lines in Listing 9.1 that list the backup set information, you will notice that backup set piece file o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp contains the database files and the backup set piece file o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp contains the control file and system parameter file (SPFILE). Note that the size of the former is approximately 3,077MB, which is less than the total of the individual database sizes amounting to 3,520MB, as seen in Listing 9.2. The files are created in a subdirectory under the flash recovery area, appropriately identified by the database name (TS10G), the nature of the contents (namely backupset), and the date of the backup. You will learn more about Flashback technologies in Chapter 17, "Effectively Using Flashback Technologies," but suffice it to say that you may need to adjust the size of this area using the DB_RECOVERY_FILE_DEST_SIZE initialization parameter to a size that is adequate for both the intended size of backups to be retained as well as other files such as archivelog and flashback information. You will also notice the words channel and tag. An RMAN channel is a logical name for the backup to be placed in. In this case, the default channel was a disk area named ORA_DISK_1 that defaulted to the flash recovery area. You can configure multiple RMAN channels to either disk or tape devices enabled via the MML, and they can be used in parallel. The tag is a user- or system-defined handle for the backup. You can use this as a key to track and locate this particular backup. In this case, the system-defined tag was a string containing the date and time of backup; this is actually a good tag to use. Finally, notice that you can always execute SQL commands from within RMAN using the SQL 'Your_SQL_command' option as seen at the end of Listing 9.1.
If you intend to use RMAN for backup, you will have to configure an adequate value for the LARGE_POOL_SIZE initialization parameter. RMAN uses this area for its buffering. If this is not configured, RMAN uses the shared pool instead for buffers. This can result in pollution of the library and data dictionary caches, leading to ORA-4031 errors. RMAN DocumentationDocumentation for RMAN has been strengthened in the documentation set for Oracle Database 10g. The following manuals should be perused for concepts, command references, and information about advanced topics:
Accessing RMANRMAN can be accessed via both the command line, as seen in Listing 9.1, as well as using OEM Database Control. The backup/recovery commands in OEM can be accessed via the Maintenance tab. Certain simple operations related to RMAN can be performed from the following OEM screens:
We suggest you use these screens to set up your database initially for RMAN backup. Most of the screens also have a button to generate the RMAN script or the corresponding SQL so you can log what commands were executed in order to be able to record and repeat the actions when necessary. |