Re: Oracle and SAN

James Chappell wrote:
>
> H'mm. I'm going to feel anxious over Christmas. Out network guys have
> told us that they are going to implement a SAN solution (sounds like
> something you put down a lavatory!) over the Christmas shut down. As
> yet, they haven't had ANY consultation with us DBA types.

Well, here is my $0.02's worth.

I have run Oracle on both dedicated (mirrored) disks and an EMC SAN solution. I much prefer the EMC disk array. Here is why. 1. The disk array has lots (8 GB) of I/O cache. This means that writes are instantly acknowledged so Oracle does not have to wait for the actual disk access. This makes the write proves much faster. Also, the I/O cache means that I Oracle can perform some reads faster because the disk array does some read-ahead. 2. We can perform a full backups of six databases ranging in size from about 10GB through over 300GB in about five minutes -- hot. Cold takes a little longer because of the database and application shutdown and startup cycle times. We use what EMC calls BCVs (Business Continuance Volumes). Instead of a single mirror copy of the logical volume, we have two (actually three so we can clone production to Model office). This means that to do a hot backup we:

1. Put all of the tablespaces into backup mode.
2. Run a script to split the BCV volumes.
3. Take all of the tablespaces out of backup mode.
4. Copy the BCV volumes to tape -- can take as long as necessary and, depending on the backup facility you have, can be either full or incremental.
5. Resync the BCV volumes to the data volumes. 3. Striping. This also improves I/O 4. Full mirror. DO NOT under any circumstances let those hardware clowns do RAID 5. 5. Many logical disks. This allows you to logically distribute your files. They can also, optimize read and write on certain disks to support your various needs. For instance you can set-up the mount points like this: /a01 - all software for oracle and applications. Including bin, sh, ctl, sql, doc, etc. /a02 - log and list files. bdump, cdump, udump, application logs, etc. (soft link bdump, cdump, udump back to their OFA locations. /a03 - application data backup and export files. /n01 through /n08 - four duplicate log file locations /u01/oradata through /u##/oradata - Oracle data files and only Oracle data files. /p01 through /p## - public disk for other uses.

Some things to watch out for:
1. Do not split your installation between server internal disk and disk array/SAN disk.
2. Watch out for EMC Fast Path(tm). We have found that the latest version can cause an OS panic and reboot when flooded with data. We are backing down to 2.02(IIRC) this weekend because it does not have this problem. Other than that Fast Path(tm) seems to be a worthwhile product.
3. Full mirroring is the only way to go. Well, you can do RAID-5 for archive log files, and other write-only logical disks. SFAIAC, all other logical disks should be mirrored. The write cache will take care of the latency imposed on writes and reads will be faster for mirrored. With RAID-5, write will also be supported through the cache but reads will still have to go through parity check before the data is passed down the buss.

In your situation, if the hardware guys are not consulting with you, I would:
1. Find out how much raw disk is being installed (if it is in marketing GB multiply by .93 to get an estimate of the engineering GB -- marketing calls 1,000,000,000 a GB, engineers call 1,073,741,824
 a GB).
2. Divide the engineering GB by two to get an estimate of the mirrored disk available. Divide by three if you are going to use BCVs.
3. Come up with your own logical disk plan to provide an optimal installation for your Oracle installation. Remember, you do not have to have all mount points the same size. 4. Present it to your implementation team/manager and ask them to implement/consider/evaluate it. After all you are the expert on how your Oracle implementation should be built and you should have a voice in how the disk supporting your databases is implemented.

The forgoing is all based on my experience so remember YMMV.

-- 
Andrew Allen
Livonia, MI
E- Mailto:ajalle_at_ameritech.net