Maximum Availability Architecture – Oracle’s industry-leading set of database high availability capabilities

The Evolution of Maximum Availability Architecture (MAA)

Saurav Das
Principal Product Manager

I hope everyone had a great time attending OOW 19. It was a great experience for me to meet so many customers at the MAA demo booth and talking to them about MAA. From these discussions, the most obvious realization for me has been how much MAA has evolved over the years and how much our customers appreciate it.

The Maximum Availability Architecture (MAA) was initially published for our customers to use them as blueprints, best practices, and solutions. For on-premises infrastructure or generic systems, customers had to implement MAA themselves. Over time, Oracle released Engineered Systems such as Exadata Database Machine, Zero Data Loss Recovery Appliance (ZDLRA) and Database Appliance (ODA), which were designed keeping in mind the validated MAA best practices and blueprints. As part of this evolution, customers still had some partial ownership of their environment while Engineered Systems optimized the high availability from the infrastructure point of view, expanding high availability by including built-in features such as fully automated network and storage failover, to supplement the rest of the MAA solution. With the recent introduction of Oracle Cloud Database Services and Oracle Autonomous Database, the ownership has shifted more onto Oracle for day to day lifecycle operations to ensure that customer environments are MAA compliant.

See the picture below.

However, MAA has evolved in other ways too and all of this was possible through key enhancements delivered for the Oracle Database and for applications running on it. To understand this evolution, let us take a look at some of these key features which are part of MAA and Oracle’s continuous delivery of high availability features for customer environments hosted On-premise or on the Cloud.

Oracle Database

Some of the key features and enhancements delivered to the Oracle database are as below:

  1. Online Reorganization or Redefinition – Customers frequently make changes to the logical and physical structures of a table, partition or datafile, etc. Such operations would normally impact the availability of the database causing concurrent DML and DDL operations to fail. Online data and schema reorganization is a classic feature that enables customers to do so using the ONLINE keyword, Oracle Enterprise Manager Cloud Control or DBMS_REDEFINITION package. This allows customers to accommodate application changes without any downtime. Moreover, the feature is fault-tolerant and can be resumed or rolled back easily.

  2. Flashback – Another classic feature which allows customers to rollback changes without involving any complex recovery procedures. Flashback can be performed at different levels ranging from the query, transaction, table or the entire database. It provides an additional level of data protection with point-in-time-recovery which enables an efficient and less disruptive rollback to the previous state.

  3. Corruption detection and repair – Database Corruption is often one of the most impactful events for a customer which can have catastrophic effects both internally and externally if not detected and repaired quickly. The Oracle Database is efficient at managing both physical and logical corruptions when they occur. Automatic Storage Management (ASM) and Active Data Guard (ADG) automatically detect and repair corrupted blocks without any human intervention.

  4. Multitenant – Often considered one of the marquee features of the 12c release, Multitenancy enables in-database virtualization through the creation of single or multiple pluggable databases (PDBs) all attached to a single container database (CDB). This is a great option for large enterprises looking to consolidate their fleet of databases. The major benefits include reduced hardware cost, easier management, lesser databases to patch or upgrade along with fine-grained control for each PDB.

  5. Compute Scale-Out and Automatic Storage Management (ASM) - The Oracle Real Application Clusters (RAC) option provides customers the ability to linearly scale compute by running multiple instances across different servers that access the same physical database stored on shared storage. Oracle Automatic Storage Management (ASM) is the recommended shared storage option (for both Oracle RAC and single-instance Oracle Databases) that simplifies storage management. These are the only options on the market that provide capabilities such as linear scalability, storage redundancy, fault tolerance, corruption repair, etc. and many other features without requiring any application changes.

  6. Automatic Restart and Clustering – Oracle Restart provides additional protection by monitoring and automatically restarting components after a hardware or software failure for customers running a single-instance database. The same functionality for RAC environments is provided by Oracle Clusterware transforming a server farm into a cluster. Oracle Clusterware also provides node membership, node fencing and optimal resource placement for Oracle RAC environments. Oracle Restart/Clusterware along with Oracle ASM together form the Oracle Grid Infrastructure (GI) which provides a common binaries location (Oracle Home) out of which all software runs.  The GI allows for easier management of daily database tasks and maintenance.

Each of these products and features listed above received many new enhancements and for more details refer to the New Features Guide for 18c and 19c.


MAA is not limited to database high availability and disaster recovery capabilities but extends up to the application as well to minimize and in some cases completely eliminate downtime whether unexpected or planned.   Key features and enhancements that extend high availability and minimize the impact on the application tier include the following:

  1. Continuous AvailabilityApplication Continuity (AC), released in 12c, helps mask database outages from the application by draining sessions and caching failed transactions on the impacted node, reconnecting the application to another node (RAC environment) and replaying the transaction. The whole event seems like a delayed execution for the application consequently ensuring continuous availability for the end-user. Transparent Application Continuity (TAC), released in 19c, does this transparently by tracking and recording database sessions automatically without any need for application code changes.

  2. Zero Downtime Patching – Mission-critical applications which require continuous availability cannot afford any downtime during patching. The Oracle Database provides a way to achieve zero downtime patching for applications via the Oracle RAC Rolling Patching feature or Fleet Patching and Provisioning (FPP). Oracle RAC Rolling Patching allows patching of Oracle RAC nodes in a rolling fashion, maintaining database and application availability with direct integration with the Application Continuity feature. FPP is a feature of the Oracle Grid Infrastructure (GI) which simplifies patching across large scale deployments and ensures standardization across a fleet of databases via gold imaging and orchestration.

  3. Zero Downtime Upgrades – Similar to zero downtime patching, customers also desire online upgrades (zero downtime upgrades) for their mission-critical applications. Oracle Edition Based Redefinition (EBR) feature allows an online upgrade of the application with uninterrupted availability for the application. EBR uses the built-in Editions feature of the Oracle Database in order to maintain two editions of the database available for the application to connect to during and after the upgrade. This allows the older edition to continue to service the application while table changes and possibly other schema changes are made to the new edition.  A cross-edition trigger ensures that the new edition is kept in sync with the older version and simplifies transition when ready.  EBR can be utilized in custom applications and is routinely used internally by Oracle Applications Cloud, Oracle Enterprise Manager Cloud Control, and E-Business Suite as part of their core infrastructure to provide Zero Downtime Upgrades.

  4. Workload Offloading – The earlier version of the Oracle Data Guard provided disaster protection and recovery for customers by replicating redo data to a standby database. With Active Data Guard (ADG), customers can now offload most of their read-only reporting applications, ad-hoc queries, data extracts, etc., to a replicated physical standby database simultaneously providing disaster protection thereby eliminating the cost of idle redundancy. As part of 19c for reporting applications, Active Data Guard allows DML operations (occasional updates) on a “read-mostly” standby to be redirected to the primary database.

  5. Heterogenous Active Replication – In contrast to Oracle Data Guard which allows for only one-way physical replication, Oracle GoldenGate is a feature-rich logical replication product with advanced features that can supplement Active Data Guard, providing customers flexible options to fully address their replication requirements. GoldenGate also supports replication between a broad range of heterogeneous hardware platforms – e.g. Linux, Solaris, Windows, etc. and database management systems – Oracle, DB2, SQL Server, etc. The heterogeneous replication supports platform migrations, technology refreshes, database upgrades, and application upgrades that change back-end database objects, with minimal or zero downtime.

  6. Distributed Database and Fault Isolation - Oracle Sharding distributes and replicates data across a pool of discrete Oracle databases referred to as shards. Sharding is built on a shared-nothing horizontal partitioning architecture in which the databases do not share storage or rely on cluster software. Oracle Sharding provides a number of benefits for web-scale applications such as linear scalability, extreme data availability and geographic data distribution allowing data sovereignty and data proximity.

The above list of features and capabilities is not by any means a complete list, and of course, there are many additional high availability features that have not been mentioned here. Please add a comment if you wish to provide feedback on any high availability features you use currently that have not been mentioned here. Additionally, also refer to our MAA whitepaper for Oracle Database 19c here.

In our next series of blog posts, I will continue the discussion on the evolution of MAA by expanding into the solution provided via Engineered Systems (Exadata, ZDLRA, and ODA) and Oracle Cloud Database Services (Database Cloud, Exadata Cloud, and the Autonomous Database). Stay tuned! Until then, if you need more information, please visit our Maximum Availability Architecture page.

You can also follow us on Twitter at @OracleMAA for new updates.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.