When to create seperate Volume groups

[Robert Groenemans]

On most of our server we have several different applications, which have there own seperate Oracle database.

Till now we allways created 3 different volume groups for each application:
- 1 for no DB-files of the application
- 2 for the DB-files

Though, not all application are very large and
in every VG we have to put at least 1 LUN.

This way of working is not really nice, as we have lot's of VG's and lot's of waste space
(minimum LUN size 4 GB).

We would like to reduce number of VG's we have.
- Would it make sense to just create 1 VG per server?
- Are there any rules on when to create seperate VG's?

Also disks become larger and larger.
We would like to use metavolumes (EMC-Symmetrix), but those are large too,
typically LUN's from 4x8GB.

In 32GB fit a lot of our smaller applications.

...

[Massimo Bianchi]

Hi Robert,
there is not general guideline that can help you.
Here follow my personal pont of view: I prefer to separate each application in separate VG is possible.

In this way we achieve a logical separation of contents: when you need to move away an application, you know that you can take away that VG, without worries about implication over other applications.

Space is waste, maybe, but nowadays every application, sooner or later, will become angry for space. Better to reserve it now.

I would use 1 vg for every application....

Why would you ho to metavolume, have you problems for hte maximum number of luns on the scsi/fc connections ?

[Alzhy]

There is really no use creating separate Volume Groups (or disk groups if using VxVM) apart from grouping (and naming) them according to their location on your array or your SAN or its affinity with a particular application. We name our diskgroups/volumegroups the same as the server they're attached to with a suffix serial or id since we are on a SAN. This way, when the SAN goes bellyup it will be easy to find affinities or relationships.. It also works great for moving diskgroups around...

Why a single or minimalist no of disk groups? My reason is purely -- less objects exist, less obejects to manage and optimal space use. With a single or fewer disk/volume groups you can recoup remnant space to good use. And if performance is a concern -- you can always pick what LUN(s) to use for your LVOLS or volumes -- to ensure performance volumes stay on their intended LUNS/disks. There are tricks to this but is quite easily done on Veritas Volume Manager as opposed to LVM...

[Stuart Abramson_2]

I like to create one VG for each application on the server. That way:
o you can move an application from one server to another if you have to;
o you can set up EMC BCVs on a VG - VG basis.
We have between 3-9 Oracle SIDs on each server, and (roughly) the same number of VGs.

In some older servers we run one set of Oracle binaries for MULTIPLE SIDs, and set up multiple SIDs in a single VG, and then have multiple VGs for the whole shebang:

/u20
/u20/oradata/SID-1/...
/u20/oradata/SID-2/...

and then

/u20 is in VGXX

and

/u21 is in VGYY, with the same mixed up SIDs.

Try seperating that?

(Actually we don't move stuff around that much, but we are getting ready to add new servers and will move SIDs individually to new servers and retire older servers.)

[Stuart Abramson_2]

In regard to EMC MetaVolumes:

EMC seems to push them at you, I don't know why. They have this scheme called SAME, I think, which is "Stripe and Mirror Everything", but it's a bunch of junk. The stats they give you are less than 10% faster than "regular" smart disk layout and harder to maintain with more waste in bigger "allocation units".

In a few cases, where you have isolated file systems which need rapid response, Striped MetaVolumes are faster than regular, but not if you have ALL MetaVolumes.

I like regular 8 GB HyperVolumes.