| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> 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
The "miniumum" SCN? You mean that some files are further on than #152?? (You're quite right: some of them will be, because they're the ones that have no trouble).
And therein lies your problem...
> so you start an incomplete recovery until scn #153
> all the datafiles will be with scn #153
Why don't you try it for yourself? Here's a brief attempt of mine:
C:\Documents and Settings\Howard>sqlplus scott/tiger
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
SQL> update emp set sal=sal*1.04;
14 rows updated.
SQL> commit;
Commit complete.
SQL> connect / as sysdba
Connected.
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 30480768 bytes
Fixed Size 452992 bytes Variable Size 25165824 bytes Database Buffers 4194304 bytes Redo Buffers 667648 bytesDatabase mounted.
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
----------- --------------------------- 1 231187 2 231187 3 231187 4 231187 5 231187
SQL> recover database until change 231187;
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'F:\DATABASES\ORACLE\ORA92\BRIT\SYSTEM01.DBF'
Point being, what the headers of the file say the SCN is, is not a reliable guide to the SCN of the actual contents of those files. Oracle spots that and throws up the usual error whenever some part of the database is left at a time later than another part of the database has gotten to.
You can't do what you propose to do.
HJR
> Open the database with resetlogs
>
> do i missing something (except the scn in control files that i havent
> taken in account for semplicity?)
>
> 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.
>
>
Received on Fri Sep 20 2002 - 08:03:18 CDT
 |
 |