Anyone have some suggestions for disk layout to support Oracle RAC ASM diskgroups, keeping in mind scalability?

[LOWERI444]

Anyone have some suggestions for disk layout to support Oracle RAC ASM diskgroups, keeping in mind scalability?

We are looking at setting up 5-6 Oracle ASM disk groups to support a single database and NetApp SMO requirements.

• Diskgroup1-DATA
• Diskgroup2-RedoLogs
• Diskgroup3-Temp
• Diskgroup4-FRA\ArchiveLogs
• Diskgroup5-OCR\VotingDisk

Each diskgroup will contain 2-3 LUNs in one single volume with each diskgroup tied to their own single volume. In other words, 5-6 ASM diskgroup volumes, each with 2-3 LUNs.

So my thought is, that this approach doesn't scale well. When a 2nd database is added to the Oracle RAC ASM instance, the ASM diskgroup requirement almost doubles. This is in order to support NetApp SMO.

When a third database is added the diskgroup requirement almost triples, and so on.

Am I wrong here? or is there another approach that NetApp recommends?

I've already looked at the various best practices docs and installation guides.

Rick

[RAVI_PALADUGU]

Please use the attached guide for reference.

Best Regards,

Ravi

[LOWERI444]

Thanks.

I've seen some of these documents, and the recommendations and guidelines have been helpful, but I have yet to see anything that provides a definitive answer with regards to my question on scalability. Specifically, with the having to create additional Oracle ASM disk groups as new databases are added. Seems like a DBA and storage management headache.

[LOWERI444]

Okay, I guess I'm seeing some conflicting information. I was under the impression that having multiple databases in a single ASM diskgroup volume would be problematic during restore activities due to either having to restore the entire volume and\or the overhead costs of doing more granular restores. But it seems NetApp Snap Manager for Oracle may have solved the issue. Found this below.....

From TR-3633

In an ASM configuration, an ASM disk group can be shared by multiple databases. As a result, you cannot simply revert to an older Snapshot copy of the disk group, because it would revert all the databases. Traditional restore solutions would go through the host and would require that all the blocks that constitute the database be moved from the storage system to the host and then back to the storage system. The unique solution provided by SnapManager from Oracle relieves this overhead. SnapManager provides the ability to restore just the required data within the ASM disk group without going through the host for most scenarios