ASM best configuration disks on EMC storage in RAC

Question

After reading ASM best practices, suggesting to use a disk group for all datafiles and a disk group for FRA I was wondering how to optimize I/O on storage.
I mean.. what about if I add also a disk group for the redologs of the two RAC instances?
Moreover... what are the best practices to use the several disks offered by the storage compared with the possibility to use different LUN on the same big disk of of the storage?
Example...
My storage has 2 disks of about 2TB each one:
1) I could partition one disk into two LUN and use this two LUN for the DG_DATA and DG_FRA asm disk groups. Every LUN should be partitioned in small units.
2) I could use two disks and use one disk for DG_DATA asm disk group and the other for DG_FRA asm disk group.
3) I could use two disk partitioned in two LUN (and so I have 4 LUN). Add to the DG_DATA disk group the LUN partitions physically based on two different disks, and the others two LUN for the DG_FRA disk group.
Hope you can solve my doubts,
thanks Marco

Answer 1

Here's a brief comment ....
There is not one answer that fits all. This is because it all depends on your SAN env and the storage architecture. Some configs are good for a system but disastrous for another.
Also, we must make a clear distinction between the terms LUNs vs. disks. Because DBA interact with storage at the host level, we use them synonymously which is understandable. However, for SAN and storage, they should not be and they are not.
These are some of the guidelines I learned ...
1) use small spindles with highest RPM for your disk arrays. Rarely we have control over that, but DBAs should at least understand and obtain these specs from SAN admins.
2) Understand your system's potential bottlenecks and load balance around them. For example, I've seen systems bottleneck at the HBA, DA, spindle, or even host level. This where you need to take caution when you layout DB storage. You do not want 2 IO intensive apps accessing same LUNs on same controller whereas the 2nd one remains semi-idle. Most systems should auto balance them, but at least these apps primary or preferred access path should be separated.
3) Use expected DB size to decide on your LUN size. You can not layout a TB database using 12GB LUNS nor can you use a 500GB LUN to layout a 50GB DB.
4) For most storage systems now, data separation occurs as a result of data protection, management convenience and to a lesser extent for performance reasons or IO type (random vs. sequential). Again, the accuracy of this statement varies from one system to another, but at least this is the trend.
5) always always, measure you IO metrics. There are simple, yet effective measures you or (SAN admin) can do to measure IP performance. Use metrics like service times and latency measures. Also, most application have typical IO profiles like PIO/sec, sequential vs. random reads.
6) On some systems, I have seen DBAs request LUNs carved from RAID10 arrays for redo logs and RAID5 for the remainder of the database, You can certainly exercise this option.
Hope this helps
Thank you