Re: Help getting past missing archivelog file

In <3f7443b0$0$18889$afc38c87_at_news.optusnet.com.au> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> writes:

>Stan Brown wrote:
 

>> In <3f743a3f$0$32058$afc38c87_at_news.optusnet.com.au> "Howard J. Rogers"
>> <howardjr2000_at_yahoo.com.au> writes:
>>
>>>Alistair Thomson wrote:
 

>>>> Hi Stan
>>>>
>>>> You can restore until cancel or until a point in time, check out the
>>>> syntax below:
>>>>
>>>> SVRMGRL> connect internal
>>>>
>>>> SVRMGRL> startup mount db_name;
>>>>
>>>> SVRMGRL> recover database until time '2003-09-23:14:40:00';
>>>>
>>>> While still in svrmgrl, execute the normal command to open the database,
>>>> using the RESETLOGS option. This forces the database to reset the redo
>>>> log sequence number information in the control files and the online redo
>>>> log files This in turn makes sure that any redo log entry data that
>>>> followed the "RECOVER DATABASE UNTIL" time will not be applied to the
>>>> database:
>>>>
>>>> SVRMGRL> alter database open resetlogs;
>>>>
>>>> Now backup your database.
>>>>
>>>>
>>>>
>>>> Hope it helps
>>>>
>>>>
>>>>
>>>> Alistair
>>
>>
>>>I have to say that's a dreadful piece of advice! Sorry, but it is so. The
>>>guy already has stated that the datafile in question (which is all that is
>>>being recovered here) only contains indexes, and that those indexes can be
>>>re-created. Your suggestion to do a database-wide incomplete recovery
>>>means that you will be causing data loss on the entire database, totally
>>>unnecessarily.
 

>>>The correct response to this sort of situation is to alter database
>>>datafile X offline drop. That will permit him to open the rest of his
>>>database, drop the tablespace, re-create it, and then re-create all the
>>>indexes. And no data will have been lost in the meantime.
 

>>>The only slight bummer to this approach is that it is easier said than
>>>done to get rid of the index tablespace, because some of those indexes
>>>might be being used to enforce constraints... and all those constraints
>>>will therefore have to be disabled before the tablespace drop can be
>>>accomplished... and then re-enabled at the end of it. But that's merely
>>>just a lot of hard manual work... it's still better than losing data he
>>>didn't need to lose in the first place!
>>
>>
>> Actually (speaking as the OP) In my case the incomplete recovery would
>> probably be better. Here is is the rest of the story.
>>
>> I've moved on further to determine that there _are_ additional datafile
>> that want non existent archivelogs. These datafiles, unfortunately contain
>> tables.
>>
>> Now I need to explain the nature of the database. It's archival data from
>> a process control system. There are virtually no dependencies between
>> various datasets, thus almost no constraints. At this point in time I'm
>> losing more (real time) data because the database is still down, that
>> there is any likleyhood of losing from a 24 (or even 48) hour old
>> recovery.
>>
>> The best thing for me, is to get it back up as soon as possible.
>>
>> Given all the above, I've been unable to get a partial recovery to work.
>> The latest ever was a cancel based recovery that would up, after I did
>> alter database open resetlogs, with an error message about file +3 being
>> to new!
>>
>> I guess I'm going to restore all the (necessary ?) files from the previous
>> days tape backup. Given the size of the database, this will take _a long_
>> time!
>>
>> Does anyone have a better suggestion?

>Can I suggest that you stop posting about the same subject in different
>threads? Stick to one thread per problem.

Sorry, I'll stick to this thread for the rest of the saga.

Thanks for the hepl!

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
						-- Benjamin Franklin