We use a dedicated HP EVA SAN to host the SQL backend for our application. I believe the disks are in a large shared pool (24 disks RAID10).

The SAN is split into several LUNs which hold the SQL components(OS, System DBs, TempDB, Logs, Data, Indexes, Backups).

Is there any performance benefit in having these LUNS split this way when using a shared pool of disks - could we just have configure one large LUN to hold it all?

When I monitor the LUNs using perfmon physical disk counters it does look as though each LUN is isolated.


I'm sorry but I have to strongly disagree with ynguldyn, what they say might be true for other disk arrays but this is an EVA and I'm a through-and-through EVA-guy. We have dozens of them, all models and sizes, and there's literally zero benefit breaking up disk-groups into smaller units, they're designed that way and offer best performance when in one big block. In fact splitting disk-groups slows EVAs.

For example one of my newer 8400's has 16 shelves of 12 x 450Gb 15krpm FC disks, using iozone we tested it split into two disk-groups and it was 20% slower across the board of tests in this manner compared to a single disk group.

Also the array isn't broken into RAID types at the disk-group level, so it's not RAID10 for everything, individual vdisks (LUNs) have a particular RAID level but the disk-group itself only has the option to pre-allocated one or two hot standby disks (leave this at one by the way). This way you can give DB logs, MSDTC, Quorum etc. LUNS R10 and choose how your data and backup LUNs are setup based on your performance requirements (personally I use R10 for all data and R5 for backups but that's your choice). Oh and it's much quicker, and safer, to keep all your different DB data types in separate LUNS ok :)

If you have any follow-up questions regarding EVA's/XP's or other HP storage feel free to come back up me ok.

  • 1
    The one case I've seen where different disk groups made any difference was using FATA (Fiber ATA) drives on an EVA4400. I saw noticeable improvements there. However, those drives are not intended for database loads. FATA reaches I/O saturation far faster than FC drives. For straight up FibreChannel disks? One big disk group is all you need. – sysadmin1138 Dec 23 '09 at 22:59
  • God I hate those HP FATA disks, we've seen shocking failure rates on them (like 25%pa!!!) and their DG-levelling speed is appalling, utterly hate them. – Chopper3 Dec 23 '09 at 23:08
  • I'm not sure where you're actually disagreeing with ynguldyn? The question was whether to have a single LUN (~vdisk) or multiple LUN's on the same pool (~disk group). And ynguldyn says there's no performance difference, which is correct. Also, to be pedantic, EVA's don't have hot standby disks, they use distributed sparing. – janneb Dec 23 '09 at 23:18
  • @sysadmin1138 Yeah as a rule of thumb you should avoid having disks with wildly different performance or capacity in the same disk group. In practice we tend to have all FC disks in one group and all FATA disks in another. There is some capacity and potentially performance loss from having different capacity disks in the same group (when we expand new disks are often bigger), but OTOH as Chopper3 said there is a benefit from having as few DG's as possible, so it's a compromise. – janneb Dec 23 '09 at 23:22
  • @Chopper3: FWIW, we haven't had any reliability issues with FATA disks. But yeah, they're big and slow so rebuilding takes time; VRAID6 helps me sleep at night. – janneb Dec 23 '09 at 23:26

You gain nothing in terms of performance one way or the other. But you gain a lot in terms of manageability with smaller LUNs assigned to specific tasks.

It's worth noting that you're not utilizing those disks efficiently. Backups never need RAID10; in many cases, data and indexes don't need it either. If you ever decide to redesign storage and start using RAID5, having separate LUNs would help you to move them around into the pools that are most appropriate for specific requirements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.