8.1.7, linux

Situation: ran a relatively complex query using 6 bitmapped columns, on
a partitioned table, and with autotrace on. That's fine.
Prior to running, set "alter session set events '10046 trace name
context forever, level 8'", then ran tkprof on the 22MB tracefile. 2
seconds after starting tkprof, up pops a message saying 'segmentation
fault', and quits.

I googled up a couple of notes about a bug (way in back in 7+) that said
to try "grep -v APPNAME tracefile.trc > newfile.trc" but that had no
success.

Anyone have any suggestions on how to work around this, or encountered
this before?

Cheers,

Bricklen

"Bricklen" <fake (AT) email (DOT) com> wrote



Could be this bug:

Bug 1354942 Fixed: 8172
a.. Dumps / Abends
TKPROF may dump if "STAT" lines are over 79 characters long.
Workaround:
Edit the raw .trc file so that no STAT line is over 79 characters.

Try applying 8172 or later patch.

Cheers,
Dave

Bricklen wrote:
I've occasionally had tkprof's go bust on very large trace files. Maybe
play with 'split'

hth
connor
--
=========================
Connor McDonald
http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue"

Thanks Dave and Connor,

I grep'd | wc -l the STAT lines and counted 701, although if you go by
STAT #, there were never more than about 40 per #.
Split is an interesting idea, and not one I even considered for this
problem (having no idea what the problem _was_ !).

As it turns out, today the exact same query's trace file (flushed
shared_pool, same values etc) goes through tkprof without a hitch. No
parameters or settings were changed, and no os options were changed that
I am aware of. Strange....

Anyways, thanks for the tips!

Cheers,

Bricklen