Professional Documents
Culture Documents
ABSTRACT
RMAN is Oracle Corporations latest tool to perform backup and recovery on Oracle
databases. This paper covers notes that I made during my studies and tests of
RMAN.
WHAT IS RMAN?
Recovery Manager (RMAN) is an Oracle tool that lets the DBA perform backup and
recovery of Oracle databases. RMAN lets one perform full backups (with the
database up or down), incremental backups on the block level, and backups of
online redo logs and control files. The SYSDBA privilege is required to run RMAN on a
database. Among RMANs other benefits are:
o Keeps track of all backup and recovery operations performed against the
database.
o Manage centralized backup & recovery procedures for the enterprise.
o Identifies corrupt blocks.
Why use RMAN at EDC when other backup & recovery implementations have
proven so successful? The GASR database is slated to be in the terabyte range.
Such a large database would take a very long time to bring down for cold
backups. This leaves us with two options, either hot backups or RMAN.
Unfortunately, hot backups will backup the entire database files. RMAN can be
used to backup only those blocks that actually contain data. This can lead to big
savings in the backup space requirements. RMAN is being deployed on GASR to
perform incremental backups on the block level of this multi-terabyte database.
RECOVERY CATALOG
Notice that I had my environment set up for the GAST as my local database. This let
me connect to this target database with the connect target / command. If the
target database was remote, one could use the userid/password@connect_string
convention. This is exactly the tactic used to connect to the remote catalog
database.
If you need to create a Recovery Catalog, then you need to perform the following
steps:
1. Create a schema owner in the Recovery Catalog database.
2. Create a tablespace for that schema owner
3. Grant CONNECT, RESOURCE, and RECOVERY_CATALOG_OWNER roles to that schema
owner.
4. 8i: From RMAN, connect to the recovery catalog and issue the following
command: CREATE CATALOG TABLESPACE RMAN_TS;
5. Pre-8i: Run the $ORACLE_HOME/rdbms/admin/catrman.sql script.
As you can see, Oracle 8i supports the CREATE CATALOG statement. It also supports
the UPGRADE CATALOG and DROP CATALOG statements.
REGISTERING A DATABASE
Now that you have set up the Recovery Catalog, you need to register a database
with that recovery catalog in order to begin backup & recovery operations. This is
done with the REGISTER DATABASE command as can be seen below:
edcsns18% rman
Here, we connected RMAN to the recovery catalog and the target database. The
target database was then registered with the recovery catalog. Notice that this
database was given a unique database identifier. A section that follows will cover
this in a little more detail.
Enter password:
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
Before you can deregister the database, you need to know the DB_KEY and DB_ID for
that database. For more information, refer to the section on Database Identifiers.
The Recovery Catalog is not immediately aware of changes made to the database.
For instance, you may add a tablespace to the database. The Recovery Catalog
needs to be aware of this for future backup and recovery operations. The BACKUP,
COPY, RESTORE, and SWITCH commands automatically update, or re-sync the Recovery
Catalog. If one wants to force the re-sync, it can be done as follows:
This should be done on a periodic basis so that RMAN is familiar with changes to
the online redo logs and the archive redo logs.
DATABASE IDENTIFIER
Notice that when I connected to the GAST database, it displayed a unique database
identifier, DBID=4222303827. Each database id is used to uniquely identify that
database to the Recovery Catalog. To see which databases currently exist in the
recovery catalog, issue the following:
Here, we can see that we have two databases currently registered with the
Recovery Catalog. And you can clearly see their individual DBID numbers.
BACKING UP A DATABASE
Its now time to backup the database. After all, thats what were here for! There
are multiple ways to perform a backup. What is not backed up? The following files
are not backed up by RMAN: INIT.ORA parameter files, password files, online redo
logs, transportable tablespaces not yet set to READ WRITE, and operating system
files. Youll have to employ some other method of backing those up. In our case,
Legato generally backs these files up without any of our intervention.
RMAN handles three different types of backups: backup sets, datafile copies (or
image copies), and operating system backups. Backup sets are created with the
BACKUP command. Backup sets can be a FULL backup of database blocks in use (not
to be confused with a full backup), and INCREMENTAL backups. Datafile copies are
done with the COPY command. OS backups can be done with OS commands
through RMAN.
The next few sub-sections will give you some details about RMANs backup
capabilities.
An RMAN full backup is not like the cold backups of the past. Cold backups would
require that the database be down. A RMAN full backup can take place if the
database is up or down. All database blocks for the datafiles and control files will
be backed up regardless of whether those blocks are empty or not. If the full
backup needs to take place when the database is up and running, then that
database must be running in Archive Mode. A full backup is done similarly to the
following:
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_full_bkup_%t';
4> backup database;
5> sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
6> }
There are some important points to note about this series of commands. They will
be explained here and not in further sections. First, the RUN command is used to
tell RMAN what series of commands to execute. Those commands can be found
between the open and closed braces.
CHANNELS
The first command in the example will open a channel. RMAN will only read or
write using a channel. In my case, Ive opened a channel to disk, but I could have
opened a channel to a tape device by specifying the sbt_tape type. Since this is a
disk channel, I had to tell it which directory to use and what the filename of the
backup set will be called. This is done with the FORMAT option. You can clearly see
that I placed the backup set in the /edcsns18/backup/oradata/gast/rman directory.
The rest of the FORMAT option declares the backup set filename in that directory,
%d_full_bkup_%t. Referring to the table below, one can see that %d is the database
name and %t is a timestamp.
Wildcard Meaning
---------- --------------------------------------
%d Database name (SID)
%t Timestamp
%u Unique name/number generated by Oracle
%c Copy number
%p Backup piece #
%s Backup set #
Here, you can see that the timestamp is 446312136. A further message shows:
Here, you can see the backup set was placed in one piece in the appropriate
directory. The %d and %t wildcards have been replaced by the database SID and
timestamp respectively.
It is possible to allocate more than one channel to your backup. This is done to
improve performance. If I allocate three disk channels to three different physical
disk drives, then I can backup the database in one-third of the time it takes to
backup the database through one channel to one physical drive.
FULL BACKUP
The backup database command says to perform a full backup of the database. This
is all that is required.
The SQL directive passes a SQL command to the target database. In my example,
I issued the ALTER SYSTEM ARCHIVE LOG CURRENT command. Keep in mind that SQL
commands will not show any output other than the RMAN-03023: executing command:
sql message.
FINAL THOUGHTS
Notice that each of the datafiles of the database is included in the backup. This is
indicated by the RMAN messages:
There is one of these for every file in the database. Notice that there is no TEMP
tablespace in this backup set. This is because the TEMP tablespace was created
with TEMPFILES instead of DATAFILES. As such, they do not require a backup. If
the TEMP tablespace needs to be restored, simply remove that tablespace from the
database and create a new one.
A copy of the control file was included in the backup set. This is confirmed in the
following message:
The online redo logs were not included in the backup set. According to Oracle
Corp., a backup of online redo logs is not required, nor is it recommended. In fact,
restoring these datafiles can lead to a corrupt database.
When the backup is done, you will get a message indicating the elapsed time
along with a resync of the recovery catalog.
TABLESPACE BACKUPS
Occasionally, one will want to backup just a tablespace (and its associated
datafiles). This can be done similarly to the following:
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_ts_bkup_%t';
4> backup tablespace "GAST_DATA"
5> filesperset 2;
6> }
Here, we backed up just the GAST_DATA tablespace. We also used the optional
parameter to indicate that there could be at most 2 pieces, or files, for this backup
set.
DATAFILE BACKUPS
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/file_gast_data02_%t';
4> backup datafile '/edcsns18/oradata7/gast/gast_data02.dbf';
5> }
RMAN can also backup control files as well. A full backup will automatically backup
the control file, but it may be desirable to do this separately. For instance, you
may wish to backup a tablespace and include the control file in that backup.
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_ctl_file';
4> backup current controlfile;
5> }
The backup current controlfile command indicates that the control file should be
backed up.
RMAN can now be used to backup the archived redo logs. Previously, DBAs had to
create custom scripts to accomplish this. Using RMAN is a great way to backup
those archived redo logs to tape without any other intervention.
RECID DAY
---------- --------------
1 11/06/01 12:47
2 11/06/01 14:04
3 11/06/01 14:39
4 11/07/01 14:06
5 11/08/01 11:48
6 11/08/01 11:48
7 11/20/01 15:38
7 rows selected.
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_redologs';
4> backup archivelog all;
5> }
You can clearly see that all 7 archived redo logs were archived with RMAN
messages similar to the following:
One can also specify a range of archived redo logs instead with a command
similar to the following:
RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_redologs_%t';
4> backup archivelog from time='07-NOV-01' until time='09-NOV-01';
5> }
This range specified those archived redo logs generated in a specific time frame.
INCREMENTAL BACKUPS
RMAN will let you perform incremental backups on a database. This lets you
backup only those database blocks that have changed since the last incremental
backup. Before RMAN, Oracles export utility was the only supported incremental
backup solution. But the import utility could not roll forward any changes since the
export was taken. RMAN lets you take incremental backups and roll forward any
changes since that backup.
All of the backups mentioned in the above sections will backup all database
blocks, even if they are completely empty. This is not one of the strengths of
RMAN. RMANs incremental backups will backup non-empty database blocks.
RMAN has multiple levels of incremental backups. The lowest level, level 0, is a
baseline incremental backup. Essentially, this is a full backup. A level 1
incremental backup will backup only those blocks that have changed since the
previous backup at level 1 or lower (level 0). RMAN also lets one perform a level 2
incremental backup.
RMAN> run {
2> allocate channel disk1 type disk
3> format '/edcsns18/backup/oradata/gast/rman/%d_incremental0_%t.bkup';
4> backup incremental level 0 database;
5> }
This completes the level 0 incremental backup. In my case above, the backup file
was 83 Mbytes in size. Some time later, a level 1 backup is performed. Changes
have been made to the database during this time.
RMAN> run {
2> allocate channel disk1 type disk
3> format '/edcsns18/backup/oradata/gast/rman/%d_incremental1_%t.bkup';
4> backup incremental level 1 database;
5> }
One other note, the recovery catalog should not reside in the same database as
you are backing up. It is a very good idea to house the recovery catalog in a
separate database in a different server. You can use any method to backup the
recovery catalog, including RMAN.
The simplest way to find out which backups have taken place through RMAN is to
use the list command. To find all backups of the target database issue the
following command:
Here, you can see that a backup set was created on 07-NOV-01. This backup set
consists of one backup piece,
/edcsns18/backup/oradata/gast/rman/GAST_gast_01d8hthi_1_1. This backup set only
comprises two database datafiles corresponding to the SYSTEM and RBS tablespaces.
If other backup sets were created for this target database, then the same
information presented above would follow for each backup set.
The above example shows how to list the backup sets for the database (of
database keywords). The same command can be used with other options such as
of tablespace ts_name or of controlfile or of archivelog all. For example:
This shows all the backup sets for the GAST_DATA tablespace. You may wish to
restrict the output of the list command to those backup sets generated in a
specific date range. This is done with the completed between option.
The above output showed only those backup sets for the GAST_DATA tablespace
created between 11/07/01 and 11/21/01.
There is more information on the list command in the Oracle8i Recovery Manager
User's Guide and Reference manual. Use the list command to find out which
backup pieces are needed for recovery. If those backup pieces have been
archived to some other location, restore them before beginning recovery of the
database. This will make your life much simpler.
REPORTING
RMAN also comes with more advanced reporting functions. These reports can help
you make decisions. For example, to see which datafiles comprise the database,
issue the following:
Here, you can see that this database is made of five datafiles. The REPORT SCHEMA
command lists the physical layout of your database according to RMAN. If you add
a datafile to the database, then RMAN needs to be notified of this change. This
can be done with the RESYNC CATALOG command.
The REPORT command can also let you know which datafiles need to be backed up.
For instance, to find out which datafiles have not been backed up in the last five
days, issue the following command:
This report shows that five datafiles need more than five days of archived logs to
recover. These files have not been backed up in the last five days.
The REPORT command can also let you know which backup sets are obsolete and
can be removed.
This command lists all backup sets that have at least 3 or more recent backups or
copies. If I only need three generations, then these backup sets can be removed.
The next section shows how to remove backup sets from RMAN.
REMOVING BACKUP SETS
It is unlikely that you have an unlimited supply of tapes or disk space to hold
every single backup ever made of your database. It is more likely that you have
allocated enough storage space to hold X generations of your backups (your
business rules determine X). For instance, you may desire to have the last three
good backups available. Over time, backup sets will become obsolete due to
storage considerations and those backup sets will be lost forever. RMAN needs to
be notified when those backup sets are no longer available for recovery.
In the previous section, I determined that five backup sets were obsolete. Lets
see how we can manually remove two.
First, a channel needs to be allocated to delete backup sets. Then the CHANGE
BACKUPIECE is executed to delete each backup piece. Finally, the channel is
released. Notice now that the two backup pieces have been removed from RMAN.
Only three backup pieces remain. This delete operation also removed the datafiles
from disk.
RMAN SCRIPTS
RMAN lets you store scripts in RMAN. This way, you can store regularly executed
tasks right in RMAN. Then you just run the stored script. To demonstrate this, well
store a FULL backup script in RMAN and then run the script.
The first command creates the script. The second command runs that script.
RECOVERY
What good would a backup be if you werent able to recover the database? RMAN
lets one easily recover databases as well. In this example, Ill show how to recover
the entire database, but recovery can be done on the tablespace or datafile level
as well.
SVRMGR> startup
ORACLE instance started.
Total System Global Area 13197472 bytes
Fixed Size 73888 bytes
Variable Size 4841472 bytes
Database Buffers 8192000 bytes
Redo Buffers 90112 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/edcsns18/oradata7/gast/gast_data02.dbf'
Here we can see that the GAST_DATA02.DBF is missing when we tried to startup the
database. We need to recover this datafile from the backup. First, well start the
database in MOUNT mode.
Now that the database has been mounted, lets use RMAN to perform recovery.
RMAN> run {
2> allocate channel ch1 type disk;
3> restore database;
4> recover database;
5> }
In order to recover the database, we first need to allocate a channel to our backup
set. We then restore the datafiles and then perform recovery. Finally, we release
the channel. At this point, the database has been fully recovered. But the
database is not yet open.
The database is now open for processing. This command could have also been
included in the restore operation.