Re: Physical I/O on a SAN or NAS

rgaffuri_at_cox.net (Ryan Gaffuri) wrote in message news:<1efdad5b.0312050706.20a680c7_at_posting.google.com>...
> We are using an NAS. Are there any conventions to handling Physical
> I/O distribution on NAS or SANs? They are relatively new. Since we
> dont control which disk or mount point datafiles go on, we really
> can't spread out the I/O. Does it matter if we put tables in different
> datafiles then?
>
> any conventions or articles would be helpful.

Ryan,

You might want to post your OS platform. I saw just today some articles discussing corruption issues with Oracle and NAS with Solaris 2.7, 2.8 up on Metalink.

The first time I had to administer a point-to-point fibrechannel external storage cabinet, I was quite paranoid. On internal storage I had:

- a member of each online redo log group
- an archived redo duplex destination
- last night's uncompressed hot backup set
- last night's export (full)

(the size of the databases was small enough to accommodate this with 4 x 36 GB HDs setup as a pair of RAID 1 vols).

After a sysadmin accidentally disconnected the fibre cable (which of course, crashed the instance) I was ready to just bring the database up internally from the hot backup set, local controlfile, local online redo and archived redo logs. I didn't have to, thankfully.

Years later, the same site lost its air conditioning unit. It lost a drive in a 9 drive RAID 5 cabinet prior to it shutting itself down (off-brand, did not support RAID 10 or 01). Didn't have to restore, as they only lost one drive, but had another disk failed, it would have meant rebuilding the entire volume. When you don't have control over whether the network backup picks up your backup sets or not, it sure is nice to have a staging area for backups that isn't subject to the same media failures as your primary datafile storage.

Your NAS vendor should have some best practices.

I remember a paper (#559) "Tuning I/O for performance - focusing on HP and EMC" by Wei Huang. I would also recommend the usual "how to stop fragmenting and start living" paper by Juan Loiza (Optimal Storage Configuration made easy" and other texts that discuss "SAME".

Check metalink for docs.
be prepared for (possible) corruption issues. use point-to-point connections, not switched. trunk across multiple connections.
use multiple mount points if possible.
benchmark your I/O during typical operations. try to fit into memory your sorting and hash join operations.

hth.

Pd Received on Fri Dec 05 2003 - 19:56:05 CST