The server is a single Intel CPU/core Dell box with 512MB of memory, running Oracle Database 11g Release 1, with a 256MB of shared pool memory, a buffer cache of 4MB (yes, I know it's small, but it forces a lot of IO), and running on Oracle's unbreakable Linux 5. Each of the two main tests (IMU enabled and IMU disabled) was run nine times. The worst time was removed from each series, resulting in eight samples. Before each of the two tests, the instance was recycled, and the DML load was started and left to stabilize for about 5 minutes. Then a heavy read-consistent query was run four times. CPU and wall clock time statistics were collected before and after each query; that is, the wall clock time is the difference between the time at the end of the last query subtracted from the time before the first query.

For this particular experiment, there was a statistically significant 21% CPU time reduction when using IMU. However, there was a statistically insignificant 6.5% wall clock time reduction when using IMU. This means, for this particular experiment, there is not quite enough wall clock time difference to indicate using IMU made an improvement.

Unfortunately, based on this experiment, the significant IMU CPU savings was offset by an insignificant average wall clock time reduction. The experiment was not designed to detect why the wall clock time was not significantly better when using IMU. But I'll speculate: There was a raging DML and physical read-induced IO bottleneck with plenty of excess CPU capacity. So while IMU reduced the CPU consumption, the wall clock time was primarily based on IO. In other words, I reduced Oracle's CPU consumption when where was plenty of available CPU-the classic performance blunder of tuning the wrong thing! However, if the bottleneck were CPU, I should have seen a very significant reduction in both CPU and wall clock time.