Instructor's Notes
(If applicable)
- Lesson 2 - Oracle Recovery Manager (RMAN) Architecture
- Author: Dave Anderson, SkillBuilders
- www.skillbuilders.com
- Last Update: October 17, 2007
- In this lesson you will learn about:
- RMAN Components
- Limited ability to us mixed releases of RMAN
- The Oracle Control File and RMAN
- CONTROL_FILE_RECORD_KEEP_TIME parameter
- Creation of the Control File
- Size of the Control File
- Operating in NOCATALOG Mode
- Using a Recovery Catalog with RMAN and Synchronizing the Catalog
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- This lesson introduces RMAN architecture to the Oracle DBA. This includes a discussion of the control file and the RMAN catalog.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- An RMAN environment is comprised of several components, each of which has a release (or version) number.
- The RMAN executable is an Oracle client application. This client application spawns server sessions on the target database to do the work of backup or recovery. It is similar in some ways to SQL*Plus in that it allows connections to databases and provides a line mode command interface. It is different in that it allows multiple concurrent connections (one to the target, one to the catalog database and optionally a third to an “auxiliary” database) and it does not support SELECT statements. (RMAN actually spawns multiple sessions on the target database, but supports one CONNECT to the target.)
- The Target database is the Oracle database to be backed up or recovered. It is where the server sessions spawned by the RMAN executable run. The target database’s control file contains recovery metadata - that is, information about backups that have been taken. This information is needed to perform recovery.
- The Catalog database is a separate Oracle database created to hold the recovery catalog. It is optional database because the recovery catalog is optional. See the next page for more information on the Recovery Catalog.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The recovery catalog is a series of tables and view owned by a single user (typically called “RMAN”) populated with backup and recovery information for one or more databases. Since the target database’s control file also contains this information, this is an optional component. However, it is recommended. See more in the section “Recovery Catalog" later in this lesson.
- Oracle and RMAN do not come with the ability to directly read and write to tape. You must install compliant software, called a “media management library”, from a tape software vendor. Oracle ships with an free but scaled down MML from Legato (e.g. the tape drive must reside on the server). For a list of vendors supplying MML’s visit:
- http://otn.oracle.com/deploy/availability/htdocs/bsp.htm.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- Each component in the RMAN environment has a release – and often they are not the same. For example, you may have a group of release 9.2 production (target) databases that you would like to back up with RMAN. You would like to create a new database to hold your recovery catalog and choose to install Oracle 10g. Finally, to take advantage of the new 10g RMAN features, you would like to use the 10g RMAN executable to backup your 9.2 databases. However, this is not valid! You will need to backup your 9.2 databases with a 9.2 version of RMAN (i.e. the RMAN executable). The Oracle documentation states “The RMAN executable should be the same as the target database.” (There are exceptions; see below.) So, in fact, you will need multiple copies of RMAN to backup your mixed release environment.
- See the RMAN compatibility guide for more information. Login to Oracle ,Metalink and search on “RMAN compatibility” for the latest compatibility guide.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The control file is actually always used as a repository for RMAN metadata, even if you also use a recovery catalog. It is the only repository of data if you use RMAN in NOCATALOG mode. See the “NOCATALOG Mode” section later in this lesson.
- The control file is made up of records or slots. There are 3 types of records in the control file:
- Circularly reusable records – these records can be overwritten after they are older than value specified in CONTROL_FILE_RECORD_KEEP_TIME parameter.
- Non-Reusable records – these records cannot be overwritten.
- Persistent Configuration records – these records contain the RMAN environment settings. They are changed with the CONFIGURE command.
- Initially, (just after CREATE DATABASE) the records are mostly empty. As activity occurs on the database, the control file receives information about log switches and archived logs from the log writer and archive writer background processes. This information is stored in reusable records in the control file. The CONTROL_FILE_RECORD_KEEP_TIME parameter controls when a reusable record expires – which means the record can be overwritten. The purpose of the CFRKT parameter is to specify a recovery window – how far back in time you would like to be able to recover to.
- Tom Kyte of “asktom.oracle.com” says: “set your control_file_record_keep_time to be at least one day GREATER then the period of time between your backups, else there is a chance that an archive record gets aged out during the backup which thoroughly confuses the situation.”
Other Text:
(Examples or comments displayed on slide, if any).
Control retention with CONTROL_FILE_RECORD_KEEP_TIME parameter<br>
Instructor's Notes
(If applicable)
- The control file become larger as log switches, archiving and backups are performed. The records generated for log switches and archive logs can be overwritten – thus negating the need for the control file to expand – but not until the records are older than the value in the CONTROL_FILE_RECORD_KEEP_TIME parameter. Thus, this parameter has a direct affect on the size of the control file.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The CONTROL_FILE_RECORD_KEEP_TIME parameter helps control control file size by specifying, in days, how old a reusable record must be before it can be overwritten. So, for example, a value of 7 means that a backup record can not be reused (overwritten) unless it has existed for 7 days.
- The default value of the CONTROL_FILE_RECORD_KEEP_TIME is 7 days; the minimum is 0 and the maximum is 365 days. Setting to 0 effectively turns off expiration check, i.e. reusable records are reused as necessary (and the control file will not expand). Use with caution and you can lose metadata RMAN needs for recovery
- Overwritten metadata is lost - unless you use a recovery catalog and update the catalog with the RESYNC CATALOG command before the record is overwritten. If the CONTROL_FILE_RECORD_KEEP_TIME value is 5, you need to resync the catalog every 4 days or less. See more about resync Catalog in the “Recovery Catalog Maintenance” section of this lesson.
- Note that losing the metadata does not necessarily mean you cannot recover. It simply means that RMAN does not know about it and thus cannot use it in RMAN recovery. If the backup data is still available (the RMAN backup sets and Oracle archived logs), you can still manually apply them to the database.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The CONTROL_FILE_RECORD_KEEP_TIME parameter is a dynamic parameter. This example illustrates how to change the value.
Other Text:
(Examples or comments displayed on slide, if any).
system@DAVE> show parameter control_file_record_keep_time
<br>
<br>NAME TYPE VALUE
<br>------------------------------------ ----------- ------
<br>control_file_record_keep_time integer 7
<br>
<br>system@DAVE> alter system
<br> 2 set control_file_record_keep_time = 30
<br> 3 comment='30 days of history in control file'
<br> 4 scope = both;
<br>
<br>System altered.<br>
Instructor's Notes
(If applicable)
- The CREATE DATABASE command creates the control file. Several parameters on this command affect the construction of the control file. For example, the MAXDATAFILES parameter allocates a fixed number of empty records (slots) to hold information about the datafiles. In this example, we can add 100 datafiles to this database. The control file would need to be re-created if we later want to add more datafiles.
Other Text:
(Examples or comments displayed on slide, if any).
CREATE DATABASE prod
<br>MAXINSTANCES 1
<br>MAXLOGHISTORY 1
<br>MAXLOGFILES 5
<br>MAXLOGMEMBERS 5
<br>MAXDATAFILES 100
<br> .
<br> .
<br> .
<br>LOGFILE GROUP 1 ('C:\Oracle\oradata\prod\redo01.log') SIZE 100M,
<br>GROUP 2 ('C:\Oracle\oradata\prod\redo02.log') SIZE 100M,
<br>GROUP 3 ('C:\Oracle\oradata\prod\redo03.log') SIZE 100M
<br>
Instructor's Notes
(If applicable)
- The dynamic view V$CONTROLFILE_RECORD_SECTION is a way of looking at the fixed and reusable records contained within the control file.
- This example shows that just after database creation (i.e. control file creation), Oracle has reserved empty records, or slots, for information to be added later.
Other Text:
(Examples or comments displayed on slide, if any).
select type, record_size, records_total, RECORDS_USED
<br>from v$controlfile_record_section
<br>
<br>TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED
<br>------------------ ----------- ------------- ------------
<br>DATABASE 192 1 1
<br>REDO LOG 72 5 3
<br>DATAFILE 180 100 6
<br>RMAN CONFIGURATION 1108 50 0
<br>LOG HISTORY 36 226 7
<br>OFFLINE RANGE 56 145 0
<br>ARCHIVED LOG 584 13 0
<br>BACKUP SET 40 204 0<br>
Instructor's Notes
(If applicable)
- Here are some notable comparisons between the CREATE DATABASE on the previous page and this example:
- CREATE DATABASE MAXLOGFILES 5 – And the control file contains 5 records of type “REDO LOG”. Only 3 are used because the CREATE DATABASE command only specifies 3 log files.
- CREATE DATABASE MAXDATAFILES 100 – And the control file contains 100 records of type “DATAFILE”. Only 6 are used because so far only 6 datafiles have been created.
- CREATE DATABASE MAXLOGHISTORY 1 – But the control file created 226 records of type “LOG HISTORY”. These record information about log switches. This is not documented, but I believe this is the minimum (and default) for a Windows 2000 system.
- Note that only 13 records have been created for “ARCHIVED LOGS”. There is no documented control for this on the CREATE DATABASE command. Certainly, we will want to keep history for more than 13 archived logs. This will happen because additional records will be dynamically added to the control file, causing the control file size to increase. See the next page for more information.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The size of the control file will grow in size because of the RMAN data.
- If new information needs to be recorded, and all the available slots have been used, RMAN will do one of the following:
- If there are expired records, RMAN will overwrite the expired records. No warnings are given.
- If there are no expired records, RMAN will allocate more. This will cause the size of the file to grow. No warnings are given.
- If the LOG HISTORY and/or ARCHIVED LOG section has reached its maximum of 65,535 records AND there are no expired records, Oracle will begin to overwrite non-expired records, starting at the oldest record. Warnings are produced in the alert log.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- Not only did my control file grow to 81MB, but we now start to receive warnings that the control file cannot be expanded further because the log history records section has reached its maximum of 65,535 records.
Other Text:
(Examples or comments displayed on slide, if any).
TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED
<br>------------------ ----------- ------------- ------------
<br>LOG HISTORY 36 65535 65535
<br>ARCHIVED LOG 584 65535 65535<br>
Instructor's Notes
(If applicable)
- The initial number of records allocated for log switches is defined by MAXLOGHISTORY. The Oracle documentation says that the number of records that can be allocated is limited only by OS file size limitations or available disk space. This is incorrect. So, if your CFRKT parameter is high, say for example 300, and the number of log switches is also high, say 350 a day, then in 187 days (350 * 187) or less, you will have a problem. The problem is that your control file will have allocated the maximum 65535 slots for log switches, and the oldest record has not expired, meaning that Oracle has nowhere to put the new log switch data.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- We can see here that Oracle will start to overwrite non-expired log records.
- Possible Solutions:
- Set the CONTROL_FILE_RECORD_KEEP_TIME parameter = 0. This will turn off the expiration check. Use with caution because non-expired records will be written over. If you are using a recovery catalog, be sure to resync catalog immediately and frequently. Consider an hourly scheduled job to resync the catalog.
- Increase the size of the log files. This will reduce the number of log switches and archived logs.
Other Text:
(Examples or comments displayed on slide, if any).
ARC0: Beginning to archive log 2 thread 1 sequence 65533
<br>kccrsz: denied expansion of controlfile section 11 by 24238 record(s)
<br> the number of records is already at maximum value (65535)
<br>krcpwnc: following controlfile record written over:
<br> RECID #4 Recno 65526 Record timestamp 05/22/02 13:10:55<br>
Instructor's Notes
(If applicable)
- NOCATALOG mode is the default. This means that a recovery catalog will not be used and the target database’s control file is the only repository of RMAN backup information. Oracle recommends that you use this mode for small, single database environments and development databases. Environments with many production databases should use CATALOG mode.
- Set CONTROL_FILE_RECORD_KEEP_TIME to the maximum number of days that you would think you would possibly want to go back for recovery.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- In the event of a RESTORE/RECOVERY operation, RMAN relies on the control file for a record of backups taken when a recovery catalog is not used. What happens if you lose the control file in this mode? That depends on a few things:
- Oracle9i (and above) and AUTOBACKUP ON – Easy to RESTORE CONTROLFILE.
- Oracle9i (and above) and AUTOBACKUP OFF – Difficult, possibly impossible, to recover.
- Note this warning about loss of control files is included in the Oracle8i Backup and Recovery manual:
- “WARNING: It is difficult to restore and recover if you lose your control files and do not use a recovery catalog. The only way to restore and recover when you have lost all control files and need to restore and recover datafiles is to call OracleWorldWide Support (WWS). WWS will need to know:
- The current schema of the database.
- Which files were backed up.
- When the files were backed up.
- The names of the backup pieces containing the files.”
- Overcome this problem by using the control file AUTOBACKUP feature. See the lesson titled Backup with RMAN for details on using AUTOBACKUP.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The recovery catalog is a series of tables and view owned by a single user (typically called “RMAN”). Via the RMAN REGISTER command, these views are populated with backup and recovery information for one or more databases.
- After creating the catalog in the RMAN schema, you will notice a series of views starting with “RC_”. These are the recovery catalog views; these views can be queried for information on backups. Since the target database’s control file also contains this information, this is an optional component. However, it is recommended.
- Using a recovery catalog is optional. The control file of the target database also contains recovery metadata (in fact, the recovery catalog is populated from information stored in the target databases control file with the RESYNC CATALOG command). However, though RMAN is still very useful without a recovery catalog, some RMAN functions are lost. For example, you cannot create and store RMAN scripts and you cannot restore to an older incarnation of the database. (An incarnation of the database is created when you open the database with the “RESETLOGS” option – necessary when a point-in-time recovery is performed.)
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The recovery catalog stores information on:
- Backup sets and pieces. (files that contain backups)
- Image copies (Mirror image copies of datafiles.)
- Archived redo logs
- Structure of target database
- User scripts (recovery manager commands & SQL)
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- The RMAN client application can CONNECT to both a TARGET and a CATALOG (recovery) database. The target database is the database to be backed up. The recovery database contains a recovery catalog. The recovery catalog can contain metadata for many target databases.
- Create the recovery catalog in a separate database! You do not want to lose the recovery catalog if you lose your production (target) database – you would not be able to recover. A helpful recommendation that I found on the Oracle Technology Network (otn.oracle.com/availability/htdocs/9ifaq.html) was to create your recovery catalog in the same database that contains your Oracle Enterprise Manager repository.
Other Text:
(Examples or comments displayed on slide, if any).
RCAT database<br>Target databases<br>
Instructor's Notes
(If applicable)
- The database that contains the recovery catalog must also be backed up. For the RMAN catalog database, Oracle suggests using RMAN in NOCATALOG mode (to eliminate the need for a recovery catalog for the recovery catalog). If you choose this technique, consider increasing the CONTROL_FILE_RECORD_KEEP_TIME to a larger value so more days of backup data are kept before being overwritten.
- You could also consider:
- user-managed backups for the recovery catalog database. (User-managed backups are the old-style OS copy command backups.)
- EXPORT. This is a flexible option because you could restore (IMPORT) the recovery catalog into any working database for the recovery.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
- Keeping the recovery catalog updated with the information from the current control file is critical and is easily accomplished with the RESYNC CATALOG RMAN command. If we never updated the recovery catalog with metadata from the control file, and we lost the target databas&
