While it is common to hear about the ASH buffers being flushed, it is not a true flush, because the data is not cleared or erased. It remains, so we are more likely to find ASH data in memory. Oracle's AWR facility manages how much and the granularity of AWR data to keep before the rows are physically deleted from the AWR tables.

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.