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

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

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)

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

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

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

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

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

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:

in the DUPLICATE command, which must

be unique among databases in the destination ORACLE_

HOME.

Yes

Oracle-Managed Files (OMF)

duplicate database This size must match the source database.

Yes, if not using the default (which is 2KB)

converting datafile and tempfile names.

No

rename online redo log files.

No

datafiles.

No, unless using OMF

DB_CREATE_ONLINE_LOG_DEST_n Location for OMF

online redo log files.

No, unless using OMF

recovery area.

No

Table 17-1 Auxiliary Instance Initialization Parameters

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

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

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