LUN's for Oracle

[Tonny Sejr Kromann]

Hi

We have EVA8100's and Oracle 10g on HP-UX 11iv3. At the moment we have one big lun for the database datafiles, one redologA, one redologB, and one for other filesystems.
To improve performance I would like to have 4 LUN's. Would it be ok to create 4 LUN's --> 1 vg, containing all volumes for database, redologs and filesystems? Or should I have 4 LUN's for redologA, 4 LUN's for redologB and so on? ( we have 4 HBA's and 8 cpu cores ). Hope for some advice, thanks.

--
Best regards
Tonny

[Wim Rombauts]

I am not 100% familiar with the HP-UX 11i v3 IO-stack, but for HP-UX 11i v2, there is an IO queue per LUN, so it makes sense to use multiple LUN's for your databqse, but don't overdo.
I would :
Create one LUN per redolog member.
You could also create a separate LUN for your Control files.
If you want to go for fatabase performance, take care to have your control files and redologs on the fastest disks and the fastest IO cards.
Create a few (4 may be a good number) for your datafiles, but be sure the logical volumes are striped over these LUN's to balance IO over the LUN's as good as possible.
Create 1 or 2 LUN's for things like the archive logs. Again, if you have 2 LUn's use striping.

[Tonny Sejr Kromann]

Some additional info:
HP-UX 11i v3 should include functionality like the "Secure path" product which should balance load over the HBA's.
Each LUN will be a vDisk on a diskgroup of 72 physical disks on the EVA's, so there's no difference on the LUN's I can create.
At the moment I very often see 100% busy (sar/glance) on the LUN where the Oracle database files are, and one of the controlfiles I believe.
As I understand your comment, it might be better to have seperate queues for all types of LUN's? Meaning f.ex. 4 LUN's for redologs, 4 LUN's for database files and so on. They will be combined using extent based striping. But still on the same physical diskgroup on the EVA's.

--
Best regards
Tonny

[Yaniv Valik]

Hi Tonny,

As Wim suggests, separation of database data files and log files to different LUNs will improve performance.
Assuming redo log file multiplexing is used, don't store all the redo log members of the same group on the same set of LUNs. A redo log group should have at least two members such that each member is stored on separated LUNs. This is important for optimal data protection and availability. It doesn't necessarily mean that every redo log file should be stored on dedicated LUNs - Multiple redo log files of different redo log groups can be stored on the same set of LUNs.
Moreover, for the best results, I believe it would be wise also to separate redo log files and archived redo log files, storing each file type on dedicated set of LUNs.
As for control files, have multiple copies of the control file. Do not store all copies on the same set of LUNs. Similar to the redo log multiplexing, this is important for data protection and availability.
Striping would also help as well as SAN I/O multipath configuration with load balancing (Be sure to utilize all the 4 HBAs and that all you paths are alive).
Use RAID1 LUNs devices if possible and don't configure also LVM mirroring/raid5 on top of that.
I also suggest that you search the forum for "HBA queue depth". For example - http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1242339829044+28353475&threadId=1055954.
I had my share of queue depth issues on AIX....which needed tuning.

If these are replicated LUNs, there are additional best practices (especially in case of synchronous replication).

Best Regards,
Yaniv
Continuity Software
http://www.continuitysoftware.com

[Eric Antunes]

Hi,

As Yaniv said, use RAID 1 preferably:

- for all the database files and controlfiles use RAID 1 preferably;
- for redologs, use RAID 1 (don't use RAID 5 LUN's).

Best Regards,

Eric Antunes

[Volker Borowski]

Hi,

first comes saftey, then comes performance.
The absoulute minimum are 2 LUNs for the DB.
One for the datafiles, one for the archivelogs. In this setup you need to soft mirror the online redologs on both LUNs.

Surely, this is a bad performance setup, but
you will be able to do a complete recovery if a single LUN fails.
(And yes, even LUNs on a SAN, although they are Raid-whatever, may fail)

For performance reasons more LUNS are better,
so you can seperate sequential (log) and random (datafile) IO, (and Indexes, and undo, and temp, and ... depending on Load Profile),
but never distribute a datafile to the LUN
with your archive logs.

Volker

[Tonny Sejr Kromann]

Thanks a lot for the help to all of you.

--
Best regards
Tonny

[Tonny Sejr Kromann]

Thanks again - closing thread :)