Lesson 2 RMAN Architecture

Transcription

1 RMAN Architecture 2.1 Lesson 2 RMAN Architecture An introduction to the architecture and components used by the RMAN utility. SKILLBUILDERS Author: Dave Anderson, SkillBuilders

2 RMAN Architecture Lesson Objectives RMAN Components Effect of mixed releases Control File and RMAN CONTROL_FILE_RECORD_KEEP_TIME parameter Creation Size Operating in NOCATALOG Mode Using a Recovery Catalog Synchronizing the Catalog

3 RMAN Architecture RMAN Components... RMAN executable Client application Can run on entirely separate machine Starts server sessions on Target Database Target Database Database to be backed up Control file contains RMAN metadata Catalog Database Optional database to hold Recovery Catalog 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 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 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.

4 RMAN Architecture RMAN Components Recovery Catalog Optional Secondary location for RMAN repository Primary location is target database control file Contains backup metadata Media Management Library Required if backing up to tape Communicates with server session on target database Reads and Writes to tape 2.4 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:

5 RMAN Architecture 2.5 Component Releases Each component has a release or version Mixing releases can be problematic For example, assume Group of 8.1.x production databases targets Install new 9i database to hold recovery catalog Want to use 9i RMAN to backup 8.1.x DB s No Good! See RMAN compatibility matrix The versions of the RMAN executable and the target database should be the same 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 8.1.x production (target) databases that you would like to back up with RMAN. You would like to create a new database to hold you recovery catalog and choose to install Oracle9i. Finally, to take advantage of the new 9i RMAN features, you would like to use 9i RMAN to backup your 8.1.x databases. However, this is not valid! You will need to backup your 8.1.x databases with a 8.1.x version of RMAN. Oracle documentation states The versions of the RMAN executable and the target database should be the same. 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 Metalink and search on RMAN compatibility for the latest compatibility guide.

6 RMAN Architecture The Control File Always the initial repository of RMAN metadata Control File contains Circularly reusable records Non-reusable records for datafiles and logs Persistent configuration setting records Circularly reusable records Initial allocation of empty records (slots) LGWR and ARCH add data History of log switches Archive log history Backup history Control retention with CONTROL_FILE_RECORD_KEEP_TIME parameter 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. Notes continued on the next page

7 RMAN Architecture 2.7 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.

8 RMAN Architecture The Control File Control file size will grow Affected by CONTROL_FILE_RECORD_KEEP_TIME parameter Frequency of log switches Frequency of backups 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.

9 RMAN Architecture 2.9 CFRKT Parameter... CONTROL_FILE_RECORD_KEEP_TIME parameter controls reuse of reusable records Minimum age in days of a reusable record before it can be overwritten Reusable records EXPIRE Default is 7 days Maximum 365 days Minimum 0 Overwritten metadata is lost, unless Using a recovery catalog and RESYNC catalog prior to overwrite More on this later 2.9 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.

10 RMAN Architecture CFRKT Parameter 2.10 show show parameter control_file_record_keep_time NAME NAME TYPE TYPE VALUE VALUE control_file_record_keep_time integer 7 system@dave> alter alter system 2 set set control_file_record_keep_time = comment='30 days days of of history in in control file' file' 4 scope scope = both; both; System altered. The CONTROL_FILE_RECORD_KEEP_TIME parameter is a dynamic parameter. This example illustrates how to change the value.

11 RMAN Architecture 2.11 Control File Creation CREATE DATABASE prod prod MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXDATAFILES LOGFILE GROUP GROUP 1 ('C:\Oracle\oradata\prod\redo01.log') SIZE SIZE 100M, 100M, GROUP GROUP 2 ('C:\Oracle\oradata\prod\redo02.log') SIZE SIZE 100M, 100M, GROUP GROUP 3 ('C:\Oracle\oradata\prod\redo03.log') SIZE SIZE 100M 100M 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.

