I'm so glad to have both options to choose from and I really think both of them
have their strengths.
With regard to the granularity of diagnostic information, SQL trace is indeed
beyond compare to any other software I've ever seen. What I mean by that is it
leaves the information about every single database and system call (i.e. wait
event) performed within a traced session.
On the other hand, ASH is great for correlating events like latch and mutex
waits across the database, especially if used in combination with Tanel Poder's
Snapper. Besides that, there is no trace left for unexpected issues, so ASH
might be the only source of information available in such case.
Nenad
http://nenadnoveljic.com/blog/
Von: Mladen Gogala <gogala.mladen@xxxxxxxxx<mailto:gogala.mladen@xxxxxxxxx>>
Datum Dienstag, 06. März 2018, 11:23 PM
An: oracle-l@xxxxxxxxxxxxx
<oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Betreff: Re: DBA Job Functions
Paperwork for trace? What kind of paperwork? Top secret SQL_Trace
clearance? License to trace, only for DBA personnel with double zero
codes? I'd like my Mountain Dew shaken, not stirred. I don't know about
you, but I usually did my tracing on development and UAT systems, and no
paperwork was required. When you have a problem with application
performance, you profile it and trace it, to see where the time is
spent. That's simply the method applicable across the IT industry. Plus,
you don't need license for diagnostic and tuning packs, which is
required for ASH.
On 03/06/2018 02:33 AM, Dominic Brooks wrote:
Which is a good job because turning tracing on for a production
session and then getting hold of trace files takes too long and takes
too much paperwork for many organisations, even if you are a DBA which
I am not so it’s even more difficult.
