The trick with sampling is to gather just enough samples to be meet the requirements while not disrupting the system of interest. And this is the central challenge all data collection facilities face. Because Oracle's ASH collection facility is built directly into its kernel, it has the distinct advantage of lower overhead. While ASH gathers session-level details from active sessions and stores the information in an ASH buffer located in the shared pool, the sampling frequency is adjustable via the _ash_sampling_frequency instance parameter.

From a v$active_session_history perspective, a new row is inserted for every active session during each sampling period. So if you decreased the sampling frequency from once per second to once every 2 seconds, you would notice a 50% drop in the number of ASH rows. Assuming the size of the ASH buffer is fixed, decreasing the sample rate would also allow reporting further back in time.

ASH buffers are stored in the shared pool. Oracle wants to keep around 30 minutes of history, but the more active sessions, combined with the shared pool size and the sample frequency, will obviously influence how far back in time ASH activity is available. ASH space could be as little as 1MB or as much as 30MB.14 To see the current memory dedicated to ASH, execute the following: