I am often asked why ASH is such a big deal. There are four reasons why ASH truly is a very big deal: back-in-time capabilities, configurable low-impact kernel-level data collection, clean data, and the connection of session activity with resource consumption (think service time) and wait time.

Suppose you received a call from a user who said performance was poor about 30 minutes ago, but now performance is just fine. With ASH, you can easily go back in time, and with a very simple query, perform a session-, instance-, or system-level ORTA. Usually, when someone calls with a performance problem, we get on the system and start running scripts. But even if our scripts are interval-based, they are probably based on the present going forward. This means if the problem is gone, so is our capability to diagnose that problem. Since ASH collects data and buffers it, that data is there for us to use in our "what just happened?" diagnosis. Even better, the ASH data is written into the automatic workload repository tables, creating the capability to generate advanced reports based on just about any time frame.

As discussed earlier in this chapter, modern Oracle architectures make linking a user's activity to an Oracle server process challenging. ASH helps in this endeavor because it stores not only the session identifier and serial number, but also the client identifier, the Oracle username, program, module, and action!