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.
• |
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. |
• |
You cannot use the “REMAP” clause to recover tables with named NOT NULL constraints. |
You can also use the following command to add additional channels, if applicable:
For more information on configuring channels, see your Oracle® documentation.
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 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.
Similar example except that it uses a log sequence:
Similar example except that it uses a specific date and time, and it is based on a Windows Server® environment:
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.
Recovers a table from a common user:
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.
© ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center