Oh yeah! How could I forget: make darn
sure that you are working with Oracle Support actively, step-by-step, if you are
in a scenario which might call for the use of these parameters. It would
be *disastrous* to start down this road if unnecessary, and there are other
quirks when using them that only OWS can diagnose and overcome...
...need my coffee, NOW!
----- Original Message -----
Sent: Thursday, September 19, 2002 7:03 AM
Subject: Re: Lost ofall redo logs
One correction...
The undocumented "_corrupted_rollback_segments"
parameter does not take a TRUE/FALSE value setting. It is another
list of rollback segment names (similar to "rollback_segments" and
"_offline_rollback_segments") which will be considered corrupted.
Roughly, the meaning of these undocumented
parameters is (and I'm doing this from memory and pre-morning-coffee so
those who know please correct as needed):
List of rollback segment names on which to
perform ALTER ROLLBACK SEGMENT ... ONLINE immediately after opening the
database instance.
- _offline_rollback_segments
List of rollback segments names to not scan
during OPEN in order to mark transactions as "DEAD" (uncommitted) or "ROLLED
BACK" (during instance recovery). Also, these RBS will not be used for
any new transactions and cannot be brought online. Since these RBS do
not have any DEAD transactions after OPEN, then SMON will not attempt
rollback any txns behind the scenes. If, while the instance is
open, an entry in an ITL in a database block refers to one of these RBS,
then the server process will attempt to read the transaction table in the
RBS header and also attempt to read undo blocks in the RBS body in order to
rollback the transaction or achieve a consistent read. Please
note that this is *dangerous* and that the instance can become "hung"
through infinite loops and other nasty stuff while this is being
performed. In this event, the instance may have to be killed and the
RBS involved may have to be listed in the "_corrupted_rollback_segment"
parameter if there is any hope of using the database
again...
- _corrupted_rollback_segments
Another list of rollback segments to not scan
during OPEN and not allow online after OPEN. Transaction table is not
scanned (as with "_offline_") during instance recovery and transactions
within are not rolled back or marked DEAD, ever. If, after the
instance is open, an entry in an ITL in a database block refers to one of
these RBS, then the server process will *not* attempt to reference the RBS
in order to rollback the transaction or achieve a consistent read.
Instead, the changes from the transaction will be marked as "committed" as
is.
I'm sure that you can all see the danger in
using these parameters. Transactions that should be rolled back will not
be.
With "_offline", the database will attempt
to use info within the RBS but will never allow the RBS to be brought online for
new transactions. You use "_offline" if you think you can get away with
salvaging the data in the RBS.
With "_corrupted", there is no hope, which
is usually the situation if the header block of the RBS is corrupted. In
this case, the "after-image" data stored in the data segments (i.e. table,
cluster, and index) are considered as "committed", since there is no way to tell
if they really were or weren't. The fact that the "after-images" may have
been incomplete only adds to the fun and excitement...
As Arun had indicated (but not fully
enough!), a database opened with either of these parameters really cannot be
"trusted" for future use. The firm recommendation is to use the database
instance thus opened merely to salvage as much data as possible for import (one
way or another) into a freshly-created new database. Using these parameters will put the database on life-support
for a short time only, hopefully long enough to extract its data. It would
be foolish to entrust new data to it ever again...
Hope this helps...
-Tim
----- Original Message -----
Sent: Thursday, September 19, 2002 12:58
AM
Subject: RE: Lost ofall redo logs
> Arun:
>
> You are right. The original poster *clearly*
said
>
> LOST ALL REDO LOGS
> NO BACKUP.
>
> In
the above situation, you have to open the
> databases using the some
special tricks and
> I don't think you need to go back and refer
>
BAckup and Recovery Manuals (You can not
> find anything for this
situation, that is
> another story)
>
> Those parameters will
bring up the database
> if the database is cleanly shudowned
(read:
> Shutdown Normal/Immediate) and you will
> have to do some
more tricks to get the
> database up if it is crashed (read:
shutdown
> ABORT).
>
> I don't think it is a bad
advice..
>
> YMMV
>
> KG
>
>
>
-----Original Message-----
> Chakrapanirao
> Sent: Wednesday,
September 18, 2002 11:08 PM
> To: Multiple recipients of list
ORACLE-L
>
>
> Well one I do want to make clear I have never
tried to give bad advice to
> people.
> Since the user in his mail
had said that he does not have a backup and does
> not have any online
redo logs can you please let me know how else can he
> open the database,
when he said he does not have a back it assumes that he
> does not have a
os backup and also the rman backup.
> This might be the undocumented thing
but this Is the only way it works
> And this had happened in one our case
and the only way we could open the
> database is to force open the
database in a corrupt mode take an export and
> import back into the new
database.
>
> If you still think I am trying to give a bad advice
well sorry that I am
> giving bad advices.
>
>
>
-----Original Message-----
> Sent: Thursday, September 19, 2002 12:33
AM
> To: Multiple recipients of list ORACLE-L
>
> Arun, since
WHEN has been using undocumented parameters the normal way
> of doing
things, I think you need to go back and lookup backup/recovery
>
concepts.
>
> Feel free to read both user managed and RMAN backup
recovery docs/scenarios.
>
> You are giving bad advice to people on
the list who might be new.
>
> joe
>
>
> Arun
Chakrapanirao wrote:
>
> >The only way u can open your database
is to add a parameter file
> >as
> >
>
>_allow_resetlogs_corruption=TRUE
> >
>
>_corrupted_rollback_segments= TRUE
> >
>
>_offline_rollback_segments=(the rollback segment names)
> >
>
>activate the database and then immediately take an export of the
whole
> >database.
> >Create a new database and then import
all the data to this new database.
> >
> >
>
>-----Original Message-----
> >Sent: Wednesday, September 18, 2002
5:23 PM
> >To: Multiple recipients of list ORACLE-L
>
>
> >Nop, all redo logs gone away...
> >
> >-----
Original Message -----
> >To: "Multiple recipients of list ORACLE-L"
<ORACLE-L@fatcity.com>
>
>Sent: Wednesday, September 18, 2002 5:43 PM
> >
>
>
> >
> >
> >>What about mirrored redo group
members?
> >>
> >>Igor Neyman, OCP DBA
>
>>ineyman@perceptron.com
> >>
> >>
>
>>
> >>----- Original Message -----
> >>To:
"Multiple recipients of list ORACLE-L" <ORACLE-L@fatcity.com>
>
>>Sent: Wednesday, September 18, 2002 4:30 PM
> >>
>
>>
> >>Hi people...
> >>
> >>What to
do if I have LOST ALL REDO LOGS and i don4t have any backup?
>
>>
> >>Thanks in advance!
> >>
>
>>:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
>>Gilberto
Gampert
Universidade de Passo Fundo
> >>Administrador de Banco de
Dados Passo Fundo - RS - Bra5il
>
>>gampert@upf.br
http://www.upf.br>
>>:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
>>
> >>
> >>--
> >>Please see the
official ORACLE-L FAQ: http://www.orafaq.com>
>>--
> >>Author: Gilberto Gampert
> >> INET:
gampert@upf.br>
>>
> >>Fat City Network Services --
858-538-5051 http://www.fatcity.com>
>>San Diego, California --
Mailing list and web hosting services
>
>>---------------------------------------------------------------------
>
>>To REMOVE yourself from this mailing list, send an E-Mail
message
> >>to: ListGuru@fatcity.com (note
EXACT spelling of 'ListGuru') and in
> >>the message BODY, include a
line containing: UNSUB ORACLE-L
> >>(or the name of mailing list you
want to be removed from). You may
> >>also send the HELP
command for other information (like subscribing).
> >>
>
>>--
> >>Please see the official ORACLE-L FAQ: http://www.orafaq.com>
>>--
> >>Author: Igor Neyman
> >> INET:
ineyman@perceptron.com>
>>
> >>Fat City Network Services --
858-538-5051 http://www.fatcity.com>
>>San Diego, California --
Mailing list and web hosting services
>
>>---------------------------------------------------------------------
>
>>To REMOVE yourself from this mailing list, send an E-Mail
message
> >>to: ListGuru@fatcity.com (note
EXACT spelling of 'ListGuru') and in
> >>the message BODY, include a
line containing: UNSUB ORACLE-L
> >>(or the name of mailing list you
want to be removed from). You may
> >>also send the HELP
command for other information (like subscribing).
> >>
>
>>
> >>
> >
> >
> >
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com>
--
> Author: Joe Testa
> INET: jtesta@dmc-it.com>
> Fat
City Network Services -- 858-538-5051 http://www.fatcity.com> San
Diego, California -- Mailing list and
web hosting services
>
---------------------------------------------------------------------
> To
REMOVE yourself from this mailing list, send an E-Mail message
> to:
ListGuru@fatcity.com (note EXACT
spelling of 'ListGuru') and in
> the message BODY, include a line
containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be
removed from). You may
> also send the HELP command for other
information (like subscribing).
> --
> Please see the official
ORACLE-L FAQ: http://www.orafaq.com>
--
> Author: Arun Chakrapanirao
> INET: ArunC@1800FLOWERS.com>
>
Fat City Network Services -- 858-538-5051 http://www.fatcity.com> San
Diego, California -- Mailing list and
web hosting services
>
---------------------------------------------------------------------
> To
REMOVE yourself from this mailing list, send an E-Mail message
> to:
ListGuru@fatcity.com (note EXACT
spelling of 'ListGuru') and in
> the message BODY, include a line
containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be
removed from). You may
> also send the HELP command for other
information (like subscribing).
>
> --
> Please see the
official ORACLE-L FAQ: http://www.orafaq.com> --
> Author: K Gopalakrishnan
> INET: kaygopal@yahoo.com>
>
Fat City Network Services -- 858-538-5051 http://www.fatcity.com> San
Diego, California -- Mailing list and
web hosting services
>
---------------------------------------------------------------------
> To
REMOVE yourself from this mailing list, send an E-Mail message
> to:
ListGuru@fatcity.com (note EXACT
spelling of 'ListGuru') and in
> the message BODY, include a line
containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be
removed from). You may
> also send the HELP command for other
information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: Tim_at_SageLogix.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Thu Sep 19 2002 - 09:08:33 CDT
