Re: Tracking down NOLOGGING objects

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.

HTH,
-- 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
> <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.
>
>

--
http://www.freelists.org/webpage/oracle-l