Tchater maintenant avec le support
Tchattez avec un ingénieur du support

NetVault Plug-in for Oracle 10.0.5 - User Guide

Introducing Dell™ NetVault™ Backup Plug-in for Oracle® Defining a backup strategy Installing and removing the plug-in Configuring the plug-in Backing up data Using the Oracle® Flashback Database Restoring data
Restoring and recovering data: an overview Performing User Managed restores Using advanced User Managed restore procedures Performing RMAN restores Using RMAN types of recovery in a non-RAC environment Using advanced procedures with RMAN restores
Maintaining the Recovery Catalog Using the RMAN CLI Using the Plug-in with Oracle® RAC Using the Plug-in in a failover cluster environment Using the plug-in with Oracle® Data Guard Troubleshooting Glossary

Uses of table-level recovery

Table-level recovery lets you recover one or more tables or table partitions to a specific point without affecting other tables or database objects. You can use backups created using the plug-in's RMAN backup method to accomplish this process. In addition to other recovery methods, table-level recovery is useful when you need to recover:
•
A few tables to a specific point.
•
Tables that were dropped and purged.
•
Tables that are logically corrupted.
•
A table for which the Flashback Table command is unavailable (for example, the Flashback Table cannot rewind because of structural changes, or the target point is older than the undo point).

Table-level requirements and limitations

There are Oracle® Database-specific limitations and requirements for performing this type of recovery. To perform recovery successfully, review the following requirements and limitations (for more information, including a complete list of constraints, see the table-level recovery information in your Oracle documentation).
•
Table-level recovery is available in the Enterprise Edition of Oracle Server 12.1 or later.
•
To use automated table-level recovery, the directory specified in the “Auxiliary Destination” clause must exist before running recovery. You can use an existing empty directory, or create a directory, if the directory exists before starting the process.
•
You must use the CONFIGURE command to configure the channels in RMAN. The auxiliary database uses the same channels as the target database.
•
Full backups of the tablespaces SYSTEM, SYSAUX, undo (that is, UNDOTBS1), and SYSEXT (if the SYSEXT tablespace is present) must exist. The tablespace that contains the table that is the target of the recovery must also exist.
•
You cannot use table-level recovery to recover: tables that belong to SYS, tables from the SYSTEM and SYSAUX tablespaces, or tables on standby databases.
•
You cannot use the “REMAP” clause to recover tables with named NOT NULL constraints.

Configuring channels for table-level recovery

To use the plug-in for recovery, you must configure SBT channels in RMAN. These channels connect RMAN and the NetVault Backup media management utilities. You can configure a default SBT channel, as well as additional channels of type SBT or DISK. To display the current RMAN configuration, run the following command from an RMAN prompt:
RMAN> SHOW ALL;
If no SBT channels are configured (only settings for DISK channels exist), use the following command to instruct RMAN to add a set of settings for SBT channels:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
When these settings are added for SBT channels and a table-level recovery is run, at least one DISK channel and one SBT channel are available for the recovery process. The auxiliary instance uses the same channels that are available for the target instance.
You can also use the following command to add additional channels, if applicable:
RMAN> CONFIGURE CHANNEL <channelNumber> DEVICE TYPE sbt
For more information on configuring channels, see your Oracle® documentation.

Performing table-level recovery from the RMAN CLI

As stated previously, the examples are based on using the fully automated version of the auxiliary instance. For additional examples on using an automated auxiliary instance or a user-managed auxiliary instance, both of which can be used with the plug-in to perform table-level recovery, see your Oracle® documentation. Note the following:
•
Table-level recovery requires the use of the “until” clause to define the state that you want to recover to.
•
The following examples assume that you are connected to the target instance and, if applicable, the RMAN recovery catalog.
Examples
The following example recovers three tables of an Oracle® user, sales, to a specific SCN using a fully automated auxiliary instance for which the required files are populated in a Linux® or UNIX® directory, /oracle/nvbu_pitr_auxiliary_destination, which you created before running recovery.
RMAN> recover table SALES.NORTHSALES, SALES.SOUTHSALES, SALES.CENTRALSALES
until scn 5555638
auxiliary destination '/oracle/nvbu_pitr_auxiliary_destination';
Similar example except that it uses a log sequence:
RMAN> recover table SALES.NORTHSALES, SALES.SOUTHSALES, SALES.CENTRALSALES
until sequence 38 thread 1
auxiliary destination '/oracle/nvbu_pitr_auxiliary_destination';
Similar example except that it uses a specific date and time, and it is based on a Windows Server® environment:
RMAN> recover table SALES.NORTHSALES, SALES.SOUTHSALES, SALES.CENTRALSALES
until time "to_date('2013/11/23 06:59:00', 'yyyy/mm/dd hh24:mi:ss')"
auxiliary destination 'C:\app\Administrator\product\11.2.0\dbhome_1\nvbu_pitr_auxiliary_destination';
Using the remap table option, the following example recovers two of the three selected tables to a new table with a different name. (The third table is recovered with the same name as the original.)
RMAN> recover table SALES.NORTHSALES, SALES.SOUTHSALES, SALES.CENTRALSALES
until time "to_date('2013/11/23 06:59:00', 'yyyy/mm/dd hh24:mi:ss')"
remap table sales.northsales:northsales_recovered, sales.southsales:southsales_recovered
auxiliary destination 'C:\app\Administrator\product\11.2.0\dbhome_1\nvbu_pitr_auxiliary_destination';
Recovers a table from a common user:
RMAN> recover table "C##SALES"."NORTHSALES", "C##SALES"."SOUTHSALES"
until scn 5555638
remap table "C##SALES"."NORTHSALES":"NORTHSALES_RECOVERED"
auxiliary destination '/oracle/nvbu_pitr_auxiliary_destination';
By default, RMAN imports the recovered tables or table partitions into the target database. Before import, the tables are stored in an export dump file. You can use the NOTABLEIMPORT option to prevent RMAN from importing the recovered tables or table partitions. If you use this option, the tables are recovered to the specified point, and the export dump file is created, but the dump file is not imported into the target database. At that point, you can analyze the tables using the auxiliary instance, or manually import the dump file into the target database instance using the Oracle Data Pump Import utility.
RMAN> recover table "C##SALES"."NORTHSALES", "C##SALES"."SOUTHSALES"
until time 'SYSDATE-4'
auxiliary destination '/oracle/nvbu_pitr_auxiliary_destination'
datapump destination '/oracle/nvbu_pitr_datapump_destination'
dump file 'northsales_southsales_export_dump.dat'
notableimport;
 
* 
NOTE: If errors occur during recovery, Oracle does not delete the export dump file if the recovered table created one. You can then use the export dump file to complete the recovery process manually.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation