The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Introduction

Some time ago I wrote a blog about stretched clusters and the OCR. The final conclusion at that time was that there was no easy way to get your OCR safe on both storages, and hence I disrecommended clusters with 2 storage boxes. However, after some more investigation I may have to change my mind. I did extended testing on the OCR and in this blog I want to share my experiences.

This is the setup:

• 2-node RAC cluster (10.2.0.4 on Solaris), located in 2 server rooms
• 2 storage boxes, one in each server room
• ASM mirroring of all data (diskgroups with normal redudancy)
• One voting disk on one storage box, 2nd voting disk on the other box, 3rd voting disk on nfs on a server in a 3rd location (outside the 2 server rooms)

For the components above, this setup is safe against server room failure:

• The data is mirrored in ASM and will remain available on the other box.
• The cluster can continue because it still sees 2 voting disks (one in the surviving server room and one on nfs).

But what about the OCR?

We did as what looks logical: OCR on storage box 1 and OCRmirror on storage box 2, resulting in:

         Device/File Name         : /dev/oracle/ocr
                                    Device/File integrity check succeeded
         Device/File Name         : /dev/oracle/ocrmirror
                                    Device/File integrity check succeeded

Now we can start playing. For the unattended reader, “playing” means: closing ports on the fibre switches in such a way that a storage box becomes totally unavailable to the servers. This simulates a storage box failure.

The result is a story of 5 chapters and a conclusion. Please standby for the next upcoming blog posts.