Quote Originally Posted by ridges54 View Post
I do something like this:

rman target / catalog rman/password@rman

run
{
restore DATABASE UNTIL TIME "to_date('2010-05-19:23:59:00','YYYY-MM-DD:HH24:MI:SS')";
RECOVER DATABASE UNTIL TIME "to_date('2010-05-20:19:00:00','YYYY-MM-DD:HH24:MI:SS')";
alter database open resetlogs;
}

This way, as long as I have the archivelogs and access to the backup files, I can recover to any point in time. This is done with an rman catalog so info like where the backupsets are located is housed there.

Make a small test instance and test backing up and recovering. Whenever I try something new, I always try it on my personal database first, then a test instance I made that is a dupicate of the database I'm going to be running the new thing on in prod. I take note of the time it takes for a successful run, any errors I get, what I did to resolve them, and how much disk space I am chewing up by running the new thing.

I never want to hear from management "Didn't you know that was going to happen?"

Jim
Jim,

If you insist on using point in time recovery you may want to do this, since
its one less step and also hides your password from people doing a ps -ef


cat point_in_time_recovery.rman
=========================

rman <
connect target sys/sys@rman
connect catalog rman/rman@rman

run
{
set until time "to_date('16-03-2009 17:52:07', 'dd-mm-yyyy hh24:mi:ss')";
restore database;
recover database;
SQL 'alter database open resetlogs';
}

EOF

Note: If your doing a regular restore DB and recover DB you don't need to
resetlogs, thats only needed for point int time.