download-sample (1).pdf

RMAN Architecture 2.1

2005 SkillBuilders, Inc. V2.1

2005 SkillBuilders, Inc.SKILLBUILDERS

Lesson 2 RMAN Architecture

An introduction to the architecture and components used by the RMAN utility.

Author: Dave Anderson, SkillBuilders



2005 SkillBuilders, Inc.

2.2

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




2.3

RMAN Components...

RMAN executableClient applicationCan run on entirely separate machineStarts server sessions on Target Database

Target DatabaseDatabase to be backed upControl file contains RMAN metadata

Catalog DatabaseOptional 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 databases 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.




2.4

...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

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 databases 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 MMLs visit:

http://otn.oracle.com/deploy/availability/htdocs/bsp.htm.




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 DBs No Good!

See RMAN compatibility matrix The versions of the RMAN executable and the target

database should be the same http://metalink.oracle.com

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.




2.6

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 historyControl 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



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 reusablerecord 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.




2.8

The Control File

Control file size will growAffected 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.




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

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.




2.10

...CFRKT Parameter

system@DAVE> show parameter control_file_record_keep_time

NAME TYPE VALUE------------------------------------ ----------- ------control_file_record_keep_time integer 7

system@DAVE> alter system2 set control_file_record_keep_time = 303 comment='30 days of history in control file'4 scope = both;

System altered.

system@DAVE> show parameter control_file_record_keep_time

NAME TYPE VALUE------------------------------------ ----------- ------control_file_record_keep_time integer 7

system@DAVE> alter system2 set control_file_record_keep_time = 303 comment='30 days of history in control file'4 scope = both;

System altered.

The CONTROL_FILE_RECORD_KEEP_TIME parameter is a dynamic parameter. This example illustrates how to change the value.




2.11

Control File Creation...CREATE DATABASE prodMAXINSTANCES 1MAXLOGHISTORY 1MAXLOGFILES 5MAXLOGMEMBERS 5MAXDATAFILES 100. ..LOGFILE GROUP 1 ('C:\Oracle\oradata\prod\redo01.log') SIZE 100M,GROUP 2 ('C:\Oracle\oradata\prod\redo02.log') SIZE 100M,GROUP 3 ('C:\Oracle\oradata\prod\redo03.log') SIZE 100M

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




2.12

...Control File Creation... Excerpt from

V$CONTROLFILE_RECORD_SECTION

select type, record_size, records_total, RECORDS_USED from v$controlfile_record_section

TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED------------------ ----------- ------------- ------------DATABASE 192 1 1REDO LOG 72 5 3DATAFILE 180 100 6RMAN CONFIGURATION 1108 50 0LOG HISTORY 36 226 7OFFLINE RANGE 56 145 0ARCHIVED LOG 584 13 0BACKUP SET 40 204 0

select type, record_size, records_total, RECORDS_USED from v$controlfile_record_section

TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED------------------ ----------- ------------- ------------DATABASE 192 1 1REDO LOG 72 5 3DATAFILE 180 100 6RMAN CONFIGURATION 1108 50 0LOG HISTORY 36 226 7OFFLINE RANGE 56 145 0ARCHIVED LOG 584 13 0BACKUP SET 40 204 0

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.




2.13

...Control File Creation

CREATE DATABASE MAXLOGFILES 5Control file contains 5 records of type REDO

LOG.CREATE DATABASE MAXDATAFILES 100

Control file contains 100 records of type DATAFILE.

CREATE DATABASE MAXLOGHISTORY 1But, 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 CREATEDATABASE 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.




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 = 65535 log switch records

Will start to overwrite non-expired records Warnings given

Does not automatically shrink

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.




2.15

...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:

Log history has maxed out!!!!

TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED------------------ ----------- ------------- ------------LOG HISTORY 36 65535 65535ARCHIVED LOG 584 65535 65535

TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED------------------ ----------- ------------- ------------LOG HISTORY 36 65535 65535ARCHIVED LOG 584 65535 65535

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.




2.16

...Control File Size...

Maximum log history records is 65535Oracle docs wrong on this say no maximumMake 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 65535 slots for log switches, and the oldest record has not expired, meaning that Oracle has nowhere to put the new log switch data.




2.17

...Control File Size

Error when no expired records and max log switch 65535 records allocated:

Set CFRKT = 0 to shutoff expiration checks And/Or Increase log file size

ARC0: Beginning to archive log 2 thread 1 sequence 65533kccrsz: denied expansion of controlfile section 11 by 24238 record(s)

the number of records is already at maximum value (65535)krcpwnc: following controlfile record written over:RECID #4 Recno 65526 Record timestamp 05/22/02 13:10:55

ARC0: Beginning to archive log 2 thread 1 sequence 65533kccrsz: denied expansion of controlfile section 11 by 24238 record(s)

the number of records is already at maximum value (65535)krcpwnc: following controlfile record written over:RECID #4 Recno 65526 Record timestamp 05/22/02 13:10:55

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.




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

NOCATALOG mode is the default. This means that a recovery catalog will not be used and the target databases 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.




2.19

...NOCATALOG Mode

Protect control file!Contains history of backups and archive logsNeeded to RESTORE and RECOVERDuplex with CONTROL_FILES parameterBackup frequentlyUse 9i AUTOBACKUP feature

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.




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 databases 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.)




2.21

...Recovery Catalog...

The recovery catalog stores information on:Backup sets and pieces Image copiesArchived redo logsStructure of target databaseUser scripts

Does not contain backup dataBackup data stored in backup setsOS 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)




2.22

...Recovery Catalog...

Create a separate database to hold RMAN recovery catalog On a separate server (with OEM?) Can create 1 recovery database/catalog for many target

databases

RCAT database

RMANExecutable

DB1DB1

DB2DB2

DB3DB3 DB4DB4 Recovery catalog

Target databases

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.




2.23

...Recovery Catalog

Backup recovery catalog databaseConsider: 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.




2.24

Recovery Catalog Maintenance...

RESYNC CATALOG command updates recovery catalogPropagate new and changed information into

catalogLog historyNew 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).




2.25

...Recovery Catalog Maintenance

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. 1000 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.




2.26

Where We've Been...

ComponentsRMAN executableTarget DatabaseRecovery Database (optional)Recovery Catalog (optional)MML

Control File Initial repository of RMAN metadataWatch for growth




2.27

...Where We've Been

NOCATALOG Mode OK for small DBs, test

Recovery Catalog Create in separate database

Synchronizing the Catalog Keep in sync with control file

Next lesson covers setting up catalogAlso see chapters 16 18 of the Oracle9i

Recovery Manager Users Guide

Chapters 16 through 18 of the Oracle9i Recovery Manager Users 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.




2.28

RMAN Architecture Workshop

RMAN Architecture Questions for review

RMAN Architecture Workshop

1. Assume you have twelve Oracle 9.0.1 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



2. 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. Assume that you have one Oracle 9.0.1 database to backup, and only one machine at your disposal. Answer the following questions:


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?

2. RMAN ArchitectureLesson ObjectivesRMAN Components......RMAN ComponentsComponent ReleasesThe Control File......The Control FileCFRKT Parameter......CFRKT ParameterControl File Creation......Control File Creation......Control File CreationControl File Size......Control File Size......Control File Size......Control File SizeNOCATALOG Mode......NOCATALOG ModeRecovery Catalog......Recovery Catalog......Recovery Catalog......Recovery CatalogRecovery Catalog Maintenance......Recovery Catalog MaintenanceWhere We've Been......Where We've BeenRMAN Architecture Workshop

download-sample (1).pdf

Documents

Transcript of download-sample (1).pdf