In fact, it may be possible to survive this situation: you can instruct RMAN to scan your backup devices and locate and identify any backups, but a far preferable situation is to have th
Trang 112 To do an incomplete recovery, what mode must the database be in? (Choose
the best answer.)
A Incomplete recovery can be done only with the database SHUTDOWN
B Incomplete recovery can be done only in NOMOUNT mode
C Incomplete recovery can be done only in MOUNT mode
D Incomplete recovery can be in OPEN mode, if the database is in archivelog mode
E SQL*Plus can do incomplete recovery only in CLOSED mode; RMAN can
do it in any mode
13 When using RMAN to restore a controlfile autobackup, what piece of
information might you need to supply? (Choose the best answer.)
A The database name
B The approximate time of the latest backup
C The database ID
D The instance name
E The instance number
14 You are using RMAN to perform incomplete recovery Which of the following
is the best sequence to follow? (Choose the best answer.)
A shutdown abort / startup mount / restore / recover / open resetlogs
B shutdown immediate / startup mount / restore / open resetlogs / recover
C shutdown immediate / restore / recover / open resetlogs
D shutdown immediate / startup nomount / restore / recover / open resetlogs
15 After a RESETLOGS, what will have changed? (Choose all that apply.)
A There will be a new database incarnation number
B The system change number will be reset
C The log switch sequence number will be reset
D The database ID will be changed
E The instance number will be changed
F All previous backups and archivelogs will be invalid
16 Which of the following statements are correct about block media recovery
(BMR)? (Choose two answers.)
A BMR can be performed only with RMAN
B BMR can be performed only with SQL*Plus
C Both RMAN and SQL*Plus can be used for BMR
D BMR is always a complete recovery
E BMR is always an incomplete recovery
F BMR can be either complete or incomplete; the DBA decides
Trang 217 If, during an RMAN backup, a corrupt block is encountered, what will
happen? (Choose the best answer.)
A The backup will fail
B The backup will succeed
C It depends on the MAXCORRUPT setting
D If the corruption is in the SYSTEM tablespace, the backup will fail;
otherwise, it will continue, but the address of the corrupt block will
be written to the RMAN repository
18 To what file types is BMR applicable? (Choose the best answer.)
A Archive log files
B Controlfiles
C Datafiles
D Online log files
E Tempfiles
F All of the above
19 What will be the effect of issuing this command:
blockrecover corruption list until time sysdate - 7;
(Choose the best answer.)
A The recovery will be up to but not including the system change number of
the time specified
B The recovery will be up to and including the system change number of the
time specified
C The recovery will be complete, but the restore will be from before the time
specified
D The recovery will be of all blocks entered onto the corruption list before
the time specified
E The recovery will be of all blocks entered onto the corruption list after the
time specified
Self Test Answers
1 þ A, D, and G Damage to any controlfile copy will terminate the instance,
as will damage to the critical tablespaces: SYSTEM and the current undo
tablespace
ý B, C, E, F, and H All these are noncritical files, damage to which will not
cause the instance to terminate
Trang 32 þ A An active log file group contains change vectors referring to blocks
that have not yet been written to the datafiles by the DBWn, and cannot be cleared
ý B, C, and D B is wrong because you cannot issue a CLEAR command while a recovery is progress, and D because multiplexing is not relevant to this C is relevant because following a checkpoint the group would no longer
be active, but this is not the best answer
3 þ C This is the only option in noarchivelog mode.
ý A, B, and D These are all attempts at a partial restore, which is not
possible in noarchivelog mode
4 þ A This is a sequence that will work.
ý B, C, and D None of these sequences is feasible.
5 þ B This is a sequence that will work.
ý A, C, and D Advice will be generated only for problems discovered by
a previous List command, and repair scripts will be generated by the Advise stage
6 þ A, D, and E The DRA cannot run against a database that is shut down,
nor against any RAC or Data Guard standby database
ý B and C The DRA can run against a single instance database that is in
nomount, mount, or open mode
7 þ D The repository exists as operating system files in the location specified
by the DIAGNOSTIC_DEST instance parameter
ý A, B, C, and E The repository is not stored in any database tables, nor by
Enterprise Manager
8 þ A The ADVISE FAILURE will refer only to failures previously listed.
ý B, C, and D ADVISE FAILURE can run only following LIST FAILURE in
the same session, and will refer to the information gathered at that time
9 þ C Noncritical datafiles can be restored and recovered while the database
is open, if it is running in archivelog mode
ý A, B, and D Damage to any controlfile copy will cause the instance to
terminate, and it cannot be mounted or opened until the damage is repaired
A current multiplexed online log file cannot be repaired, though it can be cleared when no longer current or active The DRA cannot repair anything—it can only advise
Trang 410 þ D An incomplete recovery is required, and the restore can be from the
most recent backup of each datafile
ý A, B, and C A is wrong because an incomplete recovery can follow
only a restore of the complete set of datafiles (though in this case, a TSPITR
might also have been an option) B is wrong because while it will work, it
is less efficient than A: the recovery would take longer because more redo
would have to be applied C is wrong because there is no way to cancel the
application of one archive log file, and then continue
11 þ A and E Loss of all copies of the current log file group necessitates an
incomplete recovery, as does the reversion of the database to a time when a
dropped tablespace still existed
ý B, C, and D The SYSTEM and UNDO tablespaces can be completely
recovered, even though they are critical to the running of the database An
uncommitted transaction can never be recovered—it will always be rolled back
12 þ C Incomplete recovery can be accomplished only in MOUNT mode.
ý A, B, D, and E MOUNT is necessary, whether you are using RMAN or
SQL*Plus
13 þ C The DBID will be needed to allow RMAN to identify an autobackup of
that particular database
ý A, B, D, and E The database name will be read from the controlfile,
as will details of the last backup The instance name and number are not
relevant
14 þ A This is the correct sequence An IMMEDIATE shutdown would be
acceptable but would take longer
ý B, C, and D These sequences are not possible.
15 þ A and C A RESETLOGS generates a new database incarnation number
and returns the log sequence number to zero
ý B, D, E, and F The SCN continues to increment following a RESET
LOGS, and the DBID remains the same The instance number is not relevant
Previous backups and archive logs will still be usable (though this was not the
case with releases prior to 10g).
16 þ A and D The BMR capability is a strong reason for using RMAN, but it
must be complete
ý B, C, E, and F SQL*Plus cannot do BMR, and an incomplete BMR is not
possible
Trang 517 þ C The MAXCORRUPT setting can be used to allow a backup to skip over
one or more corrupted blocks
ý A, B, and D By default, a corrupt block will cause a backup to fail, but
this behavior can be changed It makes no difference in which tablespace the corrupt block is found
18 þ C Only datafile blocks can be recovered with BMR.
ý A, B, D, E, and F Neither log files (of any kind) nor tempfiles can be
recovered BMR cannot be applied to the controlfile: it must be restored and recovered as a whole
19 þ C The UNTIL clause in this context determines the latest backup that may
be restored
ý A, B, D, and E A and B are wrong because BMR can be only complete
D and E are wrong because the entire corruption list is always restored and
recovered by this command
Trang 6CHAPTER 17
Advanced RMAN Facilities
Exam Objectives
In this chapter you will learn to
• 053.3.1 Identify Situations That Require an RMAN Recovery Catalog
• 053.3.2 Create and Configure a Recovery Catalog
• 053.3.3 Synchronize the Recovery Catalog
• 053.3.4 Create and Use RMAN Stored Scripts
• 053.3.5 Back Up the Recovery Catalog
• 053.3.6 Create and Use a Virtual Private Catalog
• 053.8.1 Create a Duplicate Database
• 053.8.2 Use a Duplicate Database
• 053.7.5 Restore a Database onto a New Host
• 053.7.7 Perform Disaster Recovery
• 053.9.1 Identify the Situations That Require TSPITR
• 053.9.2 Perform Automated TSPITR
• 053.10.1 Monitor RMAN Sessions and Jobs
• 053.10.2 Tune RMAN
• 053.10.3 Configure RMAN for Asynchronous I/O
641
Trang 7Using RMAN for basic backup, restore, and recovery operations has been covered in Chapters 15 and 16 This chapter deals with some more advanced capabilities First
is the recovery catalog: a storage structure for the RMAN repository that, while not essential, will make many operations much simpler Second, there are facilities for creating databases Third is tablespace point-in-time recovery: a technique for performing
an incomplete recovery on just a part of the database Finally, we’ll cover some considerations regarding performance and monitoring
The Recovery Catalog
RMAN requires a repository in which to store details of all the backups it has made
The repository is a store of metadata about the target database and its backups It contains details of the physical structure of the database: the locations of the datafiles; details of all the backups that have been made; and RMAN’s persistent configuration settings The repository is always stored in the controlfile of the target database, and optionally in a recovery catalog as well
EXAM TIP The RMAN repository always exists in the target database
controlfile, but it only has data going back as far as the CONTROLFILE_ RECORD_KEEP_TIME parameter The recovery catalog is an additional store that can retain data indefinitely
If the repository is lost, then RMAN is crippled Your backups will be fine, but RMAN won’t know where they are However, it should still be possible to rebuild the repository and continue to work, provided appropriate precautions have been taken
TIP To avoid dependency on the target database controlfile, use a recovery
catalog, or if this is not possible, you must enable the controlfile autobackup facility
The Need for a Recovery Catalog
RMAN’s repository is always written to the target database’s controlfile, but it can also
be written out to a schema in a separate Oracle database This database is known as the recovery catalog Using RMAN with a recovery catalog enhances its capabilities substantially
First, and perhaps most important, with a recovery catalog you are no longer dependent upon the target database controlfile What if all copies of the controlfile are destroyed? Your backups are perfect, but without a repository, RMAN will never be able to find them In fact, it may be possible to survive this situation: you can instruct RMAN to scan your backup devices and locate and identify any backups, but a far preferable situation is to have the repository always available in a recovery catalog database, on a separate machine from the target
Second, the recovery catalog can store RMAN scripts Without a recovery catalog, you can still use scripts but they have to be stored as operating system files on the machine where you are running the RMAN executable
Trang 8Third, if you are supporting many databases, one recovery catalog can be used
to store metadata about all of them It becomes a centralized repository of all your
backup and restore information Note that one catalog can be used with databases on
any platform You could, for example, run the RMAN executable on a Windows PC
and connect to a recovery catalog in a database on a Unix host, and then connect to
a series of target databases on Windows, Unix, Open VMS, and any other platform
Fourthly, some operations are greatly simplified with a recovery catalog For
example, the target database need not be in MOUNT mode, as is required for all
RMAN operations otherwise (with the one exception of RESTORE FROM
AUTOBACKUP) While connected to a recovery catalog, RMAN can locate backups
of the spfile and controlfile and restore them, greatly simplifying the bootstrapping
process of recovering a severely damaged database Related to this is the ability to
create a new database from a backup of the original
And last, there is no limit to the length of time for which a recovery catalog can
retain this metadata The controlfile-based repository will retain data for only the time
specified by the instance parameter CONTROL_FILE_RECORD_KEEP_TIME This
defaults to just seven days You can certainly increase the value of this parameter, but
to increase it to, for example, several months would be to use the controlfile for a
purpose for which it was never intended: it is meant to be a store of currently relevant
information, not a long-term storage place
The recovery catalog database will usually not be a particularly large or busy
database, and it will not have very demanding resource requirements, but it will
improve RMAN functionality significantly
Creating and Connecting to the Catalog
The RMAN executable can connect, concurrently, to up to three database instances:
• A target database, to which a backup or restore and recover operation will be
applied
• A recovery catalog database, where metadata describing the target and all
available backups is stored
• An auxiliary database, which is a database to be created using backups of
the target
The catalog must be created This entails identifying (or creating) a database to use
and then creating a tablespace where the catalog objects will be stored and a user to
whose schema they will belong The user should be granted the RECOVERY_CATALOG_
OWNER role, which includes the necessary object privileges For example, run these
commands in the database to be used for the catalog:
create tablespace rmancat datafile 'rmancat01.dbf' size 200m;
create user rman identified by rman default tablespace rmancat
quota unlimited on rmancat;
Trang 9TIP There is nothing special about the RECOVERY_CATALOG_OWNER role:
it is just a few system privileges Run this query to see what it can do:
select privilege from dba_sys_privs where GRANTEE='RECOVERY_CATALOG_OWNER';
Then to create the catalog, connect with the RMAN executable and run the
CREATE CATALOG command, as in Figure 17-1
The first command in Figure 17-1 runs the RMAN executable from an operating system prompt, specifying that the connection should be to a database containing
an RMAN catalog The connection will be made as the user RMAN identified by the password rman, through a TNS connect string catdb The first command executed at the RMAN prompt is CREATE CATALOG This will generate the catalog objects If there were already a catalog in that schema, the command would return an error The second command at the RMAN prompt connects to a target database as user SYS, using the TNS connect string ORCL The third RMAN command registers the target in the catalog: the registration process copies all relevant information from the target database’s controlfile into the catalog; if the target database were already registered, this would return an error From this point it is possible to connect to both catalog and target with one command from an operating system prompt:
rman target / catalog rman/rman@catdb
EXAM TIP RMAN connections to a target will usually be as SYS because of
the common need to issue startup and shutdown commands There is no need
to specify AS SYSDBA—this is assumed by the tool
Figure 17-1 Creating a catalog and registering a database
Trang 10The syntax in the preceding example is the most commonly used It uses operating
system authentication to connect as user SYS to a local database, and then connects to
a remote catalog database as user RMAN using Oracle Net The RMAN executable must
be the same release as the target database, which will always be the case if it is run
locally from the target, using the same Oracle Home The RMAN executable need not
be the same version as the RMAN catalog, so there will not be a problem with connecting
to it across a network Alternative syntax would be
rman target sys/oracle@orcl catalog rman/rman
This syntax connects to the target as SYS using password file authentication and
Oracle Net, and to the catalog in a local database as user RMAN This will often work
but is not always advisable because of the possibility of version incompatibilities
between the executable and target
The catalog must be created with a version of RMAN that is equal to or higher
than the version of any database that will be registered in it It is therefore possible to
create a single catalog of version 11.1.0.6 (11g release 1 patch set 6, the first production
release of 11g) and use this to register 11g, 10g, and 9i databases For each target, use
the version of the RMAN executable installed in the target’s Oracle Home
EXAM TIP The RMAN executable must be the same version as the target
database, and less than or equal to the version of RMAN used to create the
catalog
The Virtual Private Catalog
One catalog can register details of all databases in an organization, but in some
circumstances it will be desirable to create one or more virtual private catalogs Security
rules may require a separation of duties: some DBAs will be responsible for some
databases; other DBAs will be responsible for other databases To assist in this, RMAN
has the capacity to create virtual private catalogs: as a DBA, you can register your own
databases in what appears to be your own, private, catalog, and you will not be able
to see any databases registered in any other private catalogs This feature allows the
consolidation of several catalogs into one, without compromising security
The steps to create and use virtual private catalogs are
1 Create the catalog as normal
2 Create an additional schema, and grant it the RECOVERY_CATALOG_OWNER
role and the CREATE_SESSION system privilege
3 Connect to the catalog as the catalog owner with RMAN, and issue this
command:
grant register database to vpcowner;
where vpcowner is the name of the user created in Step 2 This will allow
vpcowner to register his own databases.