Configuration of autoraid with oracle and hp-ux

[ALH]

Hello,

We have a K580 with 4 processors and 4Gb of memory under HP-UX 10.20. There is an Autoraid 12H with 12 18Gb disks attached with hot spare on. On this autoraid there is an Oracle 7.3.4 database that is divided in two VG's of 23 Gb each. On the first VG stands the data en two redo files. On the second stands the indexes en two other redo files. Each VG is one LUN and the LUN's has crossed Controllers. The Oracle database has an block size off 8KB and the Filesystems too.
The autoraid has read/write cache on TRUE and the simplified resiliency mode = High Performance
there is about 71Gb unallocated space and about 62 Gb raid 0/1 allocated.

I have now the following questions:

1) What are the best values voor the buffer cache kernel parameters
db_pict_max, dbpict_min, nbuf , bufpages
And what is better Fixed or dynamic buffer cache

2) I have seen that the read throughput is less than the write troughput. Is this normal with above settings or not and what are the read/write settings exactly do.

3) What is the method for an Oracle database on an autoraid. Is that the above configuration or the method with LVM striping

4) If LVM striping is the best method what is the best configuration of this method and what are the rules. I think of oracle Block size, Stripe block size, number of stripe disks etc etc.

These are many questions, but we are now trying to find the best way of configure an Oracle 7.3.4. database on an autoraid. I must here say that we think about an Hass Unit for all the logging of the database and the application.

I hope that someone can help me.

Cees Wielink

[A. Clay Stephenson]

I have been running very nearly the same configuration on a number of K boxes for quite a while and I think I can give you close to the optimum setup for ORACLE. The real key is to use the OnlineJFS product for vxfs filesystems. You really only need 1 volume group but comprised of 2 equally sized LUNS.
The primary path for LUN 0 should be on one SCSI channel (e.g c5t0d0 alternate c6t1d0)while the primary path for LUN 1 should be on another SCSI channel (e.g. c6t1d1 alternate c5t0d1). You should then setup at least 2 logical volumes in this volume group. Lvol1 can contain ALL data and indexes except redo logs and archive logs. Lvol2 will contain the redo logs and archive logs. When you create each logical volume, specify striping of 2 and a blksize of 64K.
i.e. lvcreate -i2 -I64 -LXXXXX
-nlvoln /dev/vgxx. This will ensure that both controller X and Y are used for all I/O. The next key is to mount the logical volume with the data and indexes with the convosync=direct,mincache=direct,nodatainlog,delaylog vxfs options. These options bypass the unix buffering and thus behave as raw disk but allow the convenience of cooked files. The other filesystem should use the conventional mount options. Using the above methods, I observed a 30% increase in throughput from a configuration very similar to the one you described. In addition, using the Online JFS extensions, you can also make snapshot backups
so that you can down the database, snapshot the filesystems, and bring the database back up for users in less than two minutes. You are then free to backup the snapshots at leisure. This gives you all the comfort of a cold backup with almost the availability of a hot backup.
As far as kernel tuning, now that almost all of the buffering is done in the SGA there is little need for large amounts of unix buffer cache. I turn off dynamic buffer cache by setting bufpages to a non-zero value. I find that for pure database server boxes a buffer cache of about 320MB (bufpages 80000) works well and is probably overkill.

[L Tattrie]

At a site where autoraid was installed in production database environment the dba reported the autoraid performance as abysmal.

At our site autoraid was installed in a development environment and the performance was abysmal. No tune made it better. Eventually we heard a rumour that autoraid is not for database environments.

One of the good / bad aspects of autoraid is it moves recently used files to raid 1 and less used files to raid 5. When a cold backup is done to disk every backup file is changed so all backups on disk try to switch to raid 1. The back for the next database runs and its backups switch to raid 1 and so on until space runs out. Autoraid move files from raid 1 to raid 5 to gain room. So autoraid might work well in a general file server type of function where all of the files are not being updated every day, tuning autoraid in a database environment where there is much happening could be a problem.
If you want some 'fun' try multiple compresses running at the same time.

[A. Clay Stephenson]

You stated that you had > 50% of the space unallocated. That is very important so that the Auto-RAID always says in RAID 0/1 mode.
For databases always leave at least 40% (a little more is better) unallocated and the AUTO-Raid never has to go to RAID 5. If your organize your volume groups/logical volumes so that BOTH external SCSI paths are utilized they perform quite well in an ORACLE environment.