OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P70 pot

OCA/OCP Oracle Database 11g All-in-One Exam Guide
646
4. If you wish the new user to have privileges on databases already registered,
issue this command:
grant catalog for database dbname to vpcowner;
where dbname is the name of an already registered database that you wish
vpcowner to manage.
5. As vpcowner, connect to the catalog with RMAN, and issue the command
create virtual catalog;
6. Using RMAN, connect to the catalog as vpcowner and to the target as SYS, register
the target (if was not previously registered), and then carry out backup and
restore operations as normal.
The owner of a virtual private catalog will have no access to backups relating to
databases not registered in their domain, and need have no object or tablespace privileges
in the catalog database, nor any system privileges beyond those granted in Step 2.
TIP A GRANT REGISTER DATABASE will insert a row in VPC_USERS, a
table in the catalog owner’s schema. A GRANT CATALOG FOR DATABASE
will insert a row in the VPC_DATABASES table. The virtual catalog owner has
synonyms that allow these tables, which are used to filter access to be seen.
Protecting and Rebuilding the Catalog
If the recovery catalog is not available, RMAN can still function—but it will be crippled.
Because the RMAN repository is always stored in the target databases’ controlfiles, loss
(temporary or permanent) of the catalog is not disastrous. But the controlfile-based
repository will only hold a relatively small amount of information—all data older than
the CONTROLFILE_RECORD_KEEP_TIME parameter will be overwritten. So while
backups can still be performed, any restore and recover operations will be much harder.
Backup sets and image copies going back weeks may be available, but RMAN will not be
able to find them. Furthermore, any stored scripts will also be unavailable. It is therefore
necessary to protect the catalog database. And worst of all, if all copies of the controlfile
itself are lost, then RMAN will be useless—unless the controlfile autobackup facility has
been enabled (which it should always be).

There is a recursive problem with backing up the catalog database. If you back it up
with RMAN, then if it needs to be restored, RMAN will not be able to do the job. So,
unless you have a second catalog database and use this to register the first, you will have
to use a user-managed backup technique. These are fully described in Chapter 18.
The catalog schema is not very big, nor very busy. Even if the catalog is supporting
hundreds of databases, it will usually be only a few gigabytes. It may therefore be feasible
to make full whole offline backups regularly: simply shut it down, and copy it. This,
together with the archive logs (as with any production database, the catalog database
should be run in ARCHIVELOG mode), will be an adequate backup—if you can stand
the downtime. Alternatively, it may be possible to make a logical backup, using the
export/import utilities or the newer Data Pump facility (described in Chapter 23).
Chapter 17: Advanced RMAN Facilities
647
PART III
If backups are made without connecting to the catalog for any reason (such as the
catalog being unavailable—perhaps because it was down for a cold backup), then
the catalog repository must be resynchronized with the controlfile repository. This
will happen automatically the next time RMAN connects to both the target and the
catalog. The resync operation transfers all information from the controlfile repository
into the catalog, thus bringing it up to date. Data about backups will therefore only be
lost if the period without a resync exceeds the CONTROLFILE_RECORD_KEEP_TIME.
TIP All backup events that occur while not connected to the catalog, as well
as information regarding archive log generation and physical changes such as
datafile creation, are transferred into the catalog by an automatic resync at the
next connection. You can also force a resync from the RMAN prompt with
the RESYNC CATALOG command.
But what if the controlfile and perhaps other parts of the target database are
lost, and the catalog is lost too? The backups (backup sets and image copies) may
be perfect, but RMAN will not be able to find them. Of course, it should be possible
to restore the catalog—but assume that it is not. The first step is to connect to the

target with the RMAN executable, and start it in NOMOUNT mode. Even if there is
no parameter file, this will succeed because RMAN will start the instance with a
dummy parameter file; Figure 17-2 shows this procedure. Of course, the startup
will stop in NOMOUNT mode: there will be no controlfile to mount.
Once the instance is started, if you know where the backups of the controlfile and
spfile are located, instruct RMAN to restore them from this location; or if autobackup
had been enabled, use the technique described in Chapter 16. Then restart the instance
with the restored spfile, and mount the database with the restored controlfile. Then, if
Figure 17-2 Starting a Windows instance, with RMAN and no parameter file
OCA/OCP Oracle Database 11g All-in-One Exam Guide
648
you know where the other backup sets are stored, register them in the controlfile-based
repository with the CATALOG command. For example,
catalog datafilecopy '/u02/dfcopies/example01/dbf';
catalog backuppiece '/u02/backupsets/TAG20081028T174426_4JGMW1R9_.BKP';
catalog start with '/u01/app/oracle/flash_recovery_area';
The first of these commands registers an image copy of a datafile, which could
have been made either by RMAN or by a user-managed backup. Similar syntax can
register copies of the controlfile and of archive log files. The second command registers
a backup set piece. Note that in neither case is it necessary to tell RMAN what the copy
or backup set contains: RMAN can work this out by inspecting the file contents. The
third command is the most powerful: it instructs RMAN to go to a directory (in the
example, the root of the flash recovery area) and navigate down all subdirectories
cataloging every copy and backup set piece that it finds. By giving a tape device as the
path, RMAN can rebuild an entire repository. Follow up the catalog commands by
connecting to each target database. The automatic RESYNC operation will populate
the catalog with any information from the repositories in each controlfile that has not
already been inserted.
While it is possible to create a new, empty, RMAN catalog and then populate it
(always assuming that you know where the backups are) with the CATALOG and

RESYNC CATALOG commands, it is far more preferable to back up your catalog so
that if it is damaged, you can restore it.
By all means back up your catalog database with RMAN. Connect to it as a target,
and back it up as you would any other target. Be sure to enable the autobackup facility.
But do not back up your recovery catalog database only with RMAN! If it is damaged,
there could be a recursive problem with any attempt to restore: if either the controlfile
or the tablespace containing the catalog were damaged, any attempt to open the
database and then connect to it as a catalog must fail. The autobackup will help you
to survive this situation, but it will be necessary to protect the catalog database by
other means—perhaps user-managed backups (detailed in Chapter 18), or using
operating system– and hardware-based techniques, or using the Data Pump facility
(described in Chapter 23) to make a logical backup.
Exercise 17-1: Create a Recovery Catalog In this exercise, you will create a
recovery catalog. Use any database you have available, even the one you intend to use
as a target—though this would not be acceptable for a production environment. The
examples assume that the catalog database is reachable through the TNS connect string
CATDB, and that the target is a local database to be connected to with operating
system authentication.
1. Connect to the catalog database using SQL*Plus as user system:
sqlplus system/oracle@rman
2. Create a tablespace in the catalog database, with a command such as
create tablespace rman datafile '/u01/oradata/orcl/rman01.dbf' size 50m;
Chapter 17: Advanced RMAN Facilities
649
PART III
3. Create a schema to hold the catalog, using the new tablespace as the default
tablespace:
create user rman identified by rman default tablespace rman;
4. Grant privileges to the new schema:
grant recovery_catalog_owner to rman;

alter user rman quota unlimited on rman;
5. From an operating system prompt, launch the RMAN executable and connect
to the catalog database as the new user:
rman catalog rman/rman@catdb
6. Create the catalog:
create catalog;
7. Exit from RMAN, and from an operating system prompt connect concurrently
to both the catalog and the target:
rman catalog rman/rman@catdb target /
8. Register the target and see if any RMAN backups have been made:
register database;
list backup of database;
If no backups are listed, perform a full backup (as detailed in Chapter 15).
9. Exit from RMAN, and use SQL*Plus to query some views that will confirm
that the target has been registered and that backups have been made:
sqlplus rman/rman@catdb
SQL> select dbid,name from rc_database;
SQL> select db_id,bs_key,backup_type from rc_backup_set;
Stored Scripts
RMAN scripts can be stored as operating system files, and invoked from the command line.
For example, if these two commands are saved into a file named rman_script.rmn,
run {backup database plus archivelog delete all input;
delete obsolete;}
then the script can be invoked from an operating system prompt as follows:
rman target / catalog rman/rman@catdb @rman_script.rmn
However, if you have a catalog, you can use it to store scripts. There are six script-
related commands:
create [ global ] script
replace [ global ] script
print [ global ] script

