RE: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <cmarquez@xxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 19 Aug 2005 12:13:14 -0700
You probably already know this, but just in case you don't - it might be
helpful:
You can do the following to see if any of your datafiles currently contain
unrecoverable changes:
SELECT unrecoverable_time, unrecoverable_change#, name FROM v$datafile;
Regards,
Brandon
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Marquez, Chris
Sent: Friday, August 19, 2005 11:55 AM
To: Riyaj Shamsudeen; joelgarry@xxxxxxxxxxxxxxx
Cc: Thomas.Mercadante@xxxxxxxxxxxxxxxxx; Joel Garry; oracle-l@xxxxxxxxxxxxx
Subject: RE: ORA-1578...block corrupted...error is normal...a block...had a
NOLOGGING...operation performed against
Someone just replied to me directly and suggested that maybe the index is
defined as;
select OWNER, INDEX_NAME, LOGGING from dba_indexes where LOGGING='NO'
This seems logical except that I have done this many time before...creating
indexes nologging and never (maybe incorrectly) changed the to logging after
they completed building.
Maybe I need to take back about what I said about being comfortable with
NOLOGGING option (I researched)?
*HOWEVER*, I regularly apply redo logs from and active PROD to a database with
many indexes defined as LOGGING='NO' to a database I restored and recovered
from an RMAN backup. I never have errors on the recovered database???
Chris Marquez
Oracle DBA
-----Original Message-----
From: Riyaj Shamsudeen [ mailto:rshamsud@xxxxxxxxxxxx]
Sent: Fri 8/19/2005 2:52 PM
To: joelgarry@xxxxxxxxxxxxxxx
Cc: Marquez, Chris; Thomas.Mercadante@xxxxxxxxxxxxxxxxx; Joel Garry;
oracle-l@xxxxxxxxxxxxx
Subject: Re: ORA-1578...block corrupted...error is normal...a block...had a
NOLOGGING...operation performed against
NOLOGGING simply marks the range of blocks modified in that nologging
operation invalid, by writing redo records with pertinent details.
Replaying redo records from this timeframe, will mark the data blocks as
invalid. But, If you take a backup after the nologging operation then
you should be able to rollforward from that backup, as long as there are
no other nologging operations after the backup.
There must have been another nologging operation after the backup
performed on this table/index. Are you sure that the table is not
inserted with append hint ? What does created column in dba_objects show
for this table/index ?
Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA (ver 7.0 - 9i)
Allocation & Assortment planning systems
JCPenney
Joel Garry wrote:
>>Not really, I still believe it. I know I have restored databases in
>>
>>
>the past
>
>
>>that had very old NOLOGGING operations performance
>>against them and *now* included in a recent backup...not arch logs...
>>in the backup, part of the database.
>>
>>
>
>So that means that the roll forward checking pertains to blocks in the
>data file rather than the logs? A guess, I don't know, doesn't sound
>right. It might make a difference if the blocks had or had not been
>updated in the meantime.
>
>Joel Garry
> http://www.garry.to
>
>--
> //www.freelists.org/webpage/oracle-l
>
>
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions and
other information in this message that do not relate to the official business
of this company shall be understood as neither given nor endorsed by it.
Other related posts:
