Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against

RE: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against

From: Marquez, Chris <cmarquez_at_collegeboard.org>
Date: Fri, 19 Aug 2005 16:30:38 -0400
Message-ID: <B30C2483766F9342B6AEF108833CC84E05BD5F32@ecogenemld50.Org.Collegeboard.local>


Thanks Riyaj and Jared.

That explains it.

A little RTFM goes a long way.

 :o|

Chris Marquez
Oracle DBA

-----Original Message-----
From: Jared Still [mailto:jkstill_at_gmail.com] Sent: Fri 8/19/2005 4:24 PM
To: Marquez, Chris
Cc: oracle-l_at_freelists.org
Subject: Re: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against  

The manual might help here.

>From the 'CREATE INDEX' entry:

 Specify whether the creation of the index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file.

The creation of the index will not be logged. Subsequent inserts will be logged.

It isn't too hard to test this out.

Create a table nologging.
Create an index nologging.

Check your session redo size.

select
name.name name,
stat.value
from v$mystat stat, v$statname name
where
stat.statistic# = name.statistic#
and name.name = 'redo size';

Use 'insert /*+ append */' to create a lot of rows in the table.

Check your redo size again.

It will be clear that there is redo generated for the index. You can verify the amount of redo generated is not from the table by doing the same exercise wihout the index. The redo will be minimal.

You can also verify this by the following procedure:

create the table and index (no logging)

check redo size

do the mass insert

backup the tablespace

insert a new row

restore the datafile

see if the new row is in index and table

HTH Jared

-----Original Message-----
From: Riyaj Shamsudeen [mailto:rshamsud_at_jcpenney.com] Sent: Fri 8/19/2005 4:23 PM
To: Marquez, Chris
Subject: Re: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against  

NOLOGGING affects recovery only if that operation generates block range invalidation redo records.

Following will generate those invalidation redo records:

  1. CTAS with nologging.
  2. Direct load mode with unrecoverable set to y, in sqlload.
  3. insert with append hint. Of course, table/indices must have nologging attribute set and force logging must be off at the database level.

Normal DML such as the following will NOT generate these redo records

  1. Update/delete
  2. Insert without append hint.
  3. sqlload conventional path.

Functionally, turning on nologging at create time or later does not make any difference.

Thanks  

Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA (ver 7.0 - 9i)
Allocation & Assortment planning systems JCPenney

On 8/19/05, Marquez, Chris <cmarquez_at_collegeboard.org> wrote:
>
> All,
>
> After talking to a co-DBA we believe we *did* have [create] nologging
> operations within the redo logs applied to the recovered database.
>
> Also, I just tested out our database in constant recovery mode (poor man's
> standby).
> We have 33 indexes created *and* defined with nologging, *before* the
> database was restored and recovered (applying logs) to our standby server.
> It seems that we can select from indexes that were "CREATED" with NOLOGGING
> and *still* are "DEFINED as LOGGING='NO". When we select using the index on
> the database (in read only mode) we find the index and data are fine...no
> errors.
> We have applied two weeks worth of arch log (transactions) against these
> indexes "DEFINED as LOGGING='NO".
>
> So now that statement or questions is that;
> "CREATED" with NOLOGGING, must be entirely different than "DEFINED
> [ALTER?] as LOGGING='NO" (dba_indexes).
> Or rather NOLOGGING only has negative recovery impact on CREATED DDL?
>
> Chris Marquez
> Oracle DBA
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org on behalf of Jared Still
> Sent: Fri 8/19/2005 3:31 PM
> To: joelgarry_at_anabolicinc.com
> Cc: oracle-l_at_freelists.org
> Subject: Re: ORA-1578...block corrupted...error is normal...a block...had
> a NOLOGGING...operation performed against
>
> On 8/19/05, Joel Garry <joelgarry_at_anabolicinc.com> wrote:
> >
> >
> > Believe it. Time bomb sat there since long ago. Nologging operations
> > bypass the redo logs. So they bypass the archived logs. So when you
> > restore the datafile by rolling forward, you invalidate those blocks.
>
>
> Roll forward from when?
>
> If you restore from a backup prior to the nologging operation, and roll
> forward, the index created with 'nologging' will not be restored.
>
> If you restore a backup taken after the creation of the nologging
> operation,
> the nologging object will be restored.
>
>
> So you have to fix them with some other mechanism than recovery. Maybe
> > use force logging if you don't want to run into this again. And all
> > that advice about taking a backup after nologging operations seems
> > pretty misleading, huh?
>
>
> Either you need to test it further, or I don't understand your premise.
>
> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>
>
>
>
>

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist


--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 19 2005 - 15:34:52 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US