blogs.conus.info

Regarding question on Oracle X$KSMLRU fixed table.

The x$ksmlru table keeps track of the current shared pool objects and the corresponding number of objects flushed out of the shared pool to allocate space for the load. These objects are stored and flushed out based on the Least Recently Used (LRU) algorithm.
....
Note: This is a fixed table: once you query the table, the database will automatically reset the table. Make sure that you spool the output to a file so you can capture it for analysis.

I cannot yet answer why this table reset after each SELECT, but at least, I know at which point.
Information in this table is constructed using function ksmlrs() (at least for 10.2), which also calls ksmsplu(). The last function allocate memory chunks for the table, marking them as "x$ksmsp lrstat" and "x$ksmsp lru", then copy the table, then calls memset() C function to zero it.
If to bypass this last call to memset(), by debugger for example, it is possible to have such Oracle instance which will not reset this table after each SELECT. However, if you want to do this, I hope you'll backup your database first.

On different OS, Oracle V$TIMER system value shows different values.
On Microsoft Windows (we tested Oracle 8.0.5, 8.1.5, 9.0.1.1.1, 9.2.0.1, 10.1.0.2, 10.2.0.1, 10.2.0.1 x64, 11.1.0.6.0 and 11.1.0.6.0 x64) this value is exactly what system call GetTickCount() returning divided by 10.
On GNU/Linux (we tested 10.1.0.3, 10.2.0.1, 11.1.0.6.0 and 11.1.0.6.0 x64) this is exactly what times() system call returning.
On Solaris 10 (we tested 10.2.0.1 x64) this is value returned by gethrtime() divided by 10000000.

So, while we reading official Oracle manual of 11g Release 1 (11.1):

V$TIMER displays the elapsed time in hundredths of a second. Time is measured since the beginning of the epoch, which is operating system specific, and wraps around to 0 again whenever the value overflows four bytes (roughly 497 days).

... they probably not covering all OS-es.