Guidelines for vg setup

[Lasse Kemiläinen]

Hi,
I'm setting up an Oracle db on EMC Symmetrix. Initially we've reserved 1.5 TB disk space (net) for the db. Is there any advantage, from the performance point of view or otherwise, in splitting the disks into several volume groups rather than defining one big vg ?

[Steven E. Protter]

Shalom Lasse,

Performance is determined by the underlying setup of the disk itself. If this is a database with heavy writes, and the underlying disk structure on the EMC is raid 5, then you will encounter performance problems whenever writes get heavy.

I don't see any advantage in either setup beyond that. If you can afford it, try and get data/index/redo logs onto raid 10 configured EMC disk, it this is an (OLTP) system.

When you define the volume groups, don't forget the -p paramter of vgcreate. It lets you define the maximum number of physical disks. Set correctly it can provide you more usuable capacity.

Set to default or too low, and you'll end up building the vg again in the future when you want to expand.

SEP

[Jeff Schussele]

Hi Lasse,

Yes there is, IF, you have 2 or more HBAs connecting to that array. Then you could define the primary/alternate paths to those VGs such that the load is spread across all of them.
Ideally you want at least as many VGs as you have paths - or a multiple of those paths.
And if you make all LUNs available to all HBAs & define all of them in the VGs then your reads will be better because they will always go to the least queued up path.

Rgds,
Jeff

[Geoff Wild]

Performance wise - separate vg's don't really matter - but from an admin point of you - it can.

Example - one of my systems is 1.5TB of SAP on Oracle.

For performance - I only use RAID10 on DMX 1000.

I have 3 vg's - one for sapdata, one for Oracle logs, and one for the rest (SAP/Oracle binaries, etc.).

For backup, My Netbackup server only has to mount the bcv's of the sapdata vg locally - then uses brbackup to backup the db.

Rgds...Geoff

[Christine Hartman · Accepted solution]

I would say yes to this. Usually what I do is have a separate vg for the large dbf files, that way I can specify a larger extent size to use..also if you do any striping you can use a larger stripe size. I also create a vg for the oracle bin area and maybe for temp table spaces (small stuff)...I use a smaller extent size for them. Also this keeps them isolated from the large dbf files and helps with backup options (you can use say veritas flashbackup for the bin area which contains many, many small files). Then I create a separate vg for the oracle archive logs area...this will make sure that the archive logs and dbf files are not sharing the same disk space area.
I've worked with EMC extensively on configuring disks/filesystems, etc. for oracle environments....trust me...you will get better performance (from an oracle perspective) if you split up the data into different VGs and take advantage of the different extent size options and striping size options.

Hope this helps.

[Lasse Kemiläinen]

Thanks to everybody for your suggestions. It's a SAP system and I had already planned creating one vg for saparch and one for the non-sapdatas. I'm leaning towards putting all sapdatas in one vg, then add new vg's if the db expands and new disks will have to added.

Christine's reply leads to another question: EMC recommends creating logical volumes with extent striping (lvcreate -D). Is this what you mean by striping or would you use -i striping on Symmetrix metadisks ? I know this issue has been discussed previously on the forum and there's support for both alternatives.

[Christine Hartman]

I've done it with the -i on meta vols for a 400GB oracle DB...here they use the -D..I have not been here long enough to know if they have any performance issues during month end or not? The DB size here is about 1TB....and they do have multiple LVs/filesystems for their DB...but not multiple VGs...all dbfs are in one large VG.

[Geoff Wild]

Same here - I have a 1.5 TB SAP system - all db files in 1 vg - but I have multiple lv's - each one is 134 GB (made up of 4 x 33.7 GB metas).

Rgds...Geoff

[Devender Khatana]

Hi,

I would suggest to create it using -i option only as here you have the option of defining the stripe size which will be in KBs whereas with -D option the minimum size will that of one extent and that for such a large VG can not be less than 16MB or so.

Coming to the point of creating a big VG or multiple, I think you will have a better throughput and easy configuration by having multiple VGs for seperate sort of files. This is because of different usage of different LVOLs. Always divide your requirements in atleast three types for such instances i.e. datafiles, redo logs, archive logs.

You should have different VGs atleast for al of these so that for tuning you can change particular parameters and the others will not be effected from that.

Also from storage part at similar applications we have redo VG's mirrored using raid 0+1 ( In Backend at storage level) and others with Raid5.

Also redo VGs use disks of 15K RPM whereare others are of normal 10K RPM.

The important part as you are using pvlinks would be that you define your disk device files carefully while configuring so that the load is balanced across multiple HBAs. For this you need to use different alternate links properly.

HTH,
Devender