Re: Tracking down NOLOGGING objects
Date: Tue, 02 Sep 2008 03:58:55 +0400
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.
Finn Jorgensen wrote:
> 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.
> On Sun, Aug 31, 2008 at 9:57 AM, Mark Brinsmead
> <pythianbrinsmead_at_gmail.com <mailto:pythianbrinsmead_at_gmail.com>> wrote:
> Why bother to track down objects with NOLOGGING?
> Check out FORCE_LOGGING. It ought to meet your needs.