NetVault Plug-in for Oracle 11.2

If you select the System Change Number Based option, the plug-in instructs RMAN to use the “until scn” clause during table recovery. For example: until scn 5555638

•

If you select the Log Sequence Based option, the plug-in instructs RMAN to use the “until sequence <number> thread <number>” clause during table recovery. For example: until sequence 38 thread 1

•

If you select the Time Based option, the plug-in instructs RMAN to use the “until time” clause during table recovery. For example: until time "to_date('2013/11/23 06:59:00', 'yyyy/mm/dd hh24:mi:ss')"

In the Auxiliary Destination field, specify a directory (full path) that the auxiliary instances use to store all the files needed, including copies of the controlfile, archived logs, and datafiles.

Use of this field is equivalent to the “auxiliary destination '<directoryFullPath>'” clause.


	IMPORTANT: This directory must exist before you run the recovery process. If the directory does not exist, recovery might fail with an ORA-type error.

In the Recover table field, enter a comma-separated list of tables that you want to include in the recovery table as part of a table-level recovery.

Use the oracle_user_name.table_name construct. Oracle® 12c includes common users and local users, and the naming convention used for the local users is similar to the Oracle Database user names in earlier versions of Oracle.

For containers where common users are in place, Oracle Database supplies the SYS and SYSTEM common users. The name of user-created common users must begin with C## or c#. For more information, see the Oracle 12c Multitenant Architecture documentation.


	IMPORTANT: When listing a table from a common user, use double quotation marks. While SQL*Plus accepts queries on the tables using a string that includes C## or c# and excludes the double quotation marks, RMAN does not.

Example 1: The following lists three tables for the sales user.

sales.northsales, sales.southsales, sales.centralsales

Example 2: The following example lists two tables for the common C##SALES user.

"C##SALES"."NORTHSALES", "C##SALES"."SOUTHSALES"

Use of the preceding example is equivalent to the recover table "C##SALES"."NORTHSALES", "C##SALES"."SOUTHSALES" clause.

In the Remap table field, enter a comma-separated list of tables that you want to rename, if applicable, as a part of a table-level recovery.

This option lets you recover the table and analyze it for appropriateness to determine whether to overwrite the original table. You do not need to provide a mapping for every table listed in the Recover table field; you only need to list the mapping for those tables that you want to rename temporarily.

Example 1: The following maps the sales.northsales table to sales.northsales_recovered.

sales.northsales:northsales_recovered

Example 2: The following maps the sales.northsales table to sales.northsales_recovered.

sales.northsales:northsales_recovered, sales.southsales:southsales_recovered

Example 3: The following maps the sales.northsales table to sales.northsales_recovered.

"C##SALES"."NORTHSALES":"NORTHSALES_RECOVERED"

Use of the preceding example is equivalent to the remap table "C##SALES"."NORTHSALES":"NORTHSALES_RECOVERED" clause.

Maintaining the Recovery Catalog

•

Resynchronizing the Recovery Catalog

Plug‑in for Oracle automatically runs a full or partial resynchronization of the Recovery Catalog when performing RMAN backups as long the Control File is mounted and the Recovery Catalog database is available at command execution.

You can use RMAN’s RESYNC CATALOG command to perform manual Full Resynchronizations when:

•

The Recovery Catalog is unavailable when you issue any of the commands that automatically resynchronize the catalog.

•

The database is backed up infrequently and generates a high number of log switches every day. For example, hundreds of archive logs are archived between database backups, and 1000 switches are generated between catalog resynchronizations

•

You have changed the physical structure of the target database such as by adding or dropping a tablespace. As with archive operations, the Recovery Catalog is not updated automatically when the physical schema changes.

You should not need to run RESYNC CATALOG often. For more information, see Using CROSSCHECK to Update the RMAN Repository in the Oracle® Database Backup and Recovery Advanced User’s Guide.

To force a Full Resynchronization of the Recovery Catalog, perform the following steps.

Start RMAN, and connect to the target database and Recovery Catalog.

> rman TARGET / CATALOG rman/<password>@<connect_identifier for catalog>

Mount the target database.

STARTUP MOUNT;

Resynchronize the Recovery Catalog.

RESYNC CATALOG;

Exit RMAN.

Using CROSSCHECK to update the RMAN repository

To ensure that data about backups in the RMAN Repository is synchronized with corresponding data in the NetVault Database, perform a crosscheck. The CROSSCHECK command updates outdated RMAN repository information about backups whose repository records do not match their physical status. For example, if a user removes archive logs from disk with an OS command, the repository still indicates that the logs are on disk, when in fact they are not.

For more information on the CROSSCHECK command, see the Oracle® Database Backup and Recovery Basics guide.

Start RMAN, and connect to the target database and Recovery Catalog.

> rman TARGET / CATALOG rman/<password>@<connect_identifier for catalog>

Crosscheck the archive logs.

CROSSCHECK ARCHIVELOG ALL;

Exit RMAN.