12 RMAN Architecture Control File Creation... Excerpt from V$CONTROLFILE_RECORD_SECTION select type, type, record_size, records_total, RECORDS_USED from from v$controlfile_record_section TYPE TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED DATABASE REDO REDO LOG LOG DATAFILE RMAN RMAN CONFIGURATION LOG LOG HISTORY OFFLINE RANGE RANGE ARCHIVED LOG LOG BACKUP SET SET 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.

13 RMAN Architecture Control File Creation CREATE DATABASE MAXLOGFILES 5 Control file contains 5 records of type REDO LOG. CREATE DATABASE MAXDATAFILES 100 Control file contains 100 records of type DATAFILE. CREATE DATABASE MAXLOGHISTORY 1 But, control file created 226 records of type LOG HISTORY. 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.

14 RMAN Architecture 2.14 Control File Size... Size can dynamically grow Log switches and archiving can add many records Empty slots can fill up quickly More records added if necessary If existing records not expired See the CFRKT parameter Limit = log switch records Will start to overwrite non-expired records Warnings given Does not automatically shrink 2.14 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.

15 RMAN Architecture Control File Size Effect of 65,000 + log switches in 3 days CFRKT = 7 Size grew to 81 MB Duplexed 3 times, 243 MB V$CONTROLFILE_RECORD_SECTION shows growth: TYPE TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED LOG LOG HISTORY ARCHIVED LOG LOG Log history has maxed out!!!! 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.

16 RMAN Architecture Control File Size... Maximum log history records is Oracle docs wrong on this say no maximum Make sure CFRKT not too high if many log switches occur each day 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 slots for log switches, and the oldest record has not expired, meaning that Oracle has nowhere to put the new log switch data.

17 RMAN Architecture Control File Size 2.17 Error when no expired records and max log switch records allocated: ARC0: ARC0: Beginning Beginning to to archive archive log log 2 thread thread 1 sequence sequence kccrsz: kccrsz: denied denied expansion expansion of of controlfile controlfile section section by by record(s) record(s) the the number number of of records records is is already already at at maximum maximum value value (65535) (65535) krcpwnc: krcpwnc: following following controlfile controlfile record record written written over: over: RECID RECID #4 #4 Recno Recno Record Record timestamp timestamp 05/22/02 05/22/02 13:10:55 13:10:55 Set CFRKT = 0 to shutoff expiration checks And/Or Increase log file size 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.

18 RMAN Architecture 2.18 NOCATALOG Mode... Control file is sole source of backup data Self-contained RMAN environment Recommended for Single database environments Test and development databases Recovery catalog databases Set CFRKT to the maximum number of days that you would think you would possibly want to go back for recovery E.g. Weekly full backups CFRKT = 15 provides 2 weeks of archive log history 2.18 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.

19 RMAN Architecture NOCATALOG Mode Protect control file! Contains history of backups and archive logs Needed to RESTORE and RECOVER Duplex with CONTROL_FILES parameter Backup frequently Use 9i AUTOBACKUP feature 2.19 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 AUTOBACKUP ON Easy to RESTORE CONTROLFILE. Oracle9i 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 Oracle9i control file AUTOBACKUP feature. See Lesson 5: Backup with RMAN for details on using AUTOBACKUP.

20 RMAN Architecture 2.20 Recovery Catalog Tables and views contain metadata Backup data for 1 or more target databases Owned by user RMAN See the RC_ views Optional Target database control file also contains recovery metadata But, some functionality lost: Cannot store RMAN scripts Cannot restore to an old incarnation of the database (see the OPEN RESETLOGS option) 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.)

21 RMAN Architecture Recovery Catalog... The recovery catalog stores information on: Backup sets and pieces Image copies Archived redo logs Structure of target database User scripts Does not contain backup data Backup data stored in backup sets OS files on tape or disk 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)

22 RMAN Architecture Recovery Catalog... Create a separate database to hold RMAN recovery catalog On a separate server (with OEM?) DB1 Can create 1 recovery database/catalog for many target databases Target databases RCAT database DB2 DB3 RMAN Executable DB4 Recovery catalog 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.

23 RMAN Architecture Recovery Catalog Backup recovery catalog database Consider: RMAN in NOCATALOG mode EXPORT User-managed backups Increase CONTROL_FILE_RECORD_KEEP_TIME to maintain safe restore window 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.

