Re: Block Corruption, cant start DB -SOS

"Candido Dessanti" <termy_at_blunet.it> wrote in message news:3D8B0FE0.1040603_at_blunet.it...
>
> > There's no such thing as an incomplete crash recovery. Instance
recoveries
> > are, by definition, complete. If you want an incomplete recovery, you
are
> > required to restore all datafiles from a backup and roll them all
forward to
> > a point of your choosing. Since you've restored all datafiles, we're
talking
> > media recovery, not crash recovery.
> >
> > Without restoring all datafiles, your idea of rolling partway forward
> > through the online logs would result in an inconsistent database, since
some
> > datafiles would be at different SCNs from others.
>
>
> Could you tell me the difference between restore datafile and do not
> restore any datfile and perform an incomplete recovery? I cant see any,
> all datafiles header in both cases will have the smae SCN and they will
> be consistent.
>
> scenario 1
> Restore all datafiles with scn #100
> start instance, mount the database
> Recover the database thru ArchiveRedo. The scn for all datafiles is #150
> The recover continue with online redologs until scn specified #153
> Open the database with resetlogs
>
> scenario 2
> You got an instance crash
> open and mount the database.
> you query v$datafile to get the minumum #scn across all database files
> and discover it is #152
> so you start an incomplete recovery until scn #153
> all the datafiles will be with scn #153
> Open the database with resetlogs
>
> do i missing something (except the scn in control files that i havent
> taken in account for semplicity?)

Hi Candido,

The point you are missing is that you have no control over the synchronisation of the data files at the time of instance failure. There could well be a datafile that has a timestamp after the point of recovery required to avoid the associated block corruption. In theory it could work but it would be a matter of hit or miss. There can be *no* data file change numbers greater than the change number used in the recovery clause. Not something I would like to bet my life on. However, this would be *guaranteed* to work if all data files are restored from backup, an important distinction.

>
> You forgot even TableSpace Point-in-time recovery where you can perform
> an incomplete recovery of just a tablespace not the database, even it is
> a mess.

BONG !! (this isn't copyrighted is it Howard ?)

You *must* perform a incomplete *database* recovery in order to perform a tablespace point in time recovery. There is no such thing as an isolated tablespace point in time recovery.

To perform a TSPITR, you must restore *all* the datafiles (and all things being equal the backup control file as well). In mount, you *must* RECOVER DATABASE UNTIL blab blah. You then must open the database with resetlogs. IE, You have just performed a database incomplete recovery.

Now you can export the database or tablespace or transportable tablespace (depending on database version) and re-import the tablespace or transportable tablespace back to your original database.

That's a TSPIT recovery !!

And note the restore of all data files (which naturally requires a backup) is a crucial and unavoidable step.

Cheers

Richard
>
>
Received on Fri Sep 20 2002 - 08:31:25 CDT