[jrigler]

Our DBAs are doing a disk analysis project and I have given them 5.2 iostat information. They are very interested in total number of reads and writes for the time period, in addition to the amount of data read or written. I gave them the transactions per second value, but this isn't quite what they want either. What specifically is this statistic? Why not give transaction for the inverval? Is this the maximum number of transactions for any given second, or is it an average? My interval is 5 minutes, so I could multiply TPS by 300, but I am suspicious of this. When I do random reads of larger blocks of data, I see greater TPS which makes me think it is an indication of better performance. Is there a way in 5.2 to see total transactions or total reads/writes. I see this for iostat on 5.3, but not 5.2

[Mark Taylor]

Why not use filemon ?

Rgds
Mark Taylor

[cdelgadop]

Hi

My recommendation: use nmon.

Nmon is an interactive tool written by a very inteligent guy from IBM that allows for data gathering on a given interval of many statistics for CPU, memory, disk and networking subsystems, then you can take that result file and generate some very nice graphics using nmon_analizer. You can then use that information to make analisys.

IBM Wikis - AIX 5L Wiki - nmon

Hope this helps

[Mark Taylor]

Its horses for courses really, What data do the DBAs need ? if they want granular stuff like avg seek/read/write times, %seek avg read/write sizes, then nmon is no good .. its got some great high level stuff and is good for capacity planning and growth planning and is a must in all AIX admins toolkit, but for low level stuff then filemon wins hands down.

Rgds
Mark Taylor

[jrigler]

We used to use nmon, now we dump a bunch of stats into a database and make pretty graphs and charts. The DBAs determined that 'transactions per second' is congruent to 'i/o operations per second' and would work for what they want. We have given disk planning over to them since they are the biggest DASD user and SSA has died a sad and painful death to be replaced with the SAN. Now they have come to the conclusion that they need totally dedicated storage groups on the SAN with one LUN on each, essentially were we were 10 or 15 years ago with the SSA, but hey this stuff uses lasers so it can't be all bad. ;-)

[ross.mather]

Ahhh the Database boys. One of the big troubles you will face with teh database boys and their sizings is that they negelect to take into account the 64Gb kinds of cache in the big storage boxes.

In every case I've had with a DBA since doing SANs where i say - lets start with everything on RAID5 where ever I put it and I'llchange it if it doesn't work, it has been sufficiently fast.

Remember that DBA disk allocations - especially Oracle - are still determined on the basis of head movements in SCSI disks. Hence the original 22 disk solution Oracle wrote. This is simply the case of not updating the info.