Re: database recovery HELP

Thanks a lot for all who input their best thought here.

No one doubt that we all can do 1st recovery to some point. The most difficult one lies on the 2nd recovery then.

It seems we have two options on 2nd recovery:

1. if all archivelogs exist, recover it again using 'timing 'option (the last log timing);
2. have a cold backup files including control files, log files in place, then do a complete recovery.

I am puzzling at the first option: if we can do that (can we?), what command could we use? According to Howard, we cannot do so, simply because the resetlog makes log sequence to 0. My question is can we still use 'old' archivelog file to do recover again?

Again, all comment are welcome, and hopefully you would never face this kind of problem.

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3b0adbeb_at_news.iprimus.com.au...
> If I'm reading you right, the short story is that you've done an
 incomplete
> recovery, followed by an open resetlogs, and you now want to know if you
 can
> repeat that recovery. Is that right?
>
> 'Cos if it is, then the answer is 'no'. Your database is now in a
 different
> incarnation from what it was when you performed the first recovery. To
> perform the second recovery, you will again want to restore all datafiles
> and apply redo. Unfortunately, those datafiles and archives are from an
> incarnation *prior* to the current one, and you'll get an error to that
> effect the second you try it.
>
> However, no one in their right mind performs an incomplete recovery
 without
> first copying the control files and the online redo logs out to somewhere
> safe (what I'll call your 'emergency backup'), and you did all of that,
> right? A slap on the wrist if not, and a re-iteration of the "no" answer
 to
> boot. But if you *did* take your emergency backup, then you're in
 business.
> You replace the current controlfile and redo logs with the emergency
 backup
> versions, and your datafiles from your proper backup, and your database is
> now exactly as it was at the moment you performed the original recovery.
>
> But without the backups of the controlfile and online redo logs taken just
> before your first recovery, you won't be able to do that.
>
> There is a workaround for the seriously brave: it's called 'recovery
 through
> resetlogs', and you'll want to read up on it carefully before embarking on
> it. You can only even attempt it if ALL the following conditions are
 true:
>
> 1. This is Version 7.3.3 or later
> 2. There is no 'emergency backup' just prior to the original resetlogs
> 3. There is still the 'proper backup' before the resetlogs
> 4. That 'proper backup' includes a binary version of the Control File
> 5. All archives since the time of the 'proper backup' exist, right up
 until
> the present moment
> 6. You've kept a copy of the Alert Log containing the moment of issuing
 the
> original resetlogs.
>
> If all of that applies to you, then the basic procedure is (hold on to
 your
> hats):
>
> 1. Take a complete closed backup of the database somewhere safe (I'll
 call
> this the Third Backup!)
> 2. Restore all datafiles and the binary controlfile from your 'Proper
> Backup' (NOT the online redo logs)
> 3. Mount the database
> 4. In the alert log, find the SCN at which the original resetlogs was
> issued (it will say something like 'Incomplete recovery done until change
> 578393')
> 5. Recover the database until that change number ('recover database until
> change 578393 using backup controlfile')
> 6. DO NOT OPEN THE DATABASE at this point
> 7. Instead, shut it down using the normal option
> 8. Retrieve the binary version of your controlfile from the Third Backup
> taken at step 1 above, and replace the existing controlfiles with it
> 9. Mount the database
> 10.Recover the database using whatever is the command you fancy (ie
 'recover
> database' or 'recover database until....')
> 11. Open the database using the appropriate command (ie, resetlogs or not)
> 12. Check everything is OK.
> 13. Take a new backup of the entire closed database if everything is OK.
>
> I don't recommend it, I've only demo'd it half a dozen times, and it's
 gone
> spectacularly wrong on 1 of those occasions. And I'm not even sure if
 it's
> appropriate to your situation.
>
> Regards
> HJR
> --
> =============================!!=============================
> The views expressed are my own only, and definitely NOT those of Oracle
> Corporation
> =============================!!=============================
>
>
> "Steve" <schen_at_prodigy.net> wrote in message
> news:9ee2l0$4ids$1_at_newssvr05-en0.news.prodigy.com...
> > Need urgent assistance on database recovery (Oracle 7.3):
> >
> > Thousands of rows were deleted accidentally last Friday. I have online
> > archivelog in place. I can "recover database until
 '2001-05-18:12:30:00',
> > then alter database open resetlog. Then I export that recovered table
 for
> > later insertion.
> >
> > I want to recover database again back to the moment that I started the
> > recovery for I need to have database back to the point that I started
> > recovery, so that Monday, Tuesday data still there. I then just import
> > back the table rows.
> >
> > I am not sure that resetlog command on the first recovery would post
 some
> > problem on 2nd recovery, for the log sequence would be change after
 "alter
> > database open resetlog". Right? Can I recover like these? Or do
 I
> > have to put all database files back to that point to do 2nd recovery.
> >
> > I have not implement all recovery procedure yet.
> >
> > Need your timely assistance.
> >
> > Very appreciated.
> >
> > Steve
> >
> >
>
>
Received on Tue May 22 2001 - 18:46:33 CDT