Re: Tracking down NOLOGGING objects
- From: "Andrey.Kriushin" <Andrey.Kriushin@xxxxxxxx>
- To: finn.oracledba@xxxxxxxxx
- Date: Tue, 02 Sep 2008 03:58:55 +0400
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@xxxxxxxxx <mailto:pythianbrinsmead@xxxxxxxxx>> wrote:
>
> Why bother to track down objects with NOLOGGING?
>
> ...
> Check out FORCE_LOGGING. It ought to meet your needs.
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
