In my experience the time savings from nologging is minimal, small enough to even be hard to measure. And of course, by the time you resolve this sort of issue, most likely you don't save any time at all (or even go into a deficit), so I wouldn't bother with the nologging. On Tue, Dec 7, 2010 at 10:03 AM, Hemant K Chitale <hemantkchitale@xxxxxxxxx>wrote: > Just because "NOLOGGING got you into this mess" is no reason to NOT use > NOLOGGING. > > If those Indexes are large are you going to spend all that I/O and time to > generate Redo ? > > The proper thing to do is REBUILD .. NOLOGGING and then take a backup -- > ie ensure that the backup taken after the REBUILD completes is used. > > Hemant > > On Tue, Dec 7, 2010 at 11:20 PM, <lyallbarbour@xxxxxxxxxxxxxxx> wrote: > >> Isn't NOLOGGING how i got into this mess in the first place? And i >> think Grid did use PARALLEL for some, i'll have to check that. >> Lyall >> >> >> -----Original Message----- >> From: Hemant K Chitale <hemantkchitale@xxxxxxxxx> >> To: lyallbarbour@xxxxxxxxxxxxxxx >> Cc: oracle-l@xxxxxxxxxxxxx >> Sent: Mon, Dec 6, 2010 7:29 pm >> Subject: Re: NOLOGGING recovery errors >> >> An ALTER INDEX ..... REBUILD attempts to re-read the existing index >> *unless it is UNUSABLE*. >> So, for indexes that are not enforcing PK constraints, do an ALTER INDEX >> ..... UNUSABLE before the REBUILD. >> For indexes that are for PK constraints, disable the constraints before >> setting them UNUSABLE. >> Needless to say, I suggest NOLOGGING for the REBUILD. If you also use >> PARALLEL then set them to NOPARALLEL after the REBUILD. >> Enable the constraints after the REBUILD. >> Hemant K Chitale >> http://hemantoracledba.blogspot.com >> sent from my smartphone >> >> >> -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'