list [ global ] script names
execute [ global ] script
delete [ global ] script
OCA/OCP Oracle Database 11g All-in-One Exam Guide
650
TIP There is no command to edit a script. However, you can query the views
RC_STORED_SCRIPT and RC_STORED_SCRIPT_LINE to view scripts, and
edit them by using DML against these views. Of course, you bypass all the
syntax checking if you do this. The views will not show global scripts.
The commands are all self-explanatory. By default, scripts are database-specific. If
you want to run the same script against many targets, you must connect to each target
and create it many times. But if the GLOBAL keyword is used, then the script will be
visible to all targets. While global scripts are very useful, care must be taken to ensure
that they will run against any target you wish. For example, if a script includes a FORMAT
clause to name the backup pieces, the path element of the piece name would have to be
different for Unix targets and Windows targets because of the different form of the
directory delimiter on these operating systems. Extensive use of the CONFIGURE
command will allow more use of global scripts, because the scripts behavior will
then be modified transparently by each target.
TIP You can convert RMAN scripts stored as operating system files to scripts
stored within the catalog with this command:
create script script_name from file 'file_name';
Figure 17-3 demonstrates the creation and running of a stored script. Note the
automatic resync of the recovery catalog: this will update the catalog with any changes
Figure 17-3 Creating and executing an RMAN stored script
Chapter 17: Advanced RMAN Facilities
651
PART III
that have occurred since the last resync, such as datafile adjustments and archivelog
generation, so that the catalog will be aware of the current state of the database.

Using RMAN to Create Databases
To clarify some naming conventions, the target database is the existing database you
want to copy. The auxiliary database is the new database created from the target. The
target and the auxiliary may be on the same server or on different machines. The
examples that follow assume that you are duplicating a database and instance named
orcl to a database and instance named newdb.
Here are the general steps to follow to create a duplicate database:
1. Install the Oracle Home on the node that will host the auxiliary database.
2. Create a password file for the auxiliary instance.
3. Ensure network connectivity to the auxiliary instance.
4. Create an initialization parameter file for the auxiliary instance.
5. Start the auxiliary instance as NOMOUNT.
6. Start the target database in MOUNT or OPEN mode.
7. Create backups or copy existing backups and archived redo log files to a
location accessible to the auxiliary instance, unless you are using active
database duplication.
8. Allocate auxiliary channels if necessary.
9. Run the RMAN DUPLICATE command.
10. Open the auxiliary instance.
You must create a password file in the Oracle home for the auxiliary database. For
example,
orapwd file=$ORACLE_HOME/dbs/oranewdb password=oracle1 entries=3
Note that the location for all database password files is $ORACLE_HOME/dbs on
Unix, or %ORACLE_HOME%\database on Windows. The file itself must be named
ora<SID> on Unix, and PWD<SID>.ora on Windows, where <SID> is the new
instance name.
You must ensure network connectivity to the auxiliary. This will entail launching
a listener process if the auxiliary is on a different server, and in any case configuring a
tnsnames.ora file entry that will connect to the new instance.
The next step is to create an initialization parameter file for the auxiliary instance,

in the same location as the password file. Only DB_NAME must be specified; all other
parameters are optional, depending on whether you use Oracle Managed Files or you
want to specify an alternative location for one or more file destinations. Table 17-1
lists the parameters you can specify in the auxiliary initialization file along with their
descriptions and under what circumstances they are required.
OCA/OCP Oracle Database 11g All-in-One Exam Guide
652
Note that the DB_FILE_NAME_CONVERT parameter can be specified when
you run the DUPLICATE command. Here is an initialization parameter file for an
auxiliary instance, using the CONVERT parameters to map the names of the target
files to those to be used in the auxiliary:
DB_NAME=NEWDB
DB_BLOCK_SIZE=8192
CONTROL_FILES=('/u01/app/oracle/oradata/newdb/control01.ctl',
'/u01/app/oracle/oradata/newdb/control02.ctl',
'/u01/app/oracle/oradata/newdb/control03.ctl')
DB_FILE_NAME_CONVERT=('/u01/app/oracle/oradata/orcl/',
'/u01/app/oracle/oradata/newdb/')
LOG_FILE_NAME_CONVERT=('/u01/app/oracle/oradata/orcl/',
'/u01/app/oracle/oradata/newdb/',
'/u06/app/oracle/oradata/orcl/',
'/u06/app/oracle/oradata/newdb/')
Using the initialization parameter file you just created, start the instance in
NOMOUNT mode. Set your ORACLE_SID environment variable to the name of the
new instance, and start it in NOMOUNT mode using the new parameter file. On Unix:
export ORACLE_SID=newdb
Initialization Parameter Value(s) Required?
DB_NAME
The name you specify
in the DUPLICATE

command, which must
be unique among
databases in the
destination ORACLE_
HOME.
Ye s
CONTROL_FILES
All controlfile locations. Yes, unless you use Oracle-
Managed Files (OMF)
DB_BLOCK_SIZE
The block size for the
duplicate database. This
size must match the
source database.
Yes, if not using the
default (which is 2KB)
DB_FILE_NAME_CONVERT
Pairs of strings for
converting datafile and
tempfile names.
No
LOG_FILE_NAME_CONVERT
Pairs of strings to
rename online redo
log files.
No
DB_CREATE_FILE_DEST
Location for OMF
datafiles.
No, unless using OMF

DB_CREATE_ONLINE_LOG_DEST_n
Location for OMF
online redo log files.
No, unless using OMF
DB_RECOVERY_FILE_DEST
Location of the flash
recovery area.
No
Table 17-1 Auxiliary Instance Initialization Parameters
Chapter 17: Advanced RMAN Facilities
653
PART III
Or on Windows,
set ORACLE_SID=newdb
and then treat the Windows service:
oradim –new –sid newdb
and then,
sqlplus / as sysdba
startup nomount
If the target database is not already open, start it in MOUNT or OPEN mode.
All datafile backups of the target, including incremental backups and archived
redo log files, must be available on a file system accessible by the auxiliary instance.
Alternatively, you can perform an active database duplication, in which case you do
not have to create or copy backups for the operation in advance. Either way, the
directories in which the auxiliary database files will be created must exist.
Now use RMAN to connect concurrently to both the target database and to the
newly started auxiliary instance. Allocate channels (possibly several, which may
reduce the time needed) against both, and execute the DUPLICATE command. This
must be done within a run block:
rman target sys/oracle@orcl auxiliary sys/oracle@newdb

run { allocate auxiliary channel a1 device type disk;
allocate auxiliary channel a2 device type disk;
allocate channel t1 type disk;
allocate channel t2 type disk;
duplicate target database to newdb;}
This example will create the new database from existing backups. Alternative
syntax to use the live database as the source rather than a backup is
duplicate target database to newdb from active database;
In summary, here is what the DUPLICATE command does:
• Creates a controlfile for the duplicate database.
• Restores the target datafiles to the duplicate database or copies directly from
the running database.
• Performs incomplete recovery up to the last archived redo log file.
• Shuts down and restarts the auxiliary instance.
• Opens the auxiliary database with the RESETLOGS option to create the online
redo log files.
• Generates a new DBID for the auxiliary database.
OCA/OCP Oracle Database 11g All-in-One Exam Guide
654
The generation of a new DBID is critical: RMAN distinguishes databases by their
DBID, not by their DB_NAME, and if a new DBID were not generated, RMAN would
not be able to tell the two databases apart.
A duplicate database can be used for many things, including the following:
• Test backup and recovery procedures without disrupting the production
database.
• Create development and UAT systems.
• Generate reports that would otherwise have a detrimental effect on the
response time for an online transaction processing (OLTP) production system.
• Export a table from the duplicate database that was inadvertently dropped
from the production database, and then import it back into the production

