For example, suppose ten samples were taken over a 10-second period. During two of the samples, an Oracle process was consuming CPU and the other eight were waiting for IO. Based solely on these samples, we can infer 20% of the time the process is consuming CPU, while 80% of the time it is waiting for IO. Since we know the duration is ten seconds, we can also infer the process was consuming CPU for about 2 seconds and waiting for IO about 8 seconds. While we do not know the exact figures and we could increase the accuracy by increasing the sample rate, we know enough to understand the situation, resulting in a stellar diagnosis.

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.