Re: HotBackup Dilema

"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
>
>
>
> -----------== Posted via Newsfeed.Com - Uncensored Usenet News
==----------
> http://www.newsfeed.com The #1 Newsgroup Service in the World!
> -----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers
=----- Received on Tue Dec 17 2002 - 14:43:43 CST