disk, performance question

[Penni Nussbaum]

I have a new L class that has two disk system 2100's . Each disk system contains 4 disks. One disk system is mirrored to the other disk system. The disk systems are on different controllers. The application on the server (Oracle database) is approximately 100 gig. The developers would like the disks set up so all the file systems are striped against 4 disks. Does anyone see any negative aspects of having all the file systems in 1 big volume group striped on the same disks?

[Jim Turner]

Hi Penni,

If this is just a development box, striping across four disks and then mirroring those four to another four is probably the best you're going to be able to get. Making sure each 2100 uses a unique controller as primary is also a good idea.

It is my general practice when enough spindles are available to keep the following types of Oracle data segregated:
* Data
* Index
* Redo
* Archive
* RBS

It's always a good idea to keep different data thats going to be hit hard simultaneously split out on different spindles. This reduces the likelihood of burning up time with seeks as the heads (on a common set of disks) scurry back and forth touching data then index then data then index.....

In your specific instance however, I don't know if such segregation is practical or even possible.

Best Regards,
Jim

[Penni Nussbaum]

Unfortunately, this is going to be a production system. I know ideally I should segregate certain Oracle files, but I only have 4 disks to house all the data. What I need is a definitive answer to the developers as to why all the files should not be stripped across all 4 disks. I was going to have each disk in it'sown volume group (actually 2 disks per volume group because of the mirror), so as to separate some of the files from others. The developer prefers the stripes.

[Bill McNAMARA_1]

You can tell them that if you stripe across all the four disk you have that if one of them fails, they loose everything (since last backup)

Otherwise, their compilations are probably going to be cpu intensive not disk io intensive so striping across two or four is not going to significantly improve their performance when what they need is share of CPU.

You can install prm from software.hp.com to give them a fair share of CPU, but keep the other spindles for oracle.

Later,
Bill

[Irine Gibilisco]

Ideally, for optimum performance, Oracle requires at least 5-7 separate disks. If you have queries that result in heavy sustained access of two or more simultaneous tables, these concurrently accessed table should also be housed on separate disk drives for optimum performance.
If you format the four drives as a single volume group, you will loose the ability to control where the system allocates the physical partitions for your logical volumes. Your database activities will most likely result in severe I/O bottlenecks, where your CPU will appear blocked waiting for I/O, and you disk usage will at times reach 100%. This may not happen right away. The system performance will change and drift, depending on how your data fills up the tables and which disk that chunk of the table may fall on.
Besides, if you are going to use the 4 disks as a single mirrored quorum, you might as well configure all 8 disks as a disk array (RAID) with a hot spare. The performance degradation will be similar to lumping the disks together, but you will almost double your disk capacity, while guarding against disk failure.
If you can't invest in another set of disks, configure your database on the 4 mirrored drives with more consideration for simultaneous disk access and system performance, and worry less about Oracle recommendation of keeping your logs and rollback segments on separate disks. You already have all the necessary security with the HP-UX LVM mirroring. That alone will guard you against disk failures. Work with your DBA to establish table use and location, as well as anticipated access patterns throughout the day.
I recommend that you use UNIX mirroring instead of Oracle mirroring. It is faster and easier to deal with. I also recommend that you use 'cooked' Oracle database files instead of 'raw' access.
Oracle can be really slick when disk is properly allocated, but it will be a bear (as bad as half as slow) when disk bottlenecks occur.

[Alan Riggs]

The idea behind striping is to spread disk acess across as many spindles as possible. This achieves performance benefits by balancing access to the most limited resource (the physical interface to the disks).

The idea behind segregation of data, index, rollback, etc. within oracle is to improve performance by avoiding contention for that same resource by requests which you know will be taking place simultaneously.

These ideas are, of course, mutually exclusive in your situation. Since this is a production machine, you need protection from disk failure. That means mirroring (since the 2100 does not offer RAID 3 or 5.) If you mirror, you only have 4 disks.

Now, to make matters worse, if you mirror at teh software level you cannot have true striping (byte striping -- to accord with oracle's block size, gain best balancing, etc.) You can only extent stripe. Extent striping will offer some perfomance benefit, but not that much (in my experience--data access patterns obviously affect this).

So, what do you do?

Punt. Tell them you need more disks to achieve a reasonable leel of performance.

If that is not an option, I would segregate the index volumes on 1 pair of disks. Archive preformance is rarely a significant concern, so I would bundle archive and redo on a second pair of disks. You then have a choice to either extent-stripe data & rollback across teh remaining 2(4) disks, or supply one pair to each. I personally would keep them segregated, but that's just me.

Alternatively, function without mirrors and risk *significant* business impact in event of drive failure. Don't just think "restore from backup", think "restore from backup + recreate all business transactions from hardcopy or other records + lost time for business going forward". Always consider worst case scenario when determining your level of disaster tolerance.