One volume or many for Oracle database on XP SAN ?

[Graham Cameron_1]

Sorry it this has been posted before - I couldn't find it.

We are about to move all our applications, most of which are Oracle, from direct attached disk to XP128 SAN.

In the previous model, we would create logical volumes and map file systems onto them to loosely reflect the physical disk, eg:

/dev/vg01/lvol8 9240576 8088944 1079661 88% /data/oradata8/iom
/dev/vg01/lvol7 8192000 5839959 2205045 73% /data/oradata7/iom
/dev/vg01/lvol6 8192000 7632023 524983 94% /data/oradata6/iom
/dev/vg01/lvol5 8192000 5966975 2085966 74% /data/oradata5/iom
/dev/vg01/lvol4 8617984 7859320 711251 92% /data/oradata4/iom
/dev/vg01/lvol3 8192000 5557351 2469988 69% /data/oradata3/iom
/dev/vg01/lvol2 8192000 6336730 1739317 78% /data/oradata2/iom
/dev/vg01/lvol1 9240576 8384136 802974 91% /data/oradata1/iom
/dev/vg03/lvol1 15368192 1966492 12983104 13% /data/archive

But in future, where the disk usage is managed by the SAN, and presented to the host as a block of storage, do we still need to do this?

We still want to separate logs and redo from data, but since we are going to be doing backups by business copying and mounting the copy to a mount server, it would be much easier to manage if all our oracle data files are on a single filesystem.

Is there any reason not to do this? All we can think of is that HP-UX may perform less optimally if all i/o is through a single device special file, rather than several.

Thoughts, experiences welcome.

-- Graham

[Ashwani Kashyap]

There should not be performance problems because the storage array typically has sufficient amount of cache . All i/o's go mostly to the cache before going to the physical disks .

As far as keeping your data separate from logs and redo , you can still do that and seperate out your logical volumes accordingly .

busines copy is done at the LUN level not at file system level , so you will still get everything on your backup server .

[Duncan Edmonstone]

Graham,

There's still plenty of reasons to use multiple LUNs.

Read the following document:

http://otn.oracle.com/deploy/availability/pdf/SAME_HP_WP_112002.pdf

This is all equally true of the XP128

HTH

Duncan

[Mike Naime]

One reason not to do this would be the amount of restore time on a large volume. We recently went through this with our DBA's at work. If you have a 1TB DB, how much downtime do you want to take if you trash the DB at the OS level. I.E. If a LUN gets trashed, how much data do you have to restore, and how long will that take. We recently had one client system that was having some hardware issues. Multiple drives in the raidset were producing errors. Before it was all over, the LUN was trashed at the OS level. We wound up restoring the DB on another storage controller. This took several hours to restore the DB from an RMAN backup at a restore rate of about 100GB/hour when restored from one EVA to another EVA.

Mike Naime

[Dave La Mar]

Graham -
My .02 worth.
We have a 1.5 tb Oracle db spread over 3 volume groups and 31 + logical volumes. Most logical volumes are 56 gb which is 4 luns in our 14gb slice environment.
The volume groups are named with reference to the primary logical volume.
i.e. /dev/vgjdaprod/lvol0_3e 56885248 47108064 9700808 83% /xp512/ldev0_3e.
Backups are performed against the Business copy volumes.
Note: There are other methods for performing the naming and mounting of the business copy, but we chose-
1. Use same volume group and lvol name. This makes inprting the vg to another machine a snap. All that is different is the actual disk.
2. No vgchange id needed for the vgid since we are using the same that is written to the header of the Business copy disk.
3. No threat of mounting the wrong disk as this is secured via the secure manager of the XP.

In addition:
1. All redo logs, archive logs, etc. can be directed to the same vg but different lvols.
2. In doing the above lvol work, backups are designated in groups of lvols, thus we can control the total backup/restore time. (Less than four hours for a full tape backup in our environment.)

On another note: At least in our shop, we found out the hard way it was faster to restore from full than from using RMAN, but that decision is totally dba, environment, and application dependent.
On the i/o note, separate lvols allow for distribution of i/o in locating and distributing "hot spots". To date we have never been i/o bound.
Our choice to stipe via lvol over the XP512 stiping again is totally environment and application specific for your performance needs.
As somoen else noted, one "large vg" is very difficult to manage in a backup/restore situation.
Best of luck to you with your installation.

Best regards,

dl