Enterprise-class Disaster Recovery for Oracle SE that prioritizes database integrity, disaster resiliency, recovery speed, and ease of use.
"They tell me they are planning to use manual scripting." This was the response I got recently while speaking to one of our partners. I had asked him to describe some of the typical obstacles that he encountered when trying to introduce Dbvisit Standby as a disaster recovery and business continuity solution for his clients that are also Oracle Standard Edition database users.
His feedback highlights a tricky problem many of us have run into. Experience tells you and I that implementing manual scripting for something as critical as disaster recovery may end up being like buying yourself a gift that keeps on giving. And by giving I mean giving you problems; consistently, regularly, endlessly...a challenging project that holds great appeal to a valiant DBA can quickly turn into an unwieldy beast (no one wants to end up like this).
But how do you help your client determine which is better - a cost effective third party DR tool or the manual scripting they are already using? Running through these nine simple checks will soon make it clear if the current solution is adequate.
1. Comprehensiveness
How will you ensure that it will work when you want it to? The obvious answer is that it's been tested. Well, has it?
2. Confidence
Are you confident this solution is working? Like data from the primary is being pushed to the standby right now? Don't be left guessing whether the refresh process on both source and target are working properly.
3. Compression
What impact will maintaining a standby database for DR purposes have on the network? Bandwidth requirements should be as minimal as possible. Does your solution have compression capabilities?
4. Security
Is it secure? Are you having to open up extra ports on the firewall and increase exposure to your system and data?
5. Documentation
Does it have complete documentation? You want to make sure that you can still take holidays!
6. Ongoing Validity
Who is responsible for ensuring your solution is kept current with the latest Oracle changes, patches and upgrades?
7. Complexity
Can it support complex Oracle configurations such as ASM and RAC?
8. Failback
Is there capability to reinstate the primary database? It is important to ensure that the solution capabilities extend beyond the failover.
9. Optimized Efficiencies
Have additional scripts been factored in to support the updating of multiple standby (secondary) servers? This way you can keep your development, test, training and reporting databases updated with data from the primary.
If your client's current solution fails to pass all of these essential checkpoints there is an opportunity to improve their DR preparedness with a solution that does tick all of the boxes.
Are there any other critical checkpoints you would include?
