Truss does a different job, with pstack I took the sampling approach. I sample 10-100 times and then profile which stacks I see the most, to see where most time is spent.

With truss or DTrace approach also some post-processing would need to be done if you want to know what plan operation takes most time. I have done this in DTrace..

Haris,

Please download the script again, or just change the MAX_ARRAY=4095 to MAX_ARRAY=1023 in it, I suspect your shell can’t handle larger arrays (also on RHEL 4 and before there seems to be such problem)

Excellent script.

But the script does not work for HP-UX 11i v2

The errors
$ pstack 10020 | ./os_explain
./os_explain[138]: ==: unknown test operator
f_lifo[10]: array: subscript out of range

Is there a plan to deply in HP-UX?

Regards
Haris

Thanks for taking time to reply.

Here is a what I tried with truss instead of Dtrace. Just save the pain of reversing the pstack output. Let me know your thoughts

Also DTrace could have system wide impact where as truss would just impact the process , correct me here if I am wrong.

Run truss on
SQL> alter system flush shared_pool;

System altered.

SQL> select a from t2;

A
———-
1
2
3
4
5
6
7
8
9
10

10 rows selected.

SQL> exit

This is the output I get from truss
cat 1truss.out | grep ‘oracle|qer’ |cut -d2-20 (output edited)

^I -> oracle:qerstStart(0×407b48a20, 0×1, 0×0, 0×0)$
^I -> oracle:qerstInitialize(0×0, 0×0, 0×0, 0×1)$
^I oracle:qertbStart(0×40e484da8, 0×1, 0×16, 0×30)$
^I -> oracle:qerstStart(0×40e484f20, 0×1, 0×12, 0×6)$
^I -> oracle:qerstInitialize(0×0, 0×0, 0×0, 0×1)$
^I oracle:qerixStart(0×413faafd0, 0×1, 0×16, 0×30)$
^I -> oracle:qerixGetKey(0×413faafd0, 0×40e484f90, 0×6, 0xffffffffffffffff)$
^I oracle:qerixGetKey(0×413faafd0, 0×413faab30, 0×6, 0×1)$
^I <- oracle:qerixGetKey() = 1$
^I <- oracle:qerixStart() = 0×413faafd0$
^I <- oracle:qertbStart() = 0×40e484f20$
^I oracle:qertbRelease(0×40e484da8, 0×0, 0×0, 0×0)$
^I -> oracle:qerixRelease(0×413faafd0, 0×0, 0×0, 0×0)$
^I <- oracle:qerixRelease() = 0$
^I oracle:qerstFetch(0×407b48a20, 0×1025145c0, 0xffffffff7ffe7520, 0×1)$
^I -> oracle:qertbFetchByRowID(0×40e484da8, 0×1009af1e0, 0xffffffff7ffe6e20, 0×1)$
^I -> oracle:qerstFetch(0×40e484f20, 0×0, 0xffffffff7ffe6d54, 0×1)$
^I -> oracle:qerixtFetch(0×413faafd0, 0×0, 0xffffffff7ffe65ec, 0×1)$
^I -> oracle:qerixGetRowid(0×4dd394de0, 0×12, 0xffffffff7c056758, 0×4dd394dde)$
^I <- oracle:qerixGetRowid() = 46$
^I <- oracle:qerixtFetch() = 0$
^I oracle:qertbGetPartitionNumber(0xffffffff7ffe6d14, 0×40e484ea0, 0xffffffff7c057190,
0xffffffff7c05bde0)$

I need to run sed to get these converted to oracle calls.

Sorry If I am taking up too much space, I can share the whole script if you think this does the job.

Thanks

Ravi

In this script (extracting stack traces) truss can’t be used at all, as far as I know truss can’t extract snapshots of stack traces like pstack does.

But if comparing truss’es a.out:func* notation with DTrace, I would always use DTrace if its available and usable. DTrace is safe by design (although you *can* cause trouble with it even in non-destructive mode) but truss had problems in past IIRC, such target processes missing signals sent to them and failing to exit.

In this particular script is there an advantage in using DTRACE over using truss
to trace @ OS Level ?

I am curious – I see from your examples and from my own tests that pstack is only capturing current stack operations. You mention that you have a loop to cycle through while the query is running. This begs a couple questions:
1) A loop is going to, effectively, sample the process stack. Correct?
2) What would it take to stitch together stack traces for os_explain? Not sure if just deleting the “header” lines would do it.

Thanks again for your intelligent and comprehensive contributions.

I knew Linux distros had PDKSH instead of KSH, but didn’t know that RHEL5 one has the “real” KSH. It may be related with Sun open sourcing Solaris and related software?