ASH can be used in other ways also. Because it contains the client identifier as well as the session identifier and serial number, we can create an entire group of similar reports. Just as we drilled down from our initial instance-level response-time analysis in Figure 5-21 into both CPU consumption and wait time, we could have also drilled down to the session or to the sessions tagged with a specific client identifier. In fact, we could have easily performed an ORTA based on a specific client identifier. The possibilities are endless and powerful. I hope you have gained an appreciation for how ASH can be used during performance firefighting.

ASH can be viewed as simply a data collector, but it's Oracle's adjustable kernel-level-embedded data collector. And as demonstrated in the previous section, it can produce an amazing array of extremely useful and pinpoint accuracy response-time-based diagnostic reports. How ASH collects its data is the focus of this section.

ASH is based on a sampling methodology, whereas both Oracle's wait interface and instance statistic views (e.g., v$sysstat) gather their data based on instrumentation. Sampling is not an unusual way to gather information. It is used in many disciplines. Nearly all Oracle third-party performance products gather their performance data by polling, which is sampling. Sampling is used outside the Oracle community also; for example, with statistics, signal processing, music, compression, financial auditing, and quality control.