database.
Tablespace Point-in-Time Recovery (TSPITR)
Tablespace point-in-time recovery, or TSPITR, is a technique for performing incomplete
recovery on just a part of the database. Incomplete recovery must, as a general rule,
be applied to the whole database: as described in Chapter 16, all the datafiles must be
restored, and rolled forward together. The TSPITR technique creates an auxiliary
database from a subset of the tablespaces of the target database, performs an incomplete
recovery on just this subset, and then replaces the tablespaces in the target database
with those from the auxiliary. The end result appears as though just the subset has
been restored and recovered, leaving the remainder of the target database up-to-date.
Doing this manually would be a nontrivial task.
The TSPITR Methodology
RMAN facilitates automatic TSPITR, making it easy to restore the contents of one or
more tablespaces to a previous point in time without affecting other tablespaces
or other objects in the database. TSPITR is a useful recovery tool for these scenarios:
• Corruption or deletion of rows in key tables that occur in a logically isolated
tablespace; in other words, no indexes or parent/child relationships from
objects in other tablespaces
• Incorrect Data Definition Language (DDL) changes the structure of one or
more tables in a tablespace, such that Flashback Table is not available to
recover these tables
• A table dropped with the PURGE option
TSPITR is not a cure-all for all tablespace disasters. For example, you cannot use
it to recover a dropped tablespace. You also cannot recover a renamed tablespace to
a point in time before it was renamed.
Chapter 17: Advanced RMAN Facilities
655
PART III
First, some terminology:
• Target time The point in time or SCN to which the tablespace(s) will be

recovered
• Recovery set The group of datafiles containing the tablespace(s) to be
recovered
• Auxiliary set Other datafiles required to recover the tablespace(s), such as
the datafiles for the SYSTEM, UNDO, and TEMP tablespaces
• Auxiliary destination A temporary location to store the auxiliary set of files,
including online and archived redo log files, and a copy of the controlfile
created during the recovery process
The key to TSPITR is an auxiliary instance to facilitate the recovery process, as covered
earlier in this chapter. The auxiliary instance does the work of restoring a backup
controlfile from before the desired point in time, restores the recovery set and the
auxiliary set from the target database, and finally recovers the database for the
auxiliary instance to the desired point in time. Here is a complete list of steps that
RMAN performs during TSPITR:
1. Starts an auxiliary instance with a randomly generated name.
2. Restores a controlfile to the auxiliary instance, and mounts the auxiliary
database.
3. Restores the datafiles for the recovery set to the auxiliary database.
4. Restores the datafiles for the auxiliary set to the auxiliary database.
5. Recovers the auxiliary database to the desired point in time.
6. Exports the dictionary metadata for the recovered tablespace from the
auxiliary database.
7. Imports the dictionary metadata for the recovered tablespace into the target
database.
8. Deletes all auxiliary files.
Steps 6 and 7 are critical. The export process writes out the definitions of all objects
in the auxiliary tablespace set as they are at the point in time to which the recovery
was made; the import process then reads this information into the target database,
replacing all current definitions. This completes the process of taking the affected
tablespace(s) back to a previous point in time, while leaving the remainder of the

target database current. There is one final step that must be performed manually:
bringing the recovered tablespace online.
Perform Automated TSPITR
Performing a TSPITR with RMAN is simple—but there are a few steps to be done
before and after to ensure a successful operation.