This is 11.2.0.2 database, with the April PSU applied, on Linux 32bit.
These are the numbers I see in SYS.AUX_STATS$:

SQL> select pname,pval1 from sys.aux_stats$
2 where pname like '%READTIM';

PNAME PVAL1
------------------------------ ----------
SREADTIM 90819.71
MREADTIM 72565.924


I thought that these were durations of an average single/multi block
reads, expressed in milliseconds. This doesn't work, even in
microseconds. Also, SREADTIM is larger than MREADTIM, which I find rather
strange. Has anybody noticed that? Did the units change? Should I start
playing with DBMS_STATS.SET_SYSTEM_STATS? Ask Tom is busy as usual,
impossible to ask question there.

--
http://mgogala.byethost5.com

On Wed, 07 Sep 2011 21:16:39 +0000, Mladen Gogala wrote:

I should have searched Metalink, before asking the question:
Bug 9842771 - Wrong SREADTIM and MREADTIM statistics in AUX_STATS$ [ID
9842771.8]

Both versions of 11.2.0 are affected. It's going to be fixed in 11.2.0.3
and the workaround is to set it manually. This will do wonders for the
folks who upgrades database and expects the queries to work normally.



--
http://mgogala.byethost5.com

On Sep 7, 5:43*pm, Mladen Gogala <gogala.mla... (AT) gmail (DOT) com> wrote:
There are apparently two related bugs, the comment by Sokrates at the
following link states that there is a patch for 9842771, but I do not
recall locating that patch:
http://hoopercharles.wordpress.com/2...ct-statistics/

Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration
from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

On Wed, 07 Sep 2011 15:33:02 -0700, Charles Hooper wrote:

The company that I used to work for started converting to Oracle 11.2 a
month ago, I didn't bother to check until I started seeing some radically
altered plans. So far, I encountered 3 major issues:

- This one with SREADTIM/MREADTIM/MBRC
- Problem with baselines, where background processes suddenly start
inserting into SYS objects containing profile data.
- Problem with import (dp), indexes are not created in parallel, not
even if specified.

Unfortunately, the company has filed for chapter 7 protection, so no more
problems are to be expected with this database.If anyone needs an
experienced DBA in NYC.....


--
http://mgogala.byethost5.com

On Wed, 07 Sep 2011 15:33:02 -0700, Charles Hooper wrote:

Great note! I wish I saw it earlier, I would have known immediately. It
does need an update, though. In Oracle11, you should collect stats for
SYSMAN, not SYSADM.



--
http://mgogala.byethost5.com

On Sep 7, 7:32*pm, Mladen Gogala <gogala.mla... (AT) gmail (DOT) com> wrote:
Thanks for the feedback regarding the article. The slides and slide
notes are from a presentation that I gave to Oracle DBAs for a
specific ERP package - that ERP package places the ERP data into the
SYSADM schema. I should have better clarified that point when I made
the blog post.

---

I first noticed the system statistics bug roughly a year ago. I was
testing Oracle Database 11.2.0.1 on a crazy expensive laptop with two
256GB SSD drives in RAID 0 - when I gathered the system statistics and
saw the roughly 2.5 second single block read time and roughly 9 second
multi-block read time, I thought of 3 possible causes:
* The laptop is so fast that the numbers wrapped around zero. :-)
* The scale of the numbers changed so that the numbers were no longer
presented in milliseconds.
* There is a potentially ugly bug in 11.2.0.1 (and carried through to
11.2.0.2).

I was running tests at the time comparing 10.2.0.x, 11.1.0.x and
11.2.0.x and wanted to make certain that the tests were reasonably
equal, so I borrowed the system statistics that were collected by
either 10.2.0.4 or 11.1.0.7 and simply forgot about the problem. A
couple of months later, I read an article on Christian Antognini's
Blog ( http://antognini.ch/2010/11/workload...istics-in-11g/
) that explained the bug that I simply brushed off.

Randolf Geist recently wrote an article that describes another change
that he had noticed in 11.2.0.2 that is related to execution plan
costing:
http://oracle-randolf.blogspot.com/2...eneration.html

---

I am sorry to hear about the chapter 7 problem.

Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration
from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

On Wed, 07 Sep 2011 17:23:42 -0700, Charles Hooper wrote:



This is very, very interesting! That explains many things. I believe that
CBO is undergoing a quiet rewrite, which would explain this stuff with I/
O calibration. The paradigm will change completely, instead of counting
the I/O requests, they will simply want to know how much data they need
to read and, based on the calibration information, they will estimate the
time, without those pesky single and multiple block reads. That will
probably be an option for Oracle 12.0.0.0.



--
http://mgogala.byethost5.com

Mladen Gogala wrote,on my timestamp of 8/09/2011 7:43 AM:


Oh great! You mean the release the sales rep absolutely assured us was "stable"
and "in use by heaps of other customers" is actually screwed up to this point
and in such a basic way?

Lovely! Good work Oracle: the level of confidence from customers continues to
increase in leaps and bounds...

Ah yes, of course: 12.0 comes out in October and 4 months later only "dinosaurs"
will still use anything older and then openly defined as buggy.
Same old crap of the last 12 years...

On Sat, 10 Sep 2011 17:50:47 +1000, Noons wrote:

In my opinion, 12.0 is too premature. Not many companies have actually
adopted 11g in production. In addition to $40k/CPU core, there is the
question of stability, openly expressed by Oracle support analysts who
advised me to upgrade to 11.1, not 11.2, off the records, of course. 11.2
is a partial RAC rewrite release, as well as an optimizer rewrite. Those
changes are big and haven yet matured. Having two immature versions in
the wild, 11.2 and 12.0 will only undermine already rather shaky
confidence in Oracle Corp.



--
http://mgogala.byethost5.com

Mladen:

# In my opinion, 12.0 is too premature. Not many companies have
actually adopted 11g in production. In addition to $40k/CPU core,
there is the question of stability, openly expressed by Oracle support
analysts who advised me to upgrade to 11.1, not 11.2, off the
records, of course. 11.2 is a partial RAC rewrite release, as well as
an optimizer rewrite. Those changes are big and haven yet matured.
Having two immature versions in the wild, 11.2 and 12.0 will only
undermine already rather shaky confidence in Oracle Corp.

....

Yikes ... thanks for making me feel so good about my trial project
going for 11.2 on a non critical system!

All my other ones are 11.1.0.7.8 and staying pretty stable.