When the v$active_session_history view is queried, you can think of it as starting at a specific period in the past and then progressing forward in time (moving clockwise). While most ASH queries pull data from a specific number of minutes in the past and move forward until the most recent ASH record, because ASH records are indexed and stored by time, the report start and stop time can be anything you wish, as long as the data is stored in the ASH ring structure.

I am commonly asked just how much of an impact ASH places on the system. The answer is highly variable, based on CPU speed, the number of active sessions, the sampling frequency, and most important, the cost of CPU power.15 But I have run some tests to get an idea. On a very lightly loaded testing system, over a 3-minute period, the MMON and MMNL background processes together issued around 3,500 gettimeofday calls, and each call took between 0.03 ms and 0.08 ms. This means that in the worst case (0.08ms), over an hour, 5.6 seconds of CPU time were occupied by just these two background processes. That is an amazingly lightweight data collector. I have seen commercial-grade data collectors consume over a minute of CPU time every hour.

Interestingly, my tests show Oracle's wait interface places significantly more load on the database server than ASH. For example, simply operating system tracing an active server process indicated that 2,938 gettimeofday calls were issued over a 3-minute period, and each call took 0.017 ms. Another 3-minute sample of an active server process made 89,555 gettimeofday calls, with each taking around 0.077 ms. As you can see, the impact is highly variable. My first example would consume 999 ms (2938 _ 20 _ 0.017) of CPU per hour, and the second example would consume 138 seconds (89555 _ 20 _ 0.077) of CPU per hour. Therefore, wait interface overhead is highly variable. Since every system call is instrumented, many short waits would create more overhead than fewer longer waits. Keep in mind that this is just for a single server process, not the total for ten, hundreds, or even thousands of server processes. So if you're concerned about ASH overhead, you should be very concerned about the wait interface overhead.