1.3. RMAN Repository and Control Files
The RMAN utility uses two methods of storing information about the target databases that are backed up. Oracle calls the collection of metadata about the target databases the RMAN repository. There are two methods of storing data in the RMAN repository. The first method is by accessing an RMAN catalog of information about backups. The second method is by accessing the necessary information about backups in the target database's control files.
Oracle recommends that you store RMAN backup data in the catalog database as opposed to the RMAN repository for most medium-sized to enterprise environments. This allows full functionality of the RMAN utility. This catalog is another Oracle database with special RMAN catalog tables that store metadata about backups, much the same way that the data dictionary stores data about objects in the database. When using the recovery catalog, backup scripts can be created and stored in the catalog database for later use, and multiple target database can be backed up from a central source. This catalog database can also be backed up so that the information is made safe.
The RMAN utility enables you to use a target database without utilizing the recovery catalog database. The target database is the database targeted by RMAN for backup or recovery actions. Because most of the recovery catalog information is stored in the target database's control file, RMAN supports the ability to use just the control file to perform backup and recovery operations. This method would be used if the overhead of creating and maintaining a recovery catalog were too great for an organization.
NOTE
The recovery catalog database will be covered in more detail in the next section "RMAN Using the Recovery Catalog."
If you use RMAN without the recovery catalog, you are storing most of the necessary information about each target database in the target database's control file. In this case, the target database's control file is the repository. Thus, you must manage the target database's control file to support this. The init.ora or spfile.ora parameter CONTROL_FILE_RECORD_KEEP_TIME determines how long information that can be used by RMAN is kept in the control file. The default value for this parameter is 7 days and can be as many as 365 days. The greater the number, the larger the control file becomes to store more information.
|
The information that is stored within the control file is stored in the reusable sections called circular reuse records and non-circular reuse records. These sections can grow if the value of the parameter CONTROL_FILE_RECORD_KEEP_TIME is 1 or more. The circular reuse records have non-critical information that can be overwritten if needed. Some of the non-circular reusable sections consist of datafiles and redo log information.
In the next section, we will discuss the recovery catalog in detail. The recovery catalog is not the default method of storing data in the RMAN repository. You must set up and configure the recovery catalog and database before you can utilize this capability.
1.3.1. RMAN Using the Recovery Catalog
Before demonstrating how to use the recovery catalog, let's discuss briefly its capabilities and components. The recovery catalog is designed to be a central storage place for multiple databases' RMAN information. Unlike using the control file as a repository, the recovery catalog can support multiple Oracle databases or an enterprise environment. This centralizes the location of the RMAN information instead of having this information dispersed in each target database's control file.
The main components of the RMAN recovery catalog support the logging of the backup and recovery information in the catalog. This information is stored in tables, views, and other databases' objects within an Oracle database. Here is a list of the components contained in a recovery catalog:
Backup and recovery information that is logged for long-term use from the target databases
RMAN scripts that can be stored and reused
Backup information about datafiles and archive logs
Information about the physical makeup, or schema, of the target database
The recovery catalog is similar to the standard database catalog in that the recovery catalog stores information about the recovery process as the database catalog stores information about the database. The recovery catalog must be stored in its own database, preferably on a server other than the server where the target database resides. To enable the catalog, an account with CONNECT, RESOURCE, and RECOVERY_CATALOG_OWNER privileges must be created to hold the catalog tables. Next, the catalog creation script command must be executed as the user RMAN_USER connected to the RMAN utility.
Let's walk through the creation of the recovery catalog step by step:
NOTE
This example assumes that you have already built a database called oralOlrc to store the recovery catalog. Oracle recommends that the default size of the recovery catalog database be about 115mb including datafiles and redo logs.
First, you must point to the database where the recovery catalog will reside. This is not the target database. The RMAN database will be called oralOlrc. The oraenv shell script is provided by Oracle to switch to other databases on the same server. Use the following command:
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:Documents and Settingsdstuns>set ORACLE_SID=ora101rc
Create the user that will store the catalog. Use the name RMAN with the password RMAN. Make DATA the default tablespace and TEMP the temporary tablespace:
C:Documents and Settings>sqlplus /nolog SQL*Plus: Release 10.1.0.2.0 - Production on Sun Jun 13 06:17:34 2004 Copyright (c) 1982, 2004, Oracle. All rights reserved. SQL> SQL> connect /as sysdba SQL> create user rman_user identified by rman_user 2 default tablespace data 3 temporary tablespace temp; User created.
Grant the appropriate permissions to the RMAN user:
SQL> grant connect, resource, recovery_catalog_owner to rman_user; Grant succeeded. SQL>
Launch the RMAN tool:
C:Documents and Settings>rman Recovery Manager: Release 10.1.0.2.0 - Production Copyright (c) 1995, 2004, Oracle. All rights reserved.
Connect to the catalog with the user called RMAN that you created in step 2:
RMAN> connect catalog rman_user/rman_user connected to recovery catalog database recovery catalog is not installed
Finally, create the recovery catalog by executing the following command and specifying the table space that you want to store the catalog in:
RMAN> create catalog tablespace data; recovery catalog created RMAN>
Once the recovery catalog is created, there are a few steps that must be performed for each target database so that backup and recovery can be stored. The first step is registering the database. Once an incarnation of the database is registered, data may be stored in the recovery catalog for that particular target database. An incarnation of the database is a reference for a database in the recovery catalog.
Let's walk through registering a database and then using the recovery catalog by running a full backup:
C:Documents and Settings>rman target / Recovery Manager: Release 10.1.0.2.0 - Production Copyright (c) 1995, 2004, Oracle. All rights reserved. connected to target database: ORA101T (DBID=2615281366) RMAN> connect catalog "rman_user/rman_user@ora101rc"; connected to recovery catalog database RMAN> register database; database registered in recovery catalog starting full resync of recovery catalog full resync complete RMAN>
Once the target database has been registered, you can back up the target database. This will store the backup data in the recovery catalog. From this point on, all of RMAN can be utilized in the backup and recovery process for the backed-up target database.
To perform this you must connect to the target database, which in this example is ora101t in the Windows XP environment. Then you can connect to the recovery catalog in the ora101rc database.
Once connected to the proper target and catalog, you can execute the appropriate RMAN backup script. This script will back up the entire database. Next, the database can be restored with the appropriate RMAN script. Finally, the database can be opened for use.
Let's walk through this example step by step:
Set the ORACLE_SID to ora101t, which is your target database, so that the database can be started in MOUNT mode with SQL*Plus:
C:Documents and Settings>set ORACLE_SID=ora101t C:Documents and Settings>sqlplus /nolog SQL*Plus: Release 10.1.0.2.0 - Production on Sun Jun 13 07:06:16 2004 Copyright (c) 1982, 2004, Oracle. All rights reserved. SQL> SQL> connect /as sysdba Connected to an idle instance. SQL> startup mount ORACLE instance started.
Total System Global Area 88080384 bytes Fixed Size 787588 bytes Variable Size 78642044 bytes Database Buffers 8388608 bytes Redo Buffers 262144 bytes Database mounted.
Start the RMAN utility at the command prompt and connect to the target and the recovery catalog database ora101rc:
C:Documents and Settings>rman Recovery Manager: Release 10.1.0.2.0 - Production Copyright (c) 1995, 2004, Oracle. All rights reserved. RMAN> connect target connected to target database: ORA101T (DBID=2615281366) RMAN> connect catalog rman_user/rman_user@ora101rc; connected to recovery catalog database RMAN>
Once connected to the target and recovery catalog, you can back up the target database, including archive logs, to disk or tape. In this example, choose disk. Give the database name a format of db_%u_%d_%s, which means that a db_ will be concatenated to the backup set unique identifier and then concatenated to database name with the backup set number:
RMAN> run 2> { 3> allocate channel c1 type disk; 4> backup database format 'db_%u_%d_%s'; 5> backup format 'log_t%t_s%s_p%p' 6> (archivelog all); 7> } allocated channel: c1 channel c1: sid=49 devtype=DISK Starting backup at 15-JUN-04 channel c1: starting full datafile backupset channel c1: specifying datafile(s) in backupset
input datafile fno=00001 name=C:ORACLEORADATAORA101TSYSTEM01.DBF input datafile fno=00003 name=C:ORACLEORADATAORA101TSYSAUX01.DBF input datafile fno=00005 name=C:ORACLEORADATAORA101TEXAMPLE01.DBF input datafile fno=00002 name=C:ORACLEORADATAORA101TUNDOTBS01.DBF input datafile fno=00004 name=C:ORACLEORADATAORA101TUSERS01.DBF channel c1: starting piece 1 at 15-JUN-04 channel c1: finished piece 1 at 15-JUN-04 piece handle=C:WINDOWSSYSTEM32DB_04FODN6N_ORA101T_4 comment=NONE channel c1: backup set complete, elapsed time: 00:01:57 channel c1: starting full datafile backupset channel c1: specifying datafile(s) in backupset including current controlfile in backupset channel c1: starting piece 1 at 15-JUN-04 channel c1: finished piece 1 at 15-JUN-04 piece handle=C:WINDOWSSYSTEM32DB_05FODNAC_ORA101T_5 comment=NONE channel c1: backup set complete, elapsed time: 00:00:05 Finished backup at 15-JUN-04 Starting backup at 15-JUN-04 channel c1: starting archive log backupset channel c1: specifying archive log(s) in backup set input archive log thread=1 sequence=7 recid=1 stamp=527413772 input archive log thread=1 sequence=8 recid=2 stamp=527414322 input archive log thread=1 sequence=9 recid=3 stamp=528706062 channel c1: starting piece 1 at 15-JUN-04 channel c1: finished piece 1 at 15-JUN-04 piece handle=C:WINDOWSSYSTEM32LOG_T528932180_S6_P1 comment=NONE channel c1: backup set complete, elapsed time: 00:00:09 Finished backup at 15-JUN-04 released channel: c1 RMAN>
Once the backup is complete, the database may be restored and recovered. The database must be mounted but not opened. In the restore and recovery script, choose three disk channels to utilize parallelization of the restore process. This is not necessary but improves the restore and recovery time. The RESTORE DATABASE command is responsible for the restore process within RMAN. RECOVER DATABASE is required because the database was in ARCHIVELOG mode and these files need to be applied to the datafiles to perform a complete recovery. Lastly, the database is opened:
RMAN> run 2> { 3> allocate channel c1 type disk; 4> allocate channel c2 type disk; 5> allocate channel c3 type disk; 6> restore database; 7> recover database; 8> alter database open; 9> } allocated channel: c1 channel c1: sid=49 devtype=DISK allocated channel: c2 channel c2: sid=48 devtype=DISK allocated channel: c3 channel c3: sid=47 devtype=DISK Starting restore at 15-JUN-04 channel c1: starting datafile backupset restore channel c1: specifying datafile(s) to restore from backup set restoring datafile 00001 to C:ORACLEORADATAORA101TSYSTEM01.DBF restoring datafile 00002 to C:ORACLEORADATAORA101TUNDOTBS01.DBF restoring datafile 00003 to C:ORACLEORADATAORA101TSYSAUX01.DBF restoring datafile 00004 to C:ORACLEORADATAORA101TUSERS01.DBF restoring datafile 00005 to C:ORACLEORADATAORA101TEXAMPLE01.DBF channel c1: restored backup piece 1 piece handle=C:WINDOWSSYSTEM32DB_04FODN6N_ORA101T_4
tag=TAG20040615T213412 channel c1: restore complete Finished restore at 15-JUN-04 Starting recover at 15-JUN-04 starting media recovery media recovery complete Finished recover at 15-JUN-04 database opened released channel: c1 released channel: c2 released channel: c3 RMAN>