Oracle RMAN Demo
Oracle RMAN Demo
Version 10.2
Mount the NetApp
192.0.0.1 bigdog.psoug.org --> RMAN Database
192.168.2.200 --> PROD Database
$ cd /etc
$ vi hosts on PROD box
-- append the following
192.0.0.1 bigdog.psoug.org bigdog
-- save change
$ ping bigdog.psoug.org
$ ping bigdog
Modify TNSNAMES.ORA
-- as oracle on PROD box
$ ping bigdog.psoug.org
cd $ORACLE_HOME/network/admin
vi tnsnames.ora
-- add the following:
RMAN =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.0.0.1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMAN)
)
)
-- save change
$ lsnrctl start
$ lsnrctl status
$ tnsping RMAN
Put the PROD Database into Archive Log Mode
-- as oracle
$ sqlplus /nolog
SQL> conn / as sysdba
SQL> startup nomount;
col name format a30
col value format a30
SELECT name, value
FROM v$parameter
WHERE name LIKE '%arch%';
SQL> CREATE pfile FROM spfile;
-- alter the SPFILE as required.
1
$ cd $ORACLE_HOME/dbs
$ ls -la
$ vi initorcl.ora
-- append archive log destination
log_archive_dest = '/u01'
-- save changes
In Terminal Window
cd /u01
ls -la
Create Repository Tablespace and Schema
SQL> conn sys@RMAN AS SYSDBA
password: xxxxxx##
2
SQL> CREATE OR REPLACE PUBLIC SYNONYM dbms_stats FOR sys.dbms_stats;
SQL> RMAN@RMAN
3
Startup
$ rman
$ rman TARGET / CATALOG rman/rman@rman
RMAN> STARTUP MOUNT
$ rman TARGET SYS/oracle@trgt NOCATALOG
$ rman TARGET / CATALOG rman/rman@rman AUXILIARY SYS/oracle@auxdb
RMAN Create Catalog Demo
$ rman
RMAN> connect rcvcat rman/rman
RMAN> connect target sys/coi@infradb
RMAN> create catalog;
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN Backup Demo
$ rman
RMAN> connect rcvcat rman/rman
RMAN> connect target sys/coi@infradb
RMAN> run {
2> allocate channel c1 type disk;
3> backup database format '/nfs/curly/rman/o1/%u';
4> release channel c1;
5> }
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN Demo 1
Target Database Not Running in Archive Log Mode
CONFIGURATION
There are various parameters that can be used to configure RMAN operations to suit your needs.
Some of the things that you can configure are:
- the required number of backups of each datafile
- the number of server processes that will do backup/restore operations
in parallel
- the directory where on-disk backups will be stored
It should be noted that configuration settings are stored persistently, and will be used by RMAN
for all subsequent backup, restore, recovery, and maintenance operations.
Configure backups to be written to disk.
Configure RMAN to keep at least 5 backups of each datafile. If you have certain backups
which must be retained longer than this retention policy, you can use the KEEP option
4
with the BACKUP command when creating those backups.
Configure RMAN to use two disk channels for backup, restore, recovery, and
maintenance operations.
Configure RMAN to write disk backups to the /backup directory. The format specifier %t
is replaced with a 4-byte timestamp, %s with the
backup set number, and %p with the backup piece number.
Excludes tbs_exclude from full database backups. NOEXCLUDE can be specified with
the BACKUP command to override this configuration.
NOTES:
If you want backups to go to tape, refer to the configuration section in case2.rcv on how
to configure tape backups. However in case of disaster recover if RMAN is not
connected to recovery catalog, you will have to manually allocate all channels where
backups were taken.
- Use the SHOW ALL command to see your current configuration settings.
- Save the database id displayed in the RMAN output if you are taking
RMAN backups in nocatalog mode or database name is ambiguous in
recovery catalog. The database id is required during disaster
recovery (See Section 5). You will see the database id in RMAN output
on connecting to target database like :
Since you are operating the database in no-archivelog mode, only the following kinds of
backups are allowed:
- whole database backups when the database is cleanly closed and the
instance is mounted
- tablespace backups of tablespaces that are offline clean or read only
5
The following scenario assumes that you want to take one full database backup every
week, and one incremental database backup every day. The backup cycle starts on
Friday. A full backup is taken on Friday, and an incremental backup is taken every other
day. The retention policy of REDUNDANCY 5 applies only to full (not incremental)
backups, so the combination of that policy and this backup schedule ensures that you can
restore to any incremental backup time for the last 5 weeks.
If the above backup fails for any reaon, you can use the NOT BACKED UP SINCE
option on the BACKUP command (9i restartable backup feature) to continue from the
point of failure. The small value of FILESPERSET is good for restartable backups.
However you should note that smaller FILESPERSET produces more backup sets.
The steps are the same as in section 2.1, except that the options LEVEL 1
CUMULATIVE indicate that only the blocks that have changed since the last level 0
backup will be backed up. If the CUMULATIVE option was not specified, then only the
blocks that have changed since the last level 1 backup will be backed up. The advantage
of a cumulative backup is that only one incremental backup ever needs to be applied
during recovery.
6
The database does not have to be closed to back up a readonly tablespace. The following
command can be used to backup a readonly tablespace.
The following commands can be run any time to check if RMAN is capable of restoring
database/tablespace using existing backups.
In case of any user error or media failure you would have to do complete
database recovery. However using the SET UNTIL command, it is possible to recover to
different points in time when incrementals were taken. Because redo logs are not
archived, only full and incremental backups are available for restore and recovery.
It is assumed that you have all the configuration files like the server
parameter file (spfile - equivalent of init.ora in 9i), tnsnames.ora, and listener.ora in the
appropriate places, and that you can startup the Oracle instance in nomount mode and
connect from RMAN to the target instance.
7
initialization files for database, and listener files (only if
connecting over SQLNET)).
- restore controlfile.
- restore all database files. Use CHECK READONLY, to make sure all
read-only files are correct. If not RMAN will restore them.
- apply all incrementals.
- open database with resetlogs mode to re-create online logs.
The examples provided in this case study will use a disk area (/backup directory) to hold
the most recent one week of backups, in order to expedite backup/restore operations. The
size of this area may vary depending on database size, redo generated, etc. If you want all
backups to go to tape, remove DEVICE TYPE DISK option from the BACKUP
commands given in this case study.
Only the incremental backups are stored on disk for one week. The level 0 backup goes
immediately to tape. This means that RMAN will always have to read tape for recovery.
NOTES
You should not run all of the commands in this file in a single RMAN
session. Rather, the various sections in this file should be separated into individual
RMAN scripts which can be run to configure, backup, restore, and recover the database.
Organization:
8
# 3. Restore validation
# - verify that the database/tablespace is restorable
# 4. Maintenance commands
# 5. Restore and Recovery
# - Datafile recovery
# - Tablespace recovery
# - Controlfile recovery
# - Block recovery
# - Disaster recovery
# - Database Point-in-time recovery
#
# How to run the file containing RMAN commands:
#
Here is an example of how to run the file that contains RMAN commands:
CONFIGURATION
There are various parameters that can be used to configure RMAN operations to suit your
needs. Some of the things that you can configure are:
- the recovery window, to keep backups so that it is possible to recover
the database to any point in time during last X days.
- the number of server processes that can do backups/restore operations in
parallel
- default device type for backups
- the directory where on-disk backups will be stored
It should be noted that configuration setting is done just once, and these settings are used
by RMAN to perform all subsequent backup, restore, recovery, and maintenance
operations.
If the media manager requires an RMAN PARMS string, configure it here. The media
manager documentation will specify whether this configuration is needed.
CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<media manager parameter string>';
9
Configure the number of server processes (channels) that write backups to DISK. You
can delete these three lines if you want to only back up to tape.
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%t_s%s_s%p';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/backup/%F';
Set the retention policy to a recovery window of 30 days. This ensures that RMAN
retains all backups needed to recover the database to any point in time in the last 30 days.
You can use the DELETE OBSOLETE command to delete backups that are no longer
required by the retention policy. To exclude a backup from consideration by the policy,
you can use KEEP option with the BACKUP command.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
Enable the autobackup feature to backup the controlfile after each database or archivelog
backup.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Enable the backup optimization feature introduced in 9i to make sure that RMAN won't
backup an archivelog or datafile if there already exists a backup of that file. The FORCE
option can be used to override optimization on a specific BACKUP command.
CONFIGURE BACKUP OPTIMIZATION ON;
# IMPORTANT: Save the database id displayed in the RMAN output if you are
# operating RMAN backups in nocatalog mode, since it is required during
# disaster recovery. You will see the database id in output from RMAN on
# connecting to target database like:
#
# connected to target database: INVENTORY (DBID=1670954628)
# Use the SHOW ALL command to see the current configuration settings.
BACKUP
Running database in archivelog mode provides following advantages high availability,
i.e., database is available during backups.
- point in time recovery within recovery window for database/tablespace.
You can also follow the procedure given in case1.rcv for taking consistent backups. Only
disadvantage of taking consistent backups is that you have to close database cleanly, and
open in restricted mode. Hence database is not available for general use during consistent
backup.
Following scenario assumes that you want to take one full database once a week, doing
every day incrementals. Backup cycle starts on friday, i.e., every friday full backup, and
on other days incrementals.
10
# The steps are:
# - Take an incremental level 0 backup of the database. A level 0 backup is
# a complete backup of the entire file which can be used as the basis
# for a subsequent incremental backup.
# - Backup all archivelogs that have not already been backed up.
# - Delete on-disk archivelogs older than seven days.
If the above backup fails for any reaon, you can use the NOT BACKED UP SINCE
option on the BACKUP command (9i restartable backup feature) to continue from the
point of failure. The small value of FILESPERSET is good for restartable backups.
However you should note that smaller FILESPERSET produces more backup sets.
As in section 2.1, you can use the NOT BACKED UP SINCE option with the BACKUP
command (9i re-startable backup feature) to continue from the point of failure.
11
FILESPERSET 4
NOT BACKED UP SINCE TIME 'SYSDATE -1 ';
BACKUP BACKUPSET ALL; # copies backups from disk to tape
BACKUP ARCHIVELOG ALL;
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
RESTORE VALIDATION
The following commands can be run any time to check if RMAN is capable of restoring
the database/tablespace using existing backups.
Verify that all backups which RMAN thinks are stored by the third-party media manager
still exist, and generate a report of backups that need to be taken to satisfy the retention
policy.
CROSSCHECK BACKUP;
REPORT NEED BACKUP;
Delete backups that are no longer needed to satisfy the retention policy. Since we have
set the retention policy to a recovery window of 30 days, any datafile backups (generated
without the KEEP option) not required to recover within 30 days are deleted. After
deciding which datafile backups are no longer needed, RMAN can then decide which
archivelog backups are no longer needed. Archivelog backups are not needed if they are
older than ANY existing datafile backup.
DELETE OBSOLETE;
This section assumes that datafile 5 has been damaged and needs to be
restored and recovered, and that the current controlfile and all other datafiles are intact.
The database is open during the restore and recovery.
12
RUN
{
SQL 'ALTER DATABASE DATAFILE 5 OFFLINE';
RESTORE DATAFILE 5;
RECOVER DATAFILE 5;
SQL 'ALTER DATABASE DATAFILE 5 ONLINE';
}
RUN
{
SQL 'ALTER TABLESPACE TBS_5 OFFLINE';
If you restored to different locations, uncomment the commands below to switch the
controlfile to point to the files in their new locations.
# SWITCH DATAFILE ALL;
Oracle strongly recommends that you specify multiple controlfiles, on separate physical
13
disks and controllers, in the CONTROL_FILES initialization parameter.
- If one copy is lost due to media failure, copy one of the others over the
lost controlfile and restart the instance.
- If you lose all copies of the controlfile, you must re-create it using
the CREATE CONTROLFILE sql command.
You should use RMAN to recover a backup controlfile only if you have lost all copies of
the current controlfile, because after restoring a backup controlfile, you will have to open
RESETLOGS and take a new whole database backup.
This section assumes that all copies of the current controlfile have been lost, and that all
initialization parameter files, datafiles and online logs are intact.
Start RMAN without the TARGET option, and use the following commands to restore
and recover the database:
# You must take a new whole database backup after resetlogs (as
# in Section 2.1), since backups of previous incarnation are not easily
# usable.
}
14
# SQL> select * from emp;
#
#NAME
# The BLOCKRECOVER command can also be used to repair all corrupted blocks
# listed in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION. These views
are
# populated whenever an RMAN process peforms a complete scan of a file for the
# purpose of backing it up, such as with the BACKUP or COPY command. Use the
# following command to repair all blocks listed in the V$xxx_CORRUPTION views:
# command:
BLOCKRECOVER CORRUPTION LIST;
15
# Optionally you can use SET NEWNAME and SWITCH commands as described in
# Section 5.2 to restore datafiles to a new location.
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
# You must take a new whole database backup after resetlogs (as
# in Section 2.1), since backups of previous incarnation are not easily
# usable.
}
# You must take a new whole database backup after resetlogs (as
# in Section 2.1), since backups of previous incarnation are not easily
# usable.
}
RMAN Demo 3
# DESCRIPTION
# This case study outlines the basic steps to perform tablespace
# point-in-time recovery (TSPITR) using Recovery Manager.
#
# The examples in this case study assume that all backups are stored on
# disk. However if you have backups on tape and channels are configured as
# described in case2.rcv, Section 1, the same procedures will work.
#
# This case study assumes that
# - You want to recover tablespaces TBS1 and TBS2 to the point in time
# '2000-APR-01:07:05:30'.
# - TSPITR is performed on the same machine as the target database.
# - ORACLE_HOME is /oracle.
# - ORACLE_SID for the target database is PROD.
# - target database files and online logs are in $ORACLE_HOME/dbs/.
16
# - ORACLE_SID for the auxiliary instance is AUX.
# - all temporary files (except password file) for the auxiliary
# instance are created in $ORACLE_HOME/auxiliary.
#
# NOTES
# You should not run all of the commands in this file in a single RMAN
# session. Rather, the various sections in this file should be studied
# thoroughly before performing TSPITR.
#
# MODIFIED (MM/DD/YY)
# banand 04/17/01 - re-write case for tablespace point-in-time recovery
# banand 04/17/01 - Creation
#
# Organization:
#
# This case study is organized into the following sections:
# 1. TSPITR usage and restrictions
# 2. Resolving referential dependencies
# 3. Preparing for TSPITR - setup auxiliary instance
# 4. Performing TSPITR
# 5. Preparing the target database to use recovered files
# 6. Cleaning up the auxiliary instance and temporary files
#
After TSPITR you should take a new backup of the recovered tablespace(s),
since it is not possible to recover using the pre-TSPITR backups.
17
proceeding.
Oracle provides the TS_PITR_CHECK view to assert that no referential integrity constraints will
be broken after TSPITR. If this view returns rows when queried then the reason should be
investigated and resolved. Only when TS_PITR_VIEW returns no rows TSPITR will be able to
proceed (since this view is checked by imp/exp utilities called by RMAN during
TSPITR). All actions taken at this stage should be noted in order that these relationship can be
rebuilt after TSPITR is complete.
Run the following queries to prepare for performing TSPITR on TBS1 and TBS2 to time '2000-
APR-01:07:05:30':
This section shows how to set up the auxiliary instance which will be used by RMAN to perform
TSPITR on the desired tablespaces. RMAN will connect to this database using the AUXILIARY
connect option.
Section 3.1.1 - Preparing to connect to the auxiliary instance The following steps should be
followed to connect to the auxiliary instance:
- create a password file for the auxiliary instance using the orapwd utility:
orapwd file=/oracle/dbs/orapwAUX password=auxpwd entries=100
Add listener.ora and tnsnames.ora entries so that RMAN can connect to the auxiliary database.
Section 3.1.2 - Preparing the parameter file for the auxiliary instance You can use the production
instance parameter file as the basis for the auxiliary instance. However certain parameters like
db_block_buffers, shared_pool_size, large_pool_size, enqueue_resources, etc which allocate
shared memory can probably be reduced, because the auxiliary instance does not have the
same memory requirements as the production instance.
The following parameters must be set for the auxiliary instance: db_name must be the same as
in the production instance
db_name=PROD
18
db_file_name_convert and log_file_name_convert are used only in the parameter file of the
auxiliary instance. They establish the rules that are used to convert the datafile and log file
names from the production to the auxiliary database.
Note that starting in Oracle9i, more than one pair of substitutions can be specified in both of
these parameters, which allows more flexibility in converting file names. Use the RMAN SET
NEWNAME command to convert any file names that cannot be converted with the
xxx_file_name_convert parameters.
db_file_name_convert=('/dbs/', '/auxiliary/')
log_file_name_convert=('/dbs/', '/auxiliary/')
It is important to note that ALL controlfiles, online logs, and datafiles must have different names
at the auxiliary instance than they have at the production instance, otherwise RMAN may restore
files to those locations, and overwrite the production files. Use the control_files,
db_file_name_convert, and log_file_name_convert parameters to make sure
that the files at the auxiliary instance all have different names.
The auxiliary database must be in nomount state and the target instance must be mounted or
open state to perform TSPITR. The steps in RMAN TSPITR
are:
- connect to auxiliary instance
- connect to target database
- connect to recovery catalog (optional)
- recover tablespace TBS1 and TBS2
RUN
{
# optionally, use SET NEWNAME here for file name translation
# SET NEWNAME FOR DATAFILE 1 TO '/oracle/auxiliary/file1.f'
# SET NEWNAME FOR DATAFILE 2 TO '/oracle/auxiliary/file2.f'
All the recovered tablespaces will be OFFLINE in target database on successful execution of
RECOVER command. If the RECOVER command fails, then after resolving the error you can re-
execute the commands.
If export fails due to lack of temporary space, you can create a temporary tablespace. Search for
19
tspitr_7 in /oracle/rdbms/admin/recover.bsq and see comments to create temporary tablespace.
If import fails because of import tables not existing, you can run CATEXP.SQL on target
database to create import schema.
Preparing the target database to use the recovered tablespaces
After the RECOVER command in Section 4 runs successfully, you should backup the recovered
tablespaces, because after they are brought online, they can no longer be recovered using
backups taken prior to the TSPITR.
The auxiliary instance is not usable after successful completion of TSPITR. This instance must
be cleaned using following steps:
- Connect to the auxiliary instance as explained in Section 3.1.3
- mount the database using 'ALTER DATABASE MOUNT CLONE DATABASE'
- Delete the temporary files restored by RMAN when performing TSPITR.
- Shutdown the auxiliary instance and delete the above files. All these files in this case should be
in the /oracle/auxiliary directory.
20
# and perform backups as with any other database.
#
# Make sure to set your NLS_LANG and NLS_DATE_FORMAT environment
variables.
# You can set these values to whatever you wish. The UNIX example
# below keeps the date format to the standard date format used
# for recovery:
#
# %> setenv NLS_LANG AMERICAN
# %> setenv NLS_DATE_FORMAT 'YYYY-MM-DD:hh24:mi:ss'
#
#
# Connect to RMAN and run the script by executing the following at
# the O/S command line
# (a single-line command is shown here on multiple lines for the
# sake of clarity):
# rman
# TARGET
# <target_userid</<target_password>@<target_net_service_name>
# CATALOG
# <catalog_userid>/<catalog_password>@<catalog_net_service_name>
# AUXILIARY
# <auxiliary_userid>/<auxiliary_password>@<auxiliary_net_service_name>
# @case4.rcv
# LOG case4.log
#
# For more information about the commands in this script, see the "Recovery
# Manager Command Syntax" in the Oracle8i Backup and Recovery Guide.
# For a description of the procedures for creating a duplicate database,
# see the chapter "Creating a Duplicate Database."
RUN
{
# STARTUP MOUNT;
# By default the DUPLICATE command will try to create the duplicate database
# using the most recent backup of the target database. If you wish to
# recover the duplicate database to a non-current time issue a SET UNTIL
# command to speceify the time.
# There are several ways to convert the filenames for the duplicate
# database. For a complete account, see the chapter "Creating a
# Duplicate Database" in the Oracle8i Backup and Recovery Guide. Note
# the following guidelines:
21
# (1) If the duplicate database is in the same host as the target,
# and the target datafiles cannot be transformed with
# DB_FILE_NAME_CONVERT rule from the INIT.ORA file of the
# duplicate database, then issue a SET NEWNAME command for each
# datafile that cannot be converted automatically.
#
# (2) If you are connected to a recovery catalog database and have issued
# SET AUXNAME commands for some datafiles, the DUPLICATE command
# will use the AUXNAME value. Disable the use of the AUXNAME
# with the command: SET AUXNAME FOR DATAFILE ... TO NULL;
#
# (3) When the duplicate database is in a different host from the
# target database, the same disk structure is present at the new
# host, and you want to keep the same datafile names, then use
# the NOFILENAMECHECK clause
# You must allocate at least one auxiliary channel needs before issuing
# the DUPLICATE command. The channel type (DISK or SBT) must match
# the media where the backups of the target database are stored. If you
# allocate TYPE DISK, then the more channels that are allocated, the
# faster the duplicate process will be. For other types the number of
# channels should be limited to the actual number of devices available
# for the operation:
# LOGFILE
# GROUP 1 ('?/dbs/new_g1_l1.dbf',
# '?/dbs/new_g1_l2.dbf') SIZE 512K,
# GROUP 2 ('?/dbs/new_g2_l1.dbf',
# '?/dbs/new_g2_l2.dbf') SIZE 512K
# If restoring to a host with the same structure as the target host, use the
22
# NOFILENAMECHECK clause:
# NOFILENAMECHECK
# SKIP READONLY
RMAN> backup incremental level 1 for recover of copy tag 'BU1_LEV0' database;
RMAN> backup incremental level 1 for recover of copy tag 'BU1_LEV0' database;
23