24 RMAN Architecture 2.24 Recovery Catalog Maintenance RESYNC CATALOG command updates recovery catalog Propagate new and changed information into catalog Log history New datafiles Automatic re-syncs when you execute: RMAN commands backup, copy, crosscheck, delete, duplicate, list, recover, switch 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 database and control file, RMAN would not know, for example, the most recent structure of the database and the that certain archived logs exist and would not be able to fully recover your database. RMAN performs automatic resynchronizations whenever you issue a backup command (other commands as well).

25 RMAN Architecture Recovery Catalog Maintenance 2.25 Must re-sync before data in control file overwritten! Check CONTROL_FILE_RECORD_KEEP_TIME parameter Backup or issue RESYNC CATALOG before CFRKT parameter value! Frequency of manual re-sync? Log switches and archiving can occur frequently e.g log switches before backup taken Consider scheduling hourly job to resync catalog Inexpensive operation Alternative: expensive resync during backup Be sure that a re-sync is performed before the duration specified in the CONTROL_FILE_RECORD_KEEP_TIME parameter. If your database supports high volume of DML operations, you may want to consider frequent manual resynchronizations. For example, assume the database experiences 1000 log switches in between backup operations. In this case, the resync of the catalog could be reasonably time consuming. If you schedule hourly cron jobs to RESYNC CATALOG, you will avoid this situation.

26 RMAN Architecture Where We've Been... Components RMAN executable Target Database Recovery Database (optional) Recovery Catalog (optional) MML Control File Initial repository of RMAN metadata Watch for growth

27 RMAN Architecture Where We've Been NOCATALOG Mode OK for small DB s, test Recovery Catalog Create in separate database Synchronizing the Catalog Keep in sync with control file Next lesson covers setting up catalog Also see chapters of the Oracle9i Recovery Manager Users Guide 2.27 Chapters 16 through 18 of the Oracle9i Recovery Manager User s Guide is dedicated to maintaining and querying the RMAN repository. In the next lesson in this course we will learn and practice setting up a recovery catalog.

28 RMAN Architecture 2.28 RMAN Architecture Workshop RMAN Architecture Questions for review 2.28 RMAN Architecture Workshop 1. Assume you have twelve Oracle databases that you are responsible for backing up. All can be reached from your workstation via SQL*Net. Answer the following questions: 1. Q. How many copies of the RMAN executable will you use? 2. Q. Where will you install the RMAN executables? 3. Q. Will you use a Recovery Catalog? Why? 4. Q. If you will use a Recovery Catalog, where will you locate the catalog? Why? 5. Q. If you will use a Recovery Catalog, how will you backup the recovery database? Continued on the next page

29 RMAN Architecture Assume you have twelve Oracle databases that you are responsible for backing up. They range in release from 7.3 to 9.1. All can be reached from your workstation via SQL*Net. Answer the following questions: 1. Q. How many copies of the RMAN executable will you use? 2. Q. Where will you install the RMAN executables? 3. Q. Will you use a Recovery Catalog? Why? 3. Assume that you have one Oracle database to backup, and only one machine at your disposal. Answer the following questions: 1. Q. Will you use a Recovery Catalog? Why? 2. Q. If you decide to backup every 7 days, what value will you set the CONTROL_FILE_RECORD_KEEP_TIME parameter to? 4. Look in the alert log on your sample database for the CREATE DATABASE command. What are the following set to: 1. MAXLOGHISTORY: 2. MAXLOGFILES: 3. MAXDATAFILES: 5. Query V$CONTROLFILE_RECORD_SECTION. What are the RECORDS_TOTAL and RECORDS_USED for the following records types: 1. DATAFILE 2. REDO LOG 3. LOG HISTORY 4. Q. Do the values match the values specified on the CREATE DATABASE command? Why or why not? 6. Log in as SYSTEM and execute: ALTER SYSTEM SWITCH LOGFILE; 7. Query V$CONTROLFILE_RECORD_SECTION again. What changed in the LOG HISTORY records area of the control file?