show disk speed

[samsam001]

Hi, the server ES80 is running Tru64 5.1B-4.
There is a SAN Storage attched to its /dev/disk/dsk28 device (or scsi card).
What command I can use to print know its speed?
hwmgr doesn't show its rotational speed or data transfer rate between the local device (dsk28) with the SAN Storage.

Thanks
S

[Venkatesh BL]

The 'RPM' can be found in the 'disklabel' output.
The number of transfers per second and bytes transferred per second can be found using the 'iostat' command. Look into the manpage for more details.

[jim owens_1]

Unless you have configured the disk as a "passthrough" (which you should not do), the values seen by the host disklabel are not real. The SAN device returns fake values to the host for transfer and spindle speeds because physical disks are hidden and managed by the SAN.

You can only view the physical disk parameters from inside the SAN management environment. See the SAN device documentation or try the storage forum.

[Ivan Ferreira]

It's unlikely that you can get SAN storage disk speed using hwmgr because the SAN presented disks normally are disks arrays, not a single unit.

Use your Storage Management software or Storage CLI to identify disks attributes.

[samsam001]

We have two ES machines, with roughly the same CPU (one with 1835008 bytes cache, another with 16777216 bytes cahce).

Each of these ES servers attached to a different SAN storage. As we are moving from one machine to another, we need to transfer all oracle data from one to another as well, so we need to measure the among of time will take to transfer TB of data to another. This operation will simply involve reading data from a ES server and writing it to another ES server. Therefore I want to know the disk I/O speed that associated to this 2 SAN storages.

I tried to use iostat, but since both servers are dealing with different amount of data, its result is not the real I/O comparison result between this 2 servers. I may be use iostat test the same 2BG file on each server after stopping the Oracle database, will this method more accurate?

Thanks Sam

[Hein van den Heuvel]

Thanks for the further explanations.

Your main questions make a lot of sense.
The detail questions and observations make no sense to me, but so be it.
- CPU cache size is largely irrelevant, for this purpose, the CPU speed might matter a tiny bit.
- The RPM for a disks is critical for maximum random read rate, but largely irrelevant for the max MB/sec which you seem to need to know.
- Whether is it dsk28 or dsk123 matters none as those names are entirely artificial. What MIGHT be important is how they are connected which is not clear. Please re-read your opening statement. This dsk28 seems to be both local and connect to the SAN?! Where are critical details like which Fibre-channel adapter? Which switches? (Which SAN? EVA? EMC?...)

>> Each of these ES servers attached to a different SAN storage. As we are moving from one machine to another,

I don't understand. Why move the data if it is available on the SAN?! Just re-present to the next server and use it! No muss, no fuss, 1,000,000 MB /sec :-).

>> we need to transfer all oracle data from one to another as well, so we need to measure the among of time will take to transfer TB of data to another.

Just try some data set between 2GB and 10GB and extrapolate. You can use the live fiel for input. And I should think you can use the real target as test target. Nothing valuable there no?

>> This operation will simply involve reading data from a ES server and writing it to another ES server.

You mean NFS? The surely the NETWORK speed is more critical than the storage speed. Do you have your Gigabit link in place?

But again, why not just connect the old storage to the new server?

>> Therefore I want to know the disk I/O speed that associated to this 2 SAN storages.

Not really. IMHO.
You might want to calibrate with commands like
dd bs=1024k count=1000 if=/dev/zero of=/new-mount-point/tmp.tmp
and
dd bs=1024k count=1000 of=/dev/nul if=/old-mount-point/some-large-oracle-file.dbf

Please note that if you really need to move the data, that you might want to use this opportunity to review your Oracle Backup/Restore setup. If that is worth anything, then that _ought_ to be able to support this move no? If it is not good enough for the move, then one has to wonder whether is it good enough for production protection?!

Or you may want to use the opportunity to review and try your DBA data re-org strengths.
If you consider an Oracle DB, then oftem much more then 1/2, sometimes 90% of the space it recoverable without backup.
- pre-allocated empty data files.
- redo, temp, undo which have nothing useful during a move
- Indexes can readily be re-created.

You may find that it is preferrable to
EXPORT | COMPRESS | MOVE | DECOMPRESS | IMPORT + CREATE-INDEX
This is extra interesting if you can run some of this stuff in parallel.

>> I tried to use iostat, but since both servers are dealing with different amount of data, its result is not the real I/O comparison result between this 2 servers.

Agreed, that only gives an indication.

You might as well call it 50MB/sec = 200GB / hour and be done with it.

>> I may be use iostat test the same 2BG file on each server after stopping the Oracle database, will this method more accurate?

Infinitely more accurate.

Hope this helps,

Hein van den Heuvel
HvdH Performance Consulting

http://forums1.itrc.hp.com/service/forums/helptips.do?#overview

[Pieter 't Hart]

>> Each of these ES servers attached to a different SAN storage. As we are moving from one machine to another,

Sam, dou you mean two different SAN's or just different "disks" on the same SAN?
If it's the same SAN I'd follow the suggestion of Hein just to present the disks to the new host.
Or if you want to be safe do a SAN-copy (snapshot/clone) and present the copy to the new host.
If you have two separate SAN's consider merging them first to do this operation.


Involving the unix-hosts in this copy operation sincerely downgrades the speed. NB! the database has to be brought down during the copy operation by the unix-hosts.