Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: drilling into RPC EXEC calls to db link

Re:drilling into RPC EXEC calls to db link 2 years 5 months ago #332

You know, i had just tried that before you replied. Thanks!
The administrator has disabled public write access.

Re:drilling into RPC EXEC calls to db link 2 years 5 months ago #333

Alright, now i'm stuck more.
Does this just not make sense to group by $sqlid?

oradbp01: mrskew semsp01_ora_10777_NKATZ_MOA.trc --name='RPC EXEC' --group='$sqlid' --where1=1
'$sqlid' DURATION % CALLS MEAN MIN MAX
#0 49.067544 100.0% 62 0.791412 0.000000 48.063693
TOTAL (1) 49.067544 100.0% 62 0.791412 0.000000 48.063693

here's the original, that i'm trying to drill into:
oradbp01: mrskew semsp01_ora_10777_NKATZ_MOA.trc
CALL-NAME DURATION % CALLS MEAN MIN MAX
RPC EXEC 49.067544 66.7% 62 0.791412 0.000000 48.063693
SQL*Net message from client 22.543986 30.7% 99 0.227717 0.000112 22.482086

What's the #0 mean?
The administrator has disabled public write access.

Re:drilling into RPC EXEC calls to db link 2 years 5 months ago #334

Lyall,

It *should* make sense to group by $sqlid, but for remote procedure calls, mrskew v2.1 doesn't group properly by $sqlid. Hence the workaround advice from before. This is scheduled to be fixed in v2.2.

The "#0" is a cursor id that has no SQL associated with it. Normally, it is a cursor id associated with commit processing. It is showing up in your output because of the mrskew v2.1 bug that doesn't map the SQL statement on the RPC CALL line to the call on the RPC EXEC line. I think if you run this command, you'll understand the nature of the bug:

mrskew --name=all --group='sprintf("%5d %13.13s %s", $line, $sqlid, $text)' --top=0 --sort=1na yourfile.trc

This will allow you to track the value of the $sqlid variable through your whole trace file.

I'm sorry this deficiency is in your way right now...


--Cary
The administrator has disabled public write access.
  • Page:
  • 1
  • 2