This content has been marked as final. Show 7 replies
Hi Jan-Marten,1 person found this helpful
if I can remember correctly there was a discrepancy in 10.1 and 10.2 database vs. the definition in ASM.
This resulted in 10.2 time (with ASM) that the database tracked information in "hundredths of a second" while ASM did report the findings in "seconds".
As a result if you quered the I/O stat, you new that the database reported I/Os were always wrong (I though it was by 1000, but it could be that it was by 10000).
In 10.2. v$asm_disk_iostat was not included in the documentation, hence nobody really argued and thought that this was only a wrong description...
This "discrepancy" between database and ASM was fixed in 11.1.
As a result a 11.1 database and upwards has the same value as the ASM diskgroup.
However since it is the DB which is doing the I/O, it is also the DB tracking this information. So the 10 database will still report the wrong numbers (by 10000) while the numbers of an 11.X database will be correct.
So in future this is fine. And since 10.X databases are out of support anyway, upgrade to 11 and your issue is fixed. I doubt you get it fixed by Oracle for 10.X.
thanks, but things are a bit more complicated i fear... it is the Oracle 11.2 ASM instance that is reporting the wait timings from Oracle 10 and 11 on different scales but in the same view. That looks like a bug in 11.2 to me.
Although it's true that oracle 10 is no longer supported, there is lot's of them out there - and i have a problem in monitoring software that has to cater for that reality.
Your point that it will probably not be fixed seems likely, which would allow the current workaround (detecting instance version and fix the discrepancy in a case statement) to remain viable for the long term.
Hi Jan,1 person found this helpful
the thing I wanted to point out is, since the database is doing the I/O it is the database who reports the I/O statistics to the ASM instance (Which you then get displayed).
If the database however does pass the wrong numbers to ASM, it is a bug in the database, and not in ASM. It is not the task of the ASM instance to do a conversion of wrong numbers ;)
"the thing I wanted to point out is, since the database is doing the I/O it is the database who reports the I/O statistics to the ASM instance"
i assumed it was the other way around. is this something you know or something you presume?
ASM is not an I/O proxy layer. It does not do I/O on behalf of the database. The name says "+manager+" - as in it serves as the storage management layer. Not as an I/O driver.1 person found this helpful
Introducing an I/O layer in between a database server process and its ability to do direct I/O to a device, would have serious performance impact.
Support Note: *ASM Concepts Quick Overview [ID 1086199.1]*+
ASM exists to manage file storage for the RDBMS - ASM does NOT perform I/O on behalf of the RDBMS - I/O is performed by the RDBMS processes as it does with other storage types - Thus, ASM is not an intermediary for I/O (would be a bottleneck) - I/O can occur synchronously or asynchronously depending on the value of the DISK_ASYNCH_IO parameter - Disks are RAW devices to ASM - Files that can be stored in ASM: typical database data files, control files, redologs, archivelogs, flashback logs, spfiles, RMAN backups and incremental tracking bitmaps, datapump dumpsets. - In 11gR2, ASM has been extended to allow storing any kind of file using Oracle ACFS capability (it appears as another filesystem to clients). Note that database files are not supported within ACFS