During each sample period, every session (both server process and background process) that is consuming CPU or waiting on a non-idle wait event will be recorded, resulting in an additional v$active_session_history row. Even if the session is still in the same wait as the previous sample-for example, a very long table lock-there will be an additional ASH row inserted.13

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.