Recover Table With RMAN
Recover Table With RMAN
Recover Table With RMAN
Note:223543.1 22-MAR-2006
-----------------------------------------------------------
1. Restore and recover the primary database to a point in time before the drop.
This is an extreme measure for one table as the entire database goes back in
time.
2. Restore and recover the tablespace to a point in time before the drop.
This is a better option, but again, it takes the entire tablespace back in time.
The tablespace point in time recovery (TSPITR) may be useful if there are
dependencies between the dropped/truncated table and other tables in the
database. For the second option, see RMAN documentation on TSPITR and/or
Note 180436.1 RMAN Tablespace Point in Time Recovery Example. Both procedures
for the second and third options are very much the same. The differences are
that the TABLE PITR has to be exported/imported manually while the TABLESPACE
PITR is fully automated by RMAN.
General overview of procedure to recover from a DROP or TRUNCATE table by using RMAN.
------------------------------------------------------------------------------------
The simpliest method to create this 'dummy' database is to use the RMAN
duplicate command. See:
The difference between the two versions is that Oracle9i duplicate command
allows for a 'SKIP TABLESPACE' option. Thus Oracle9i allows for a duplication
of a subset of the database.
In Oracle8i, you cannot 'skip' tablespaces when using duplicate, so you must
duplicate the entire database. If this is not a desired option, or you must
restore the original database and thus cannot use
the rman DUPLICATE.
NOTE: The remainder of this information is for users who cannot use the
DUPLICATE command in Oracle8i. I.e., you want to restore only a subset
of the Oracle8i database.
Requirements :
--------------
If using the same host as the primary, be VERY careful as you do not want to
restore on top of existing files being used by the primary (production database).
Doing so can corrupt and crash the production database!!!!!!
- be sure all paths for this AUX instance are different than primary.
- be sure CONTROL_FILES parameter has different location but more importantly DIFFERENT NAME.
- add LOCK_NAME_SPACE to any value other than the primary database name.
- change/add SERVICE_NAME=AUX1.
- use the SAME DB_NAME as for the production database
- BE SURE you include the 'alter database rename file' command at the end
of the script. This changes the location and/or name of the online
redo log files.
$ rman cmdfile=table_pitr.cmd
The RMAN-script :
-----------------
run
{
allocate channel t1 type sbt_tape
parms='SBT_LIBRARY=/home/usupport/liblsm.so';
set until time "to_date( '09-10-2005 06:00', 'DD-MM-RRRR HH24:MI')";
restore controlfile;
/* NOTE: Syntax within rman is two single quotes around each name, this may be operating system specific. */
Explanation :
-------------
- Tape channel allocated, but could also be a disk channel, depending
on where the backups are.
- SET NEWNAME
New path for the datafile to be restored. Keep in mind that this is
done on the auxiliary instance and should NOT interfere/overwrite the
prodution database.
$ sqlplus /
SQL> alter database open resetlogs;
This step should ALWAYS be executed outside RMAN via SQL*Plus. If the open
is executed in RMAN it may effect the primary database's entry in the RMAN
catalog. Backups will fail with messages like:
Example:
$ exp userid=system/<password> file=table.dmp
tables=(<owner>.<tablename>, ...) rows=Y
Import the data of the dropped table back into the primary/production database.
Example:
$ imp userid=system/<password> file=table.dmp ignore=Y
RELATED DOCUMENTS
-----------------
Note 62385.1 : Oracle7 Recovery Scenarios and Equivalent RMAN Techniques
Note 180436.1 : RMAN Tablespace Point in Time Recovery Windows Example
Note 109979.1 : RMAN Tablespace Point In Time Recovery (TSPITR) Procedure on Unix.
Note 228257.1 : RMAN Duplicate Database in Oracle9i
Note 73912.1 : RMAN Creating a Duplicate Database -- Oracle8i