Re: Cheap Cheap Database Recovery
From: pitufo <vandresv_at_gmail.com>
Date: Tue, 24 Feb 2009 19:31:49 -0800 (PST)
Message-ID: <1bbfcdb4-ca8c-41c4-8350-f005b3a559e0_at_z9g2000yqi.googlegroups.com>
On Feb 24, 9:42 pm, johnbhur..._at_sbcglobal.net wrote:
> 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
Date: Tue, 24 Feb 2009 19:31:49 -0800 (PST)
Message-ID: <1bbfcdb4-ca8c-41c4-8350-f005b3a559e0_at_z9g2000yqi.googlegroups.com>
On Feb 24, 9:42 pm, johnbhur..._at_sbcglobal.net wrote:
> 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
John, I took exactly those steps, It did not apply any archivelogs...I'll try it again tomorrow. If you send me an email I could send you a flash movie with the whole procedure. (vandresv at gmail dot com) Received on Tue Feb 24 2009 - 21:31:49 CST