Re: Help! Redo logs destroyed

From: Robert Franklin <franklin_at_infomagic.com>
Date: 1998/07/18
Message-ID: <6onkab$kfg_at_boris.infomagic.com>#1/1


Another sugestion is to make additional log members on other pack to avoid this in the future. You can have Redo log Groups. Using the Group approach, you can place redo logs on other disk drives in your system protecting against disk crashes.

Good Luck,
Bob

Matthew Arrocha wrote in message <01bdaf1d$94da78a0$5d20d6d1_at_marrocha>...
>Do not drop or allow resetlogs corruption.
>Even though the files are not there you can recover this very easily.
>
>The control file contains the path and file size of each group and log
>member.
>From svrmgrl connect internal
>mount the database
>recover until cancel;
>cancel
>alter database open resetlogs;
>
>The database will open and Oracle will regenerate new logs in the old path
>based on the values in the control file.
>
>You can from the mounted state issue:
> alter database backup controlfile to trace to verify the control files
>information.
>This way theres no harm and no rebuild.
>
>If you use any _allow parameters with corruption the you have to do a full
>export and rebuild afterwards.
>Work smarter not harder.
>
>Matt-
>
>Edward Lowery <telowery_at_hotmail.com> wrote in article
><Q3Aq1.228$G42.488769_at_news4.atl.bellsouth.net>...
>> This happened to me and I had to export my data then delete my current
>> database and create a new one. It's a pain but it worked.
>>
>>
>> Ivan Boesing wrote in message
>> <01bda5f0$1f8e5e80$0cce040a_at_ivan.tre-rs.gov.br>...
>> >Hi Dan,
>> >
>> > You can try put the parameter "_allow_resetlogs_corruption = true"
 in
>> >your init.ora file.
>> > Caution is advised when using it as you might end-up with lost
 or
>> >inconsistent data!!!
>> >
>> > Please contact me if it works.
>> >
>> >--------------------------------------------------------------------
>> >Ivan Boesing
>> >Oracle DBA
>> >boesing_at_nospam.geocities.com
>> >Please remove the "nospam." to contact me.
>> >--------------------------------------------------------------------
>> >
>> >Dan Lipofsky <danlip_at_cyc.com> escreveu no artigo
>> ><3591724D.9F35A3B_at_cyc.com>...
>> >> We are running Oracle 7.1.3 on a DEC Alpha with OSF1 v3.0,
>> >> and are in a very bad situation.
>> >>
>> >> We lost a disk which contained our redo logs. None
>> >> of the data file were damanged, only the .rdo files.
>> >> HOWEVER, oracle refuses to start up without these files.
>> >>
>> >> Any ideas would be appreciated. The basic problem is that
>> >> until it can open those files and get the info, it wont
>> >> let me drop them, reset them, or anything else.
>> >>
>> >> Here is a bit from the startup.log file:
>> >>
>> >> SQLDBA> Connected.
>> >> SQLDBA> ORACLE instance started.
>> >> Database mounted.
>> >> ORA-00313: open failed for members of log group 1 of thread 1
>> >> ORA-00312: online log 1 thread 1: '/u03/ORACLE/TST8A/usoft8_01b.rdo'
>> >> ORA-07360: sfifi: stat error, unable to obtain information about file.
>> >> DEC OSF/1 (AXP) Error: 2: No such file or directory
>> >> Attempting to dismount database........Database dismounted.
>> >> Attempting to shutdown instance........ORACLE instance shut down.
>> >>
>> >> Here are a few of the commands I have tried which didnt help any:
>> >>
>> >> alter database drop logfile group 1;
>> >> alter database drop logfile member '/u03/ORACLE/TST8A/usoft8_01b.rdo';
>> >> alter database open resetlogs;
>> >> alter system checkpoint;
>> >> (Oracle 7.3 has "alter database clear unarchived logfile", but that
>> >> doesnt work under Oracle 7.1.3. Too bad, its probably what I want).
>> >>
>> >> We have old backups with redo logs on them, but it doesnt
>> >> help because the sequence numbers do not match.
>> >>
>> >> Several DBAs I talked to were unable to help.
>> >> There must be a way out of this!!
>> >>
>> >> - Dan
>> >>
>> >>
>> >>
>>
>>
>>
Received on Sat Jul 18 1998 - 00:00:00 CEST

Original text of this message