Thanks Howard! You just said in a few words what it took the author of
my backup and recovery book to say in a dozen or more pages. And you
said it clearly and concisely too! I'm going to print your reply and
place it in the appropriate section of the book.
Howard J. Rogers wrote:
> "Startup" on its own means 'startup open', so the command is attempting to
> completely open the database.
>
> It would appear, however, that a previous incomplete recovery has been
> performed, and this is still awaiting the 'alter database open resetlogs'
> command to terminate it.
>
> Incomplete recoveries are performed either (a) after a user stuff-up (such
> as 'Ooops. I just deleted the entire sales table and hit the commit button
> instead of the rollback one') or (b) when there's a gap in your stream of
> redo which prevents a complete recovery succeeding.
>
> In the case of (a), you beat the unfortunate employee around the head a bit,
> until he confesses that he did the catastrophic delete at, say, 8.45am. You
> then restore all datafiles from your last complete backup, startup mount,
> and issue the command 'recover database until time '2002-17-12:08:44:00'.
> That rolls the datafiles forward to time 8:44am. But that still leaves the
> Control File at time 8:45, ahead of the datafiles. You therefore force
> synchronisation by issuing the command 'alter database open resetlogs',
> effectively setting the database back to time zero.
>
> In the case of (b), you issue the command 'recover database until cancel',
> meaning: 'when I type in the word cancel, I want you to permanently stop
> applying redo to my datafiles'. So you restore from last night, roll them
> forward by applying redo from archives (say) 105, 106, 107, 108 and 109. But
> because archive 110 is missing, you can't go further, so you say 'cancel'.
> Now your datafiles are at time 109, but again your controlfile is ahead of
> the game at time 115. Time to force synchronisation to time zero with an
> 'alter database open resetlogs'.
>
> So someone (presumably you?) has previously done one or other of these
> scenarios, the datafiles are consistent amongst themselves at one time, but
> the controlfile is out of synch at a time in the future of that... so a
> resetlogs is needed.
>
> Bear in mind that a resetlogs resets the database to time zero. Prior
> backups at time (say) 100 are thus useless for recovering that database. All
> prior archives are likewise equally useless. Your freshly opened database is
> thus completely vulnerable to another failure of some kind, and would be
> unrecoverable unless you *immediately* start to take a new backup.
>
> Regards
> HJR
>
>
> "Chucky" <chuck.carson_at_syrrx.com> wrote in message
> news:3DFF8A4F.2000302_at_syrrx.com...
>
>>I am trying to restore from a hotbackup and am getting this problem:
>>
>>SVRMGR> connect internal;
>>Connected.
>>SVRMGR> startup
>>ORACLE instance started.
>>Total System Global Area 1979523232 bytes
>>Fixed Size 73888 bytes
>>Variable Size 368558080 bytes
>>Database Buffers 1610612736 bytes
>>Redo Buffers 278528 bytes
>>Database mounted.
>>ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
>>
>>
>>This is new to me, can anyone shed some light?
>>
>>Thx,
>>CC
>>
>>
>>
Received on Tue Dec 17 2002 - 15:00:35 CST
