Sample PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 29

RMAN Architecture

2.1

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

2005 SkillBuilders, Inc.

SKILLBUILDERS

Author: Dave Anderson, SkillBuilders

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.2

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

2005 SkillBuilders, Inc.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.3

2.3

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


2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.4

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
2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.5

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.6

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 history
Control retention with
CONTROL_FILE_RECORD_KEEP_TIME parameter
2005 SkillBuilders, Inc.

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

2005 SkillBuilders, Inc.

V2.1

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.8

2.8

The Control File


Control file size will grow
Affected

by

CONTROL_FILE_RECORD_KEEP_TIME parameter
Frequency of log switches
Frequency of backups

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.9

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.10

2.10

...CFRKT Parameter
system@DAVE>
system@DAVE> show
show parameter
parameter control_file_record_keep_time
control_file_record_keep_time
NAME
TYPE
VALUE
NAME
TYPE
VALUE
--------------------------------------------------------------------------------- ----------- ----------control_file_record_keep_time
integer
77
control_file_record_keep_time
integer
system@DAVE>
system@DAVE> alter
alter system
system
22 set
set control_file_record_keep_time
control_file_record_keep_time == 30
30
33 comment='30
comment='30 days
days of
of history
history in
in control
control file'
file'
44 scope
scope == both;
both;
System
System altered.
altered.

2005 SkillBuilders, Inc.

The CONTROL_FILE_RECORD_KEEP_TIME parameter is a dynamic parameter.


This example illustrates how to change the value.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.11

2.11

Control File Creation...


CREATE
CREATE DATABASE
DATABASE prod
prod
MAXINSTANCES
MAXINSTANCES 11
MAXLOGHISTORY
MAXLOGHISTORY 11
MAXLOGFILES
MAXLOGFILES 55
MAXLOGMEMBERS
MAXLOGMEMBERS 55
MAXDATAFILES
MAXDATAFILES 100
100
..
..
..
LOGFILE
LOGFILE GROUP
GROUP 11 ('C:\Oracle\oradata\prod\redo01.log')
('C:\Oracle\oradata\prod\redo01.log')
SIZE
SIZE 100M,
100M,
GROUP
GROUP 22 ('C:\Oracle\oradata\prod\redo02.log')
('C:\Oracle\oradata\prod\redo02.log') SIZE
SIZE 100M,
100M,
GROUP
3
('C:\Oracle\oradata\prod\redo03.log')
SIZE
GROUP 3 ('C:\Oracle\oradata\prod\redo03.log') SIZE 100M
100M

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.12

2.12

...Control File Creation...


Excerpt from
V$CONTROLFILE_RECORD_SECTION
select
select type,
type, record_size,
record_size, records_total,
records_total, RECORDS_USED
RECORDS_USED
from
from v$controlfile_record_section
v$controlfile_record_section
TYPE
RECORD_SIZE
TYPE
RECORD_SIZE RECORDS_TOTAL
RECORDS_TOTAL RECORDS_USED
RECORDS_USED
--------------------------------------------------------- ----------- ------------- ----------------------DATABASE
192
11
11
DATABASE
192
REDO
LOG
72
5
33
REDO LOG
72
5
DATAFILE
180
100
66
DATAFILE
180
100
RMAN
1108
50
00
RMAN CONFIGURATION
CONFIGURATION
1108
50
LOG
HISTORY
36
226
77
LOG HISTORY
36
226
OFFLINE
RANGE
56
145
00
OFFLINE RANGE
56
145
ARCHIVED
LOG
584
13
00
ARCHIVED LOG
584
13
BACKUP
40
204
00
BACKUP SET
SET
40
204
2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.13

2.13

...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.
2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.14

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


2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.15

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:
TYPE
RECORD_SIZE
TYPE
RECORD_SIZE RECORDS_TOTAL
RECORDS_TOTAL RECORDS_USED
RECORDS_USED
----------------------------------- --------------------- ------------------------- ----------------------LOG
36
65535
65535
LOG HISTORY
HISTORY
36
65535
65535
ARCHIVED
LOG
584
65535
65535
ARCHIVED LOG
584
65535
65535

Log history has maxed out!!!!


2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.16

2.16

...Control File Size...


Maximum log history records is 65535
Oracle

docs wrong on this say no maximum


Make sure CFRKT not too high if many log
switches occur each day

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.17

2.17

...Control File Size


Error when no expired records and max log switch
65535 records allocated:
ARC0:
ARC0: Beginning
Beginning to
to archive
archive log
log 22 thread
thread 11 sequence
sequence 65533
65533
kccrsz:
kccrsz: denied
denied expansion
expansion of
of controlfile
controlfile section
section 11
11 by
by 24238
24238
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 65526
65526 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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.18

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.19

2.19

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.20

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)

2005 SkillBuilders, Inc.

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

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.21

2.21

...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
2005 SkillBuilders, Inc.

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)

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.22

2.22

...Recovery Catalog...
Create a separate database to hold RMAN recovery
catalog

DB1

On a separate server (with OEM?)


Can create 1 recovery database/catalog for many target
databases
Target databases

DB3
DB2

RMAN
Executable

RCAT database

DB4

Recovery
catalog

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.23

2.23

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.24

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
2005 SkillBuilders, Inc.

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

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.25

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

2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.26

2.26

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
2005 SkillBuilders, Inc.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.27

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 catalog


Also see chapters 16 18 of the Oracle9i
Recovery Manager Users Guide
2005 SkillBuilders, Inc.

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.

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.28

2.28

RMAN Architecture Workshop


RMAN Architecture Questions for review

2005 SkillBuilders, Inc.

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

2005 SkillBuilders, Inc.

V2.1

RMAN Architecture

2.29

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. Q. Will you use a Recovery Catalog? Why?

3. Assume that you have one Oracle 9.0.1 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?

2005 SkillBuilders, Inc.

V2.1

You might also like