Re: code to load tracefile into CLOB?
Date: Tue, 16 Aug 2011 21:43:05 -0500
Message-Id: <098B8C32-0350-41F6-BA69-A869FD4C9213_at_enkitec.com>
I've created external tables on trace files before so I could query some of the data. Works fine for a single file as long as you're a DBA with access to the right directories, but when you start trying to figure out how to deal with multiple files being created on the fly and giving developers access, it becomes a more complicated problem. And by the way, not providing developers with the tools they really need is, in my opinion, one of the biggest problems we have in the Oracle community. MR Trace provides a pretty straight forward way to obtain that information without having to find a DBA and communicate to him which trace file you're looking for. Off my soapbox and back into my hole now.
Kerry Osborne
Enkitec
blog: kerryosborne.oracle-guy.com
On Aug 16, 2011, at 9:26 PM, John Piwowar wrote:
> If the developers are usually generating these trace files themselves from a client session, and not dumping them from within an application, you might want to look at Method R's MR Trace tool, which bolts on to SQL Developer and generates trace files locally.
>
> http://method-r.com/software/mrtrace
>
>
> Regards,
>
> John P.
>
> On Tue, Aug 16, 2011 at 6:56 PM, Jeremy Schneider <jeremy.schneider_at_ardentperf.com> wrote:
> Hm... I could definitely see some perks to using an external table. It would be a lot easier to export this to a file on their own machine... simpler all-around...
>
> Only additional wrinkle is that this is not just one tracefile, but lots and lots of tracefiles. Anytime they enable 10046 on a session, I want them to get their tracefile. A block of code that dynamically creates a bunch of external tables would do it, one for each trace file... but we have a lot of files and I'd rather not create so many objects. Maybe if there was just one external table, and I had a block of code that just redefined that external table to point to whichever trace file they need... the many developers here would just have to coordinate. Or perhaps I could make it like DBMS_STATS where they can point it to any table, create one in their own schema that they just re-use, like the PLAN_TABLE.
>
> But to my original question, I guess nobody already has this block of code already written? Suppose I'll have to actually go and write it? Oh well. :)
>
> -Jeremy
>
>
> On 8/16/2011 6:08 PM, Tim Gorman wrote:
>> >> Jeremy, >> >> Given all the complexities involving LOBs in general, why not load the tracefile line-by-line into a table with each line is a row, thus using a VARCHAR2 column for the text of the line? Easier to load, easier to manage, easier to index, easier to retrieve? >> >> Just my $0.02? >> >> -Tim >> >> -----Original Message----- >> From: Jeremy Schneider [mailto:jeremy.schneider_at_ardentperf.com] >> Sent: Tuesday, August 16, 2011 04:39 PM >> To: Oracle-L_at_freelists.org >> Subject: code to load tracefile into CLOB? >> >> Just wondering... does anyone out there have a snippit of code that will load a 10046 trace file from bdump or udump into a LOB? Just looking for a quick and dirty way to give some developers access to tracefiles (without requiring unix logins). Didn't see any code samples with a quick google search, so I'm about to code it myself - just thought I'd ask first. -Jeremy -- http://www.ardentperf.com +1 312-725-9249 Jeremy Schneider Chicago -- http://www.freelists.org/webpage/oracle-l
>
>
> --
> http://www.ardentperf.com
> +1 312-725-9249
>
> Jeremy Schneider
> Chicago
>
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Aug 16 2011 - 21:43:05 CDT