how to explain the data collected by iostat on Oracle raw devices?

[Hanry Zhou]

I have run "iostat 900 96" on raw devices that are all used by Oracle ASM disk group.

As you can see below, some of them they got all 0's on bps and sps.

Also for these not 0's on bps and sps, why the values on these columns got little changed. And the value on "msps" even never got changed, and they all appear to be "1.0".

Could somebody please explain to me? Thanks!


device bps sps msps
c17t1d1 0 0.0 1.0
c19t1d1 0 0.0 1.0
c7t1d2 0 0.0 1.0
c9t1d2 0 0.0 1.0
c17t1d2 0 0.0 1.0
...


device bps sps msps
c5t8d1 23 1.3 1.0
c12t8d1 22 1.3 1.0
c15t8d1 22 1.3 1.0
c22t8d1 22 1.3 1.0
c5t8d2 23 1.4 1.0
c12t8d2 23 1.4 1.0
c15t8d2 23 1.4 1.0
....

[Hanry Zhou]

My question also, does that make any differences on how we should read these statistics when the disk is raw and used by Oracle or when the disk is used by Unix file system?

[Matti_Kurkela]

You did not specify your HP-UX version, but "man iostat" on HP-UX 11.31 includes this:
-----
With the advent of new disk technologies, such as data striping, where a single data transfer is spread across several disks, the number of milliseconds per average seek becomes impossible to compute accurately. At best it is only an approximation, varying greatly, based on several dynamic system conditions. For this reason and to maintain backward compatibility, the milliseconds per average seek (msps) field is set to the value 1.0.
-----

In other words, the "msps" field is not real data: it is just a placeholder for legacy compatibility.

"iostat 900 96" means you got 96 groups of results in 900-second intervals. All zeroes for a device on a particular interval would mean there was no need to access that disk at all during that interval.

Have your DBA look at the Oracle-level statistics for more information. If the database was mostly idle during the time you ran your iostat, it should be no surprise that the disk access level was low.

On the other hand, if the database received a lot of requests, then the low amount of disk access must mean the requests were very repetitive (i.e. the users/applications kept requesting/updating the same data over and over), and almost all the requests could be satisfied using Oracle's internal cache.

MK

[Bill Hassell]

iostat is simply too archaic for today's disks and applications. Forget it and use sar -d for much more useful (and accurate) information. If you're running Oracle, you have lots of money so you can buy Glance and get all the information you need to analyze your disk, memory, network, and so on.