Re: Cheap Cheap Database Recovery
From: <johnbhurley_at_sbcglobal.net>
Date: Tue, 24 Feb 2009 17:42:01 -0800 (PST)
Message-ID: <585abd10-cce5-4fd2-8a8a-10127d529196_at_m40g2000yqh.googlegroups.com>
On Feb 24, 8:09 pm, pitufo <vandr..._at_gmail.com> wrote:
> Hi John,
> I I do have a valid backup, at 2:30 am. There is no way I can apply
> future archive logs using a controlfile who does not know anything of
> the future. You need a controlfile which has information of what
> archived logs have been created. As I told you before, I tried your
> approach and try to move forward using the controlfile from the cold
> backup. It did not work. Unless there is some other commands that I
> don't know, of course.
> This is what I did for trying your theroy:
>
> --untar full backup in second server
> --startup mount
> --select * from v$recover_log
> 0 rows returned.............................here it is, the
> controlfile sees that its SCN matches the SCN of the datafile
> headers...nothing to recover
>
> I don't remember if I try the recover command, but if I did Ican't
> recall the exact response from the database.
>
> But if you do the same thing with newer control files, you'll get as
> many rows (from the select statement above) as archive logs have been
> created since the last backup.....minus the ones that are still in the
> online redo logs of the production database where the backup
> controlfile statement was issued.
>
> What is the the recover statement you would apply to advance into the
> future with a controlfile that is in sync with the datafiles (as in
> the cold backup case) ?
>
> BTW, Now I know how to consistently recover my database to lets say1
> minute ago, using this method....all I need to do is 'alter system
> switch logfile' n times, where n is the number of groups of my redo
> log files. That way I am purging all online redo logs, and then 'alter
> database backup controlfile to 'binary.file' to get the recent
> controlfile will do the rest of the trick. Once that I do the above I
> can restore the database in the second server without practically
> losing data.
>
> Best regards,
> Andres
Date: Tue, 24 Feb 2009 17:42:01 -0800 (PST)
Message-ID: <585abd10-cce5-4fd2-8a8a-10127d529196_at_m40g2000yqh.googlegroups.com>
On Feb 24, 8:09 pm, pitufo <vandr..._at_gmail.com> wrote:
> Hi John,
> I I do have a valid backup, at 2:30 am. There is no way I can apply
> future archive logs using a controlfile who does not know anything of
> the future. You need a controlfile which has information of what
> archived logs have been created. As I told you before, I tried your
> approach and try to move forward using the controlfile from the cold
> backup. It did not work. Unless there is some other commands that I
> don't know, of course.
> This is what I did for trying your theroy:
>
> --untar full backup in second server
> --startup mount
> --select * from v$recover_log
> 0 rows returned.............................here it is, the
> controlfile sees that its SCN matches the SCN of the datafile
> headers...nothing to recover
>
> I don't remember if I try the recover command, but if I did Ican't
> recall the exact response from the database.
>
> But if you do the same thing with newer control files, you'll get as
> many rows (from the select statement above) as archive logs have been
> created since the last backup.....minus the ones that are still in the
> online redo logs of the production database where the backup
> controlfile statement was issued.
>
> What is the the recover statement you would apply to advance into the
> future with a controlfile that is in sync with the datafiles (as in
> the cold backup case) ?
>
> BTW, Now I know how to consistently recover my database to lets say1
> minute ago, using this method....all I need to do is 'alter system
> switch logfile' n times, where n is the number of groups of my redo
> log files. That way I am purging all online redo logs, and then 'alter
> database backup controlfile to 'binary.file' to get the recent
> controlfile will do the rest of the trick. Once that I do the above I
> can restore the database in the second server without practically
> losing data.
>
> Best regards,
> Andres
Found this below from google search:
You can check MetaLink Note#271916.1
Basically:
Restore all datafiles, controlfiles and archivelogs to expected
locations.
startup mount
recover database using backup controlfile until cancel;
Apply your available archivelogs until no more and then CANCEL
alter database open resetlogs;
shutdown immediate;
startup
Received on Tue Feb 24 2009 - 19:42:01 CST