topic Re: Volume Groups? in Operating System - HP-UX

Volume Groups?

Jesse Delk — Mon, 15 Mar 2004 09:49:28 GMT

Very new to HP-UNIX. I have a volume group vg00 which seems to have my system files on it.

I have a tape array 5300 with 12 36gb drives on it for Oracle databases which I will load later. I have created three LUN's with these drives. 155, 50, 60gb. Active spare set to automatic, and set to AutoRaid.

155 for databases and the oracle load itself.
50 archive logs
60 backups

When going into SAM it is asking if I want to create a new volume group or use an existing one.

Should I create a new volume group for each LUN, or one group for all, or use the same volume group vg00? What is the plus and minus of either?

Re: Volume Groups?

Steven E. Protter — Mon, 15 Mar 2004 09:55:10 GMT

Its not a good idea to do your entire sysetm in vg00.

Reason: Disaster REcovery.

You can use make_tape_recovery to get vg00 images, which a lot of us normally limit to OS/boot filesystems. You can then, if a patch messes up your system recover back to from tape without overwriting your data.

This seems like a strategy post, so I'll giv you mine.

I have vg00 strictly boot and OS. vg01 is binaries, software and stuff. vg02 is exclusively for oracle data. It makes things neat and easy to remember.

SEP

Re: Volume Groups?

A. Clay Stephenson — Mon, 15 Mar 2004 10:09:04 GMT

There is no "correct" answer here but, in general, vg00 is used for the OS and for the "standard" packages that reside in /opt. This makes OS upgrades/patching/system migrations much easier.

Beyond that is it pretty much up to you. Rather than thinking in terms of LUN's and VG's, think in terms of LVOL's. Also note that a VG can be comprised of multiple LUN's and often this is a good idea since it gives you a method to spread IO across multiple SCSI buses. I would tend to divide Oracle into at least 3 LVOL/filesystems within the same VG. One for binaries, one for data/indices, and one for archive/redo logs. That lets you play with various mount options. One other approach that I would use if using raw devices for databases is to add a level of indirection. For example, suppose that you are using /dev/vg01/rlvol2 as a datafile. Rather than using the raw devive directly, use /oradata/user01.raw and then symbolically link /oradata/user01.raw to /dev/vg01/rlvol2. That way, future changes are trivially easy. You could even go back to fully cooked I/O with no Oracle changes.

Re: Volume Groups?

Marvin Strong — Mon, 15 Mar 2004 10:13:21 GMT

I would say rarely if ever, share vg00 with anything.

As far as oracle goes. How to break it up depends. Typically you want to spread the I/O out on as many channels as possible.

Re: Volume Groups?

Sanjay Kumar Suri — Mon, 15 Mar 2004 10:21:22 GMT

As most of have already recommeded, keep vg00 exclusive for OS.

As UNIX files and directories are arranged in a systematic manner, like a tree structure it is a recommended practice to organize logical volume/volume groups in similar fashion for beter management and system recovery (if needed).

sks

Re: Volume Groups?

Geoff Wild — Mon, 15 Mar 2004 11:54:49 GMT

Here's what we do:

Vgcreate volume groups as per the following standard
Preamble: VG00 - VG09 are internal disks, VG10 and higher are reserved for EMC/Disk Arrays.
VG00
The root volume group VG00 should be mirrored and only contain OS files.
Primary swap should be 1 x memory
/ - 140MB (HP Default)
/usr - 1 GB
/var - 1GB
/tmp - 512MB
/stand - 128MB
/var/adm/crash - 1 x memory + 512MB
/opt - 1GB
/home - 512MB with quotas (32MB soft, 64MB hard)
Note: /var/tmp should be a symbolic link to /tmp. /tmp should be 1777 (sticky bit).
VG01
/app - 512MB
/usr/local - 512MB
/app/admin - 512MB
VG02
File system swap
VG03
Applications
VG04-VG09
Reserved
VG10 - VG19
Log volumes (redo, archive, etc)
VG20 - VG256
Data volumes

Miscellaneous
Don't use strict/contiguous when creating logical volumes.
Create file systems with "large file" support (fsadm).
Mount file systems with "delaylog".

Rgds...Geoff

Re: Volume Groups?

Shaikh Imran — Tue, 16 Mar 2004 00:49:41 GMT

Hi,
I will strictly recommend not to use the existing one as
1)Easier to Diagnose if any problem.
2)No Quorum Problems in case of multiple Disk Failures.
3)Easier to see the i/o processes and bottlenecks.

There doesn't seems any Minus.

Regards,