36 gig internal hard drives performance issue

[Emy_1]

Does anybody know if there is big performance issue using 36 gig hard drive as a root disk also with oracle apps running on the same disk. I hear oracle apps likes to run it on smaller disk, we currently have a 9 gig drive.

system:
Hp-ux 10.2
oracle 7.3.5
Emc 3430 data storage

[Cheryl Griffin · Accepted solution]

Emma,
You want to keep your root disk as small a possible for recovery sake. The smaller the root drive, the quicker you will be able to restore the root drive and bring the system back to a bootable state. Think about how long it would take to recover a 36 Gig root drive from backup or recovery media.

A standard system does not keep application and/or data space stored in root volume group for this reason.

Use the minimum size disk in root, and save the 36 Gig drive for applications and data in another volume group.

Best Wishes,
Cheryl

[Rick Garland]

As stated previously, try to keep the root disk small for recovery.
In using Oracle, Oracle recommends that certain files be spread out on different disks. Example, the index files on one disk and the data files on another disk. Also the redo logs should be on another disk. You could encounter performance issue from the disk I/O stand point because Oracle is hitting the one disk for all of its looks. Spread them out and Oracle will hit multiple disks thus reducing the disk I/O on a particular disk.

Using mirroring or a RAID setup will ensure the high availability of Oracle as well.

[Rick Garland]

As one additional note, my personal practice is to not "pollute" the vg00.
Create additional VGs for non-OS files. This will help in the recovery as well.
Check out the make_recovery process. It is part of Ignite and is not a cost item.

[Dave Wherry]

I strongly agree with Cheryl and Rick. Keep vg00 separate from your applications and data. Use other volume groups. You are also swapping in vg00 on that disk. Do not have you application/data and swap on the same disk. Just as Oracle tells you not to have data and indexes on the same disk. Spread it out.
How many disks do you have? Sounds like you have JBOD. We've always been taught to spread databases across spindles and interfaces. Disk arrays somewhat alleviate the need to spread across spindles. Their cache helps offset putting too much data on a single drive. In an array environment balancing across interfaces becomes as much if not more important.
The basic answer is spread it out. It really depends on your hardware though.

[Jim Wolff]

Hi Emma, Just a note about spreading out Oracle files and using RAID.

First, all database datafiles should be on the raid disk since "reading" from raid is faster than non-raid disks. Remember though that writing is slower. Next, I do not believe there is much benefit of spreading the data files out into separate directories other than for the sake of logically separating different types of data files (e.g., rollback tablespace, temp, users, data, indexes, system, etc.), however, I have heard that the raid algorythym that HP uses somehow does improve performance a slight amount by using a higher number of directories, even though it is on a RAID (striped disks) configuration. I'm not sure exactly why or if that is really true. At best, I can only imagine any improvement to be insignificant.

The main point of my writing is to let you know that Oracle strongly recommends that you should *always* put your redo logs on non-raid disks since these are always only being written to by the database (and only read by the ARCH process to write to archive logs). Also you should *always* multiplex your redo logs on to separate disks. Next, assuming you are running Oracle archivelog mode, you should also put the archive logs on a non-raid device, (preferably one that the redo logs are not on), since once again, these are files that are only written to. So with this said, you basically need 4 non-raid devices. One for your root volume, two for the mutiplexed redo logs, and one for the archive logs. (You will need to determine the size of the disk you require for the archive logs.) All other database files should be on the RAID volumes, including your exports (simply for the sake of the higher reliability factor of RAID.)

Best regards.

jim

[Bill Hassell]

In general, a very large single disk is a big perfomance hit for multiple filesystems. The reason is simple: there's only one channel to talk to the disk. All requests to this big disk go through one controller and vg00 can be a very busy volume. There is also the small/single-user mentality that logical volumes are complicated and therefore, one giant volume is better. From a reliability point of view, this is not the case.

Consider the most dynamic (and critical) filesystem in HP-UX: /var This filesystem contains spooling, mail, s/w and patch install history, and logfiles, any of which could grow significantly without bounds. And once /var is full, most everything breaks. If /var is part of /, then indeed, everything will start failing.

Instead, the vg00 volume group should contain several small disks, in the 2Gb to 4Gb range. Then spread the vg00 filesystems out across these smaller disks...remember that every disk is another boost in performance because it is a separate channel. Then break up /var into critical components. Depending on your usage, /var should have separate mount points for:

/var /var/adm /var/adm/sw /var/spool /var/tmp /var/mail

That way, any single component such as spooling or mail won't take down the entire system should a massive overload on disk space occur.

From a practical point of view, 3-4 disks should be the max for vg00 as more disks will introduce more possibilities for hardware failure although the service life of most servers is less than 5 years these days, quite a bit less than the average failure rates for modern disks.

[Tim Nelson]

This is more of a comment than an answer as the previous are accurate.
We are all in trouble beings the industry seems to think that enormous drive sizes are good. I personally believe they are bad. The more spindles the better. Will the "their" answer be the same as it was to combat the poor performance of Arrays ?? 36 GB of Cache will solve the problem ?? Don't think so.

[Emy_1]

Thank you to all who responded to my question all of your reply help a lot.

[Dave Wherry]

I wanted to follow up with the replies Jim, Bill and Tim posted. Your answers are correct and not completely correct. The reason being, it really depends on the hardware configuration. That is why I asked Emma how many disks she has. It sounded like she is talking JBOD and not many disks. That limits her and really determines how she should layout her data.
I want to talk about some of the points made and I'm really not nit-picking. Just saying it really does depend on the hardware and system usage. Most of my comments are based on XP256 or EMC array environments.
The Oracle recommendation that redo logs always go on non-raid disks is outdated, but, still applicable. If you are using an IDC array, all writes go to cache and it really does not matter what disks you have, size or raid configuration. The write goes to cache and that is faster than a JBOD disk.
Multiplexing the redo logs, great idea. However do you multiplex and let the database engine handle it or mirror and let the OS handle it? Or, raid-1 on an array and let it all happen on the back-end?
As far as vg00 and breaking /var up into multiple file systems. It makes sense. But, my systems send very few mail messages, print very little and how often am I actually patching? Of course HP standing for highly patched means I could be patching quite a bit. Point being it's a good idea, but, not always worth the effort.
Big drives being poor performers. In JBOD, yes. Small to medium arrays, they can be bad. In large IDC arrays, doesn't matter. Which leads to the comment of cache solving the problem. Yes, it helps greatly. I have 4GB on an XP256 and I/O screams compared to the Nike arrays I was on. I/O is no longer a bottleneck.
More spindles always being better. On smaller systems that can't justify an array, yes. On larger systems you run into the possibility of running out of possible LUNs on an interface. You may have to go large to get all of your data on a system.
I think all of your comments do apply to Emma's situation. It's difficult to make blanket statements like "always" and "most dynamic" any more. There are too many variables.
Like Emma said, thanks for the responses, they do help a lot.