For Oracle disaster recovery, check your physical standby databases

What are some of the main tasks IT shops can perform to ensure that their physical standbys will be usable in Oracle disaster recovery (DR), and how should they go about completing them?

Michael Abbey, team lead, Pythian: Think of every possible player that could be involved in a failover to DR. Then repeat exhaustive testing until all activities perform as expected. Touch base with your application owners and co-develop checklists for each. When you think everything is covered, think again and test again. Document procedures and everything required, then pass the documentation on to other people to see how well it can be followed.

Often the actual database failover is the easiest part and, to many, the most familiar. Each and every component in the tiers that interact with one another to make your systems work need attention. Do not take for granted that one, and only one, tier will fail at the same time. Isolate each tier and perform testing, document successes and failures, and hone the process for each individually. Collect information from single-tier tests and finalize each layer's processes based on the test results. Then move onto the more challenging phase where dependencies between the tiers are identified. Once the dependencies are identified, produce an ordered set of steps to ensure portions of the failover are not hindered by work required to be done beforehand.

Use a shared document to ensure nothing gets trumped by somebody else's edits. When you're done testing, make plans to test again within the next 90 days. Take the time to educate the players in the process about all tiers involved in the DR failover activity. Find the time to get all the players up to speed on what others are responsible for. This increases knowledge and awareness of all the processes and routines, which contribute to a favorable outcome in a critical real-life failover to DR.