Re: Tracking down NOLOGGING objects

From: Andrey.Kriushin <>
Date: Tue, 02 Sep 2008 03:58:55 +0400
Message-ID: <>

Hi Finn,

Mark's comment on feasubility is complete. Nothing to add.

However for pure theoretical investigation... At least we know now, that Oracle RDBMS doesn't keep a track of NOLOGGING operations at the segment level. Does it?

I'd look at the definition of GV$SEGMENT_STATISTICS and x$ksolsfts. This x$-table keeps the runtime statistics (FTS_STATNAM), and if you see 'physical writes direct' there, it might be (or not - in case of PQO) an indication of direct load, probably with the NOLOGGING.

BTW, it would be nice to see the version of the product (RDBMS) in your future posts.

-- Andrey

Finn Jorgensen wrote:
> Mark,
> I appreciate your input and you are right force logging will fix the
> issue and yes standby databases prompted this effort in the first place.
> The reason for my looking for the objects is that I wrote a monitor to
> check for datafiles that had recent nologging activity and then list
> the objects that were not logged. This particular database, as can be
> seen, reports no objects yet there's nologging activity. I want to be
> able to go back to the app/dev guys and ask them if it's on purpose
> these objects are set to nologging. It's possible I break
> (considerably slow down) some load process if I just indiscriminently
> turn on force logging.
> Looks like I'll have to test the sql*loader with unrecoverable/direct
> turned on.
> Finn
> On Sun, Aug 31, 2008 at 9:57 AM, Mark Brinsmead
> < <>> wrote:
> Why bother to track down objects with NOLOGGING?
> ...
> Check out FORCE_LOGGING. It ought to meet your needs.

Received on Mon Sep 01 2008 - 18:58:55 CDT

Original text of this message