I’ve just published two new TR’s covering
Oracle Databases on ONTAP:
Database Data Protection: Backup, Recovery, Replication, and DR
Oracle on MetroCluster: Integrated Data Protection, Disaster Recovery, and High Availability
This is all-new material, it’s an expansive topic, but this is the first publishing and as a result I’m sure I’ve overlooked something. I’ll be incorporating feedback over the next month or so and will publish an updated version.
You’ll also notice the first document doesn’t use the word “Oracle”. It’s got a section on Microsoft SQL Server. In case you notice that it’s a comparatively tiny amount of material, that’s because there aren’t all that many options available. It’s easier to explain SQL Server and for the most part you need to use a backup application designed for SQL Server. In contrast, Oracle has a bazillion different methods of implementing data protection.
I’ve also got partially written material that covers MySQL/MariaDB and PostgreSQL and hope to add that in. There’s been a substantial increase in folks looking to move to other platforms in the past year. I know people who have snapshot-based backup, restores, and clones with the open-source RDBMS, but I want to see it documented so nobody has to reinvent the wheel.
In addition, I’ve made some small updates to TR-3633. In particular, there’s a few words about ASM Mirroring. I learned something new – ASM mirroring needs to see an IO failure to switch to an alternate failgroup. The recommended settings for ONTAP LUNs results in a configuration that will never result in an IO failure. It will just wait until an IO completes.
That’s good if you want your operating system to survive storage system failover, FC switch failure, or someone in the data center moving cables around.
It’s not so good if you use ASM mirroring across two sites in a stretched RAC cluster. If you suddenly lose a site, you need ASM to give up on IO and start using the surviving copy of the data. Section 18.4 covers the changes required to make failover work properly.