Now that RAC is no longer available for SE2 users as of 19c, how do you deploy disaster recovery for Oracle Standard Edition?
After all, disaster recovery is a business essential – this is especially important when it comes to your database.
Whether it’s an IT failure, cyber attack, or even a more natural disaster such as a fire or flood – failing to put in place a sufficient database disaster recovery provision is an existential threat waiting to unfold.
But when it comes to database disaster recovery for Oracle Standard Edition (SE), you’ll find your organisation faced with a very limited pool of options – unless you’re willing to stump up the investment for an Enterprise Edition (EE) license.
So, what are these options?
Options for Deploying Disaster Recovery for Oracle Standard Edition
1) Manual Scripts
Scripts are a useful way to ensure that your production environment is kept in sync with a standby database. This means that, should your database fail, or suffer downtime, you can failover to your standby server which mirrors your main production database.
However, be cautionary with using manual scripts.
Doing so places an increased reliance on the person writing the scripts so, should they leave, your entire DR provision could be at risk.
2) RMAN (Oracle Recovery Manager)
RMAN, or Recovery Manager for short, is the standard backup and recovery method included with both Oracle Standard Edition (SE2) and Enterprise Edition (EE).
Whatever disaster recovery arrangement you use; you should always be using RMAN for the initial backup procedure. A manual process, RMAN makes backups of an Oracle database and stores them in a repository on the database.
The obvious shortcoming here is that the backup is stored on-site, on the same server. So, if the server itself suffers downtime, your RMAN backup will too. To avoid this happening, and to prevent a single-point of failure, you must ensure that any RMAN backups are being copied securely in an off-site location. You must also ensure that you have the means to restore the data as soon as possible – ie. provisioning a new server, with the relevant software installed.
The optimal way to use RMAN, is to use it in conjunction with a separate procedure. This can either be with manual scripting, to ensure that the backup remains in sync with a standby. Or, through a third party option such as DBVisit Standby.
3) DBVisit Standby in conjunction with Oracle Cloud
DBVisit StandbyTM is Xynomix’s 3rd party disaster recovery option of choice. Favoured for its speed, automation features, integrity, and simplicity – DBVisit Standby offers the best of all the 3rd party solutions on the market.
Built with Oracle Standard Edition in mind, DBVisit is compatible with all SE1 and SE2, and mirrors Oracle best practices in order to guarantee long-term support.
Standby works in conjunction with Oracle Cloud, allowing DBAs to set up a standby environment in an off-site location and therefore adding an extra layer of resilience. With just a click (or an automated script), you can failover in a matter of minutes.
So, if testing goes awry – or your production database goes down for whatever reason, you can simply failover to the Standby version in the cloud (automatically mirroring your production environment) and continue seamlessly.
4) Upgrade to Enterprise Edition for RAC* and DataGuard
It is nonetheless still worth mentioning the benefits of upgrading your Oracle licensing to Enterprise Edition.
For a start, you’ll have access to Real Application Clustering (RAC) – an incredibly useful high availability (HA) measure that can help prevent you needing to use your disaster recovery environment in the first place.
Meanwhile, Data Guard remains a stalwart option for Oracle users. It boasts a variety of protection modes which, like all good things, comes in threes:
Maximum Protection – Guarantees zero data loss if the primary production database fails.
Maximum Availability – Guarantees extremely high level of data protection, whilst ensuring that availability of the primary production database remains unaffected.
Maximum Performance – Guarantees the highest possible level of data protection, whilst accounting for performance levels. Requires sufficient bandwidth & latency for maximum efficiency.
*RAC is unavailable on Oracle Standard Edition from Version 19C onwards
Conclusion
Disaster recovery isn’t just implementing a single technology. Nor is it about finding a quick-fix solution.
Disaster recovery planning for Oracle SE is about identifying the wider strategic factors for your organisation – including your required RTOs/RPOs.
Still unsure about how vital database disaster recovery is? Ask yourself the following question: If the database goes down, can my business continue to operate?
In 99% of cases, the answer will be no.
And that reason alone is reason enough to examine your options when it comes to disaster recovery, whether you’re on Oracle, SQL Server, or any other DBMS.
