A RMAN RECOVERY SCENARIO

Question

hellow,
I am working on a rman recovery scenario as follows:
---I have a full backup on sunday
---My database in archivelog mode
---now I lost one of table on Monday 7:20PM
---then I lost another table on same day at 7:40PM
---I came to know about this(both table drop incident) at 7:45PM same day
---Now I have to recover both the tables
---I have catalog database configured
please tell me step by step, how the recovery should be done?
And I also want to know where I can find such scenarios on which I can work any book or web resource?

Answer 1

This is an abstract of http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/flashptr006.htm#sthref651
DBPITR within the current incarnation is performed using the current control file. When performing DBPITR, you can avoid errors by using the SET UNTIL command to set the target time at the beginning of the process, rather than specifying the UNTIL clause on the RESTORE and RECOVER commands individually. This ensures that the datafiles restored from backup will have timestamps early enough to be used in the subsequent RECOVER operation.
The steps required for DBPITR are as follows:
Connect RMAN to the target database and, if applicable, the recovery catalog database. Bring the database to a MOUNT state:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Perform the following operations within a RUN block:
Use SET UNTIL to specify the target time, restore point, SCN, or log sequence number for DBPITR. If specifying a time, then use the date format specified in the NLS_LANG and NLS_DATE_FORMAT environment variables.
If automatic channels are not configured, then manually allocate disk and tape channels as needed.
Restore and recover the database.
The following example performs DBPITR on the target database until SCN 1000:
RUN
SET UNTIL SCN 1000;
# Alternatives:
# SET UNTIL TIME 'Nov 15 2004 09:00:00';
# SET UNTIL SEQUENCE 9923;
RESTORE DATABASE;
RECOVER DATABASE;
Note:
You can also use time expressions, restore points, or log sequence numbers to specify the SET UNTIL time:
SET UNTIL TIME 'Nov 15 2004 09:00:00';
SET UNTIL SEQUENCE 9923;
SET UNTIL RESTORE POINT before_update;
If the operation completes without errors, then your DBPITR has succeeded. You can open the database read-only and perform queries as needed to ensure that the effects of the logical corruption have been reversed. If not, you may have chosen the wrong target SCN. In such a case, investigate the unwanted change further and determine a new target SCN, then repeat the DBPITR process.
7.6.4.1 Using a Time Expression for Database Point-in-Time Recovery
You can use a time expression instead of the SCN in the SET UNTIL statement, as shown in the preceding example. However, note that if you use SET UNTIL TIME to specify the target time for point-in-time recovery, some times that you can specify may not be in the current incarnation. The database may have been in an ancestor incarnation, or even in a sibling incarnation, at the target time. If your target time is not in the current incarnation, then see "Point-in-Time Recovery to an Ancestor Incarnation" for more information on DBPITR to ancestor incarnations, and Oracle Database Backup and Recovery Advanced User's Guide for more information on DBPITR to incarnations that are not ancestors of the current incarnation.
7.6.5 Options After Database Point-in-Time Recovery
After a successful DBPITR, your choices are:
Export one or more objects from your database using an Oracle export utility such as Data Pump Export. You can then recover the database to the current point in time and re-import the exported objects, as a way to return these objects to their state prior to the unwanted change without abandoning all other changes.
Open your database for read-write, abandoning all changes after the target SCN. In such a case, you must open the database with the RESETLOGS option, as shown here:
RMAN> ALTER DATABASE OPEN RESETLOGS;
The current online redo logs are archived, the log sequence number is reset to 1, and the online redo logs are given a new time stamp and SCN. Identifying redo log files with a new log sequence number and incarnation eliminates the possibility of corrupting datafiles by the application of obsolete archived redo logs.
The OPEN RESETLOGS operation will fail if a datafile is off-line, unless the datafile went offline normally or is read-only. You can bring files in read-only or offline normal tablespaces online after the RESETLOGS because they do not need any redo.
Sybrand Bakker
Senior Oracle DBA