<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4768124&amp;fmt=gif">
Blog

Disaster Recovery for Oracle SE on AWS

So you're thinking about how to create a resilient architecture for your Oracle Standard Edition databases in AWS. While there are plenty of native capabilities within AWS for Oracle Enterprise Edition, this article will demystify how to create a resilient architecture for Oracle Standard Edition by implementing a standby database.

AWS database disaster recovery
TECHNICAL PIECES
https://dbvisit-7632844.hs-sites.com/blog/tag/oracle-data-recovery-advisor
ORACLE
https://dbvisit-7632844.hs-sites.com/blog/tag/oracle-data-recovery-advisor
AWS
https://dbvisit-7632844.hs-sites.com/blog/tag/oracle-data-recovery-advisor
CLOUD
https://dbvisit-7632844.hs-sites.com/blog/tag/oracle-data-recovery-advisor
By Neil Barton |
October 31, 2022 |
Link Clicked!

Why AWS?

AWS has the largest market share of all cloud providers, making it a common environment for companies to deploy their computing infrastructure. Companies moving from on-premises deployments can move to either (1) Database as a Service (DBaaS) using AWS RDS, or (2) Infrastructure as a Service (IaaS) using AWS EC2, along with many other service offerings that come with the AWS ecosystem. 


Why you still need Disaster Recovery (DR) in AWS

A business critical database on Oracle Standard Edition (SE) is typically required to have high uptime, fast recovery (RTO) with minimal data loss (RPO) from any outage, and be resilient to all disaster types. This includes natural disasters, internet disruptions, user errors, power cuts, data corruption, and hardware failures.  

While AWS aims for their infrastructure to achieve a 99.5% uptime with single instance deployments, this does not mean your database will be available 99.5% of the time. Why?

  • User error or internal actors: a user may misconfigure a service or delete a table rendering your database unavailable while the infrastructure is up.

  • Internet disruptions: internet backbone issues, such as damaged cables, have put entire regions out of action or significantly degraded performance for days even though the infrastructure is up. 

  • Natural disasters: although less common, cloud hardware is still affected by natural disasters. The 2022 heatwave in Europe took Oracle and Google’s data centers offline for more than 18 hours.

So the unfortunate truth is that without Disaster Recovery (DR) your databases are not resilient and you won’t meet your RPO and RTO requirements, even in the cloud. 


The importance of understanding Regions and Availability Zones

When deploying with AWS there are two core aspects for selecting where and how to deploy - Regions and Availability Zones.

  • Regions: each AWS Region is in a geographical area that's independent and separated by vast distances—across countries or even continents, from all the other regions. You can deploy applications in different regions to mitigate the risk of region-wide events, such as large weather systems and earthquakes. Each region can include multiple availability zones (AZs).

  • Availability Zones: an independent data center or set of data centers within a region. Each region has multiple availability zones connected by high bandwidth low latency networks.


AWS - Multi-Region Best Practice

For organizations with short RTO/RPO needs, AWS recommends deploying a standby environment in a separate region to mitigate a complete region outage.

RTO RPO AWS graphic - Disaster Recovery Options in the Cloud

AWS: Disaster Recovery Options in the Cloud

For Oracle SE deployments on AWS, there is currently no supported option for an out-of-region standby on RDS.  However RDS Custom, which supports Oracle SE since April 2024, does enable the creation of warm Standby Databases on Oracle SE using Dbvisit StandbyMP.  This means that out of region standby databases can now be created on both AWS DbaaS (RDS Custom) and IaaS (EC2) environments.  


Resiliency Options in AWS RDS (DBaaS)

For Oracle SE, AWS RDS native capabilities for creating a more resilient environment include RDS automated backups, DB snapshots and Multi-AZ deployments. Each provides resiliency aspects, however, they do not protect against all disaster scenarios and recovery times may breach RTO requirements. 

Automated Backups: RDS performs a full daily backup, within a customer-specified backup window.  This backup enables point-in-time recovery. This feature is turned on by default and provides a retention period of up to 35 days.

DB Snapshots: these are user-initiated full database backups and are kept by Amazon RDS until explicitly deleted.  

Multiple Availability Zones (Multi-AZ): RDS supports multi-AZ deployments, where the database is synchronized across multiple AWS data centers within a single region. This provides high availability in the event of a data center outage. However, since multi-AZ deployments are within a single region, it does not provide resiliency in the event of a region outage.

Additionally, Multi-AZ deployments will likely require a separate Oracle license for the additional standby instance. If you are required to purchase additional Oracle licenses then the most effective approach for resiliency is to deploy the DR environment within a separate region. This is not currently available for Oracle SE deployments on RDS.


Resiliency Options in AWS RDS Custom (DBaaS)

RDS Custom delivers the Resiliency functionality of AWS RDS, but also enables the installation of additional third party tools that can deliver additional resiliency. 

Create Out of Region Standby Databases:  Utilise Dbvisit StandbyMP to create and maintain an out of region standby database.  The warm standby database provides protection against human error, regional outages, and data corruption / internal actor scenarios using point in time recovery.   The out of region standby can be used to complement Multi-AZ or as an alternative depending on your requirements. 


Resiliency Options in AWS IaaS (EC2)

Just like on-premises, it's actually possible to easily create and manage a high-performance, resilient Oracle SE environment using Amazon’s EC2.  You can even create out-of-region standby databases using a third-party tool such as Dbvisit StandyMP. 

Backup: you can leverage standard Oracle RMAN utility for database backup or also leverage AWS native storage capabilities to take backups.

High Availability: Oracle SE customers can use paid third-party products VMWare and Flashgrid to create a Multi-AZ high availability environment based on Standard Edition High Availability (SE2HA). (Read about the difference between SE2HA and RAC in our blog) Importantly, within region High Availability is not a standby database replacement because it is vulnerable to regional outages.

Disaster Recovery with a Standby Database: while Oracle Enterprise Edition (EE) customers can leverage Multi-AZ deployments or highly resilient multi-region deployments with Data Guard, Oracle SE customers do not have access to this technology.  

Oracle SE customers can use Dbvisit StandbyMP to create and manage highly resilient standby databases across regions to create a highly resilient, high-performance database architecture. 


The Case for an Out of Region Standby Database

To ensure maximum resiliency in the event of a disaster, AWS recommends deploying a warm standby database in a separate AWS Region. By having the standby database in a separate region, companies can protect themselves against even regional outages, achieve an excellent RPO/RTO, and thereby achieve a highly resilient and high-performance DR strategy.

AWS Cloud - Dbvisit Gold Standard DR on AWS

AWS: Disaster Recovery Options in the Cloud


What is Gold Standard Disaster Recovery?

In today’s modern data-driven world, a DR strategy must ensure business continuity, no matter what type of event strikes the organization. A well-rounded DR strategy - what we call Gold Standard DR - encompasses much more than just the recovery aspects.

  • DR testing to ensure that all systems can successfully be recovered.

  • Continual verification of the standby database, to ensure the database will successfully failover when needed.

  • Planned switchover and rollback, to accommodate rolling upgrades, etc.

  • Automation of repeatable processes, to ensure consistency and reliability.

  • Monitoring and notifications, so that administrators are notified when events occur that require attention.

  • Fast troubleshooting tools.


What's next?


  • Learn more about Standby MultiPlatform in our datasheet and feature sheet.

  • Read our cloud white paper discussing cloud myths and the importance of an out-of-region DR site. 

  • Download and trial the product on-premises or in the cloud, or take it for a Test Drive in a two-hour environment.

If you have any questions at all or would like to see a demo of the software, you can contact us and we will be in touch! 

Contact us

 

 

Neil Barton
Neil Barton

Email Neil Barton

Subscribe to our monthly blog updates

By subscribing, you are agreeing to have your personal information managed in accordance with the terms of DBVisit's Privacy Policy


Link Clicked!
Try StandbyMP for free

See for yourself how our continuous database protection can help keep your world in motion.

Find a local partner

We work with partners around the world to give you the best advice and world-class local support.

Mask Group 59
Mask Group 184-1
get a price2
get a price2
Get Pricing

With Dbvisit's StandbyMP software, Gold Standard Disaster Recovery doesn't have to be difficult or expensive. Get an instant quote now.