SAP Tools vs. SQLTrace and TKPROF

Question

Experts,
First let me say that I am NOT an oracle expert, I am a basis person.  Such is the reason I come seeking wisdom.
We are undergoing somewhat of a knee-jerk performance analysis, based on some user complaints.  Our new-to-the-organization dba (who has no experience in SAP) is wanting to set up a small performance tablespace within our Production ECC DB and use sql trace and tkprof to analyze what ever it is that they are wanting to look at.
In the past we have been slightly more methodical about tracking down the problem, and then analyzing it based on traces and information within the ST* and DB* tools of SAP.
my 2 questions are:
-  Is there any concern with setting up perf gathering tablespace within the production DB
- Does SQLTrace and TKProf give information not readily available within SAPs performance and administration txn's? (DBACockpit, ST* tools, Etc.)
(edit: environment is Solaris 10 64-bit/Oracle 10.2.0.2 64-bit  e2900 64/GB Mem)
Thank you in advance,
Phillip
Edited by: Phil May on Oct 9, 2009 1:47 PM

Answer 1

Hi Stefan,
> At first i think, that the analyze possibilities inside SAP for performance issues are one of the best i have ever seen.
True and sad at the same time.
There would be so much more necessary to really have an end-to-end performance view of data processing processes in heterogeneous and distributed systems like SAP landscapes are.
>So in my opinion you can mostly identify and track down the performance issues within SAP itself (ST05, ST04, STAD, etc.).
> > Does SQLTrace and TKProf give information not readily available within SAPs performance and administration txn's?
> Of course .. the raw SQL trace is much more detailed (wait events, etc.), but to be honest .. mostly you don't need it in a SAP environment.
Hmm... I think this (being able to solve most problems with the currently available tool set) only partly comes from the completeness of the tool set.
At least for a part of it, I think it's something like 'When-all-you-have-got-i-a-hammer-everything-look-like-a-nail"-effect.
Usually the "Wait Event Evangelists" (like Cary Milsap) will tell you that the extended SQL trace is all you'll ever need to track down all of your performance issues.
Then there is a whole group of people that try to catch everything by staring at execution plans and theorizing about what execution step would be the problem cause (e.g. the bad hash join or the bad bad bad full table scan).
The DB-agnostic counterpart will say that the NetWeaver platform already covers everything necessary and that look out for additional indexes or ABAP parameters.
I think the truth lies (as usual) somewhere in between.
All in all I think the key point is to get an angle to the problems at all.
As soon as one can describe the problems in a structured way, (s)he has at least a chance to figure out what is happening when
the systems becomes slow.
Given that I'd also vote for the most convenient approach - and that is to use the GUI tools provided by NetWeaver.
And the more experienced Oracle tuning-super-heroes can always take a step further and emply the sql_id-data-collection script or one of the endless number of special scripts that are available through report RSORASTT nowadays.
Just my 2 pence...
regards,
Lars
Edited by: Lars Breddemann on Oct 10, 2009 10:31 AM