Re: database recovery HELP

I would like to thank all who help. Also I would to update you what it is:

1st recovery failed to get all rows deleted back, with count of that table only up as of today.

I was using timing option, with a couple of attempts to get earlier hours still not working.

2nd recovery I simply put all database files back to places. Now I am back to square one.

Steve
"Michael Austin" <miaustin_at_bellsouth.net> wrote in message news:3B0B0017.99809413_at_bellsouth.net...
> The one thing I see that he is trying to avoid is applying the one
 transaction
> that erased the 1K records, plus keep all of the transactions that were
 applied
> since then.
>
> 1) extract all records since the records were erased from all tables
> 2)do the steps to recover until the point in time
> 3) use SQL*Loader to load the "extracted" records
>
> or restore a CURRENT COLD backup to another system (current_backup) as has
 been
> suggested
> restore/recover until... the previous backup
> insert into restored_tables from current_backup where ...
>
> Now you are back where you should be.
> Been there, done that.... did NOT like it.... shot programmer.... (or at
 least
> thought about it....)
>
> Michael Austin
> DBA Consultant
>
> "Howard J. Rogers" wrote:
>
> > 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 Wed May 23 2001 - 12:52:03 CDT