Sample PDF
Sample PDF
Sample PDF
2.1
Lesson 2
RMAN Architecture
An introduction to the architecture and
components used by the RMAN utility.
SKILLBUILDERS
V2.1
RMAN Architecture
2.2
2.2
Lesson Objectives
RMAN Components
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
V2.1
RMAN Architecture
2.4
2.4
...RMAN Components
Recovery Catalog
Optional
Secondary location for RMAN repository
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.
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
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.
V2.1
RMAN Architecture
2.6
2.6
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.
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.
V2.1
RMAN Architecture
2.8
2.8
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.
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
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.
V2.1
RMAN Architecture
2.11
2.11
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.
V2.1
RMAN Architecture
2.12
2.12
V2.1
RMAN Architecture
2.13
2.13
LOG.
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.
V2.1
RMAN Architecture
2.14
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.
V2.1
RMAN Architecture
2.15
2.15
CFRKT = 7
Size grew to 81 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
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.
V2.1
RMAN Architecture
2.16
2.16
V2.1
RMAN Architecture
2.17
2.17
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.
V2.1
RMAN Architecture
2.18
2.18
NOCATALOG Mode...
Control file is sole source of backup data
Self-contained RMAN environment
Recommended for
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.
V2.1
RMAN Architecture
2.19
2.19
...NOCATALOG Mode
Protect control file!
Contains
Overcome this problem by using the Oracle9i control file AUTOBACKUP feature.
See Lesson 5: Backup with RMAN for details on using AUTOBACKUP.
V2.1
RMAN Architecture
2.20
2.20
Recovery Catalog...
Tables and views contain metadata
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.)
V2.1
RMAN Architecture
2.21
2.21
...Recovery Catalog...
The recovery catalog stores information on:
Backup
V2.1
RMAN Architecture
2.22
2.22
...Recovery Catalog...
Create a separate database to hold RMAN recovery
catalog
DB1
DB3
DB2
RMAN
Executable
RCAT database
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.
V2.1
RMAN Architecture
2.23
2.23
...Recovery Catalog
Backup recovery catalog database
Consider:
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.
V2.1
RMAN Architecture
2.24
2.24
Recovery Catalog
Maintenance...
RESYNC CATALOG command updates
recovery catalog
Propagate
catalog
Log history
New datafiles
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.
V2.1
RMAN Architecture
2.25
2.25
...Recovery Catalog
Maintenance
Must re-sync before data in control file overwritten!
V2.1
RMAN Architecture
2.26
2.26
executable
Target Database
Recovery Database (optional)
Recovery Catalog (optional)
MML
Control File
Initial
V2.1
RMAN Architecture
2.27
2.27
Recovery Catalog
V2.1
RMAN Architecture
2.28
2.28
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:
V2.1