Recently I made a tweet about a new project with Oracle Engineered System (X9M) that remembered me about what I made with these systems until now. So, this opened the opportunity to tell my background and history until now working with these systems. Is not a show-off of ego boost post.
The Platinum architecture is the last defined at MAA references and is the highest level of protection that you can achieve for MAA. It goes beyond the Gold protection (that I explained in my previous post) and you can have application continuity even version upgrade for your database.
The image above was taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf
The Gold architecture for MAA is used to emphasis the application continuity. All the possible outages (planned or no) are protected by Oracle features. Here we are one step further and start to design using multi-site architecture. Data Guard, RAC, Oracle Clusterware, everything is there. But even with these, ZDLRA is still needed to allow complete protection.
The image above taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf.
With the MAA references, we have the blueprints and highlights how to protect them since the standalone/single instance until the multiple site database. But for Gold we are beyond RPO and RTO, they are important but application continuity and data continuity join to complete the whole picture.
The MAA defined Silver architecture for database environments that use (or need) high availability to survive for outages. The idea is having more than one single instance running, and to do that, it relies on Oracle Clusterware and Engineered Systems to mitigate the single point of failure. But is not just a database that gains with this, the Silver architecture is the first step to have application continuity. And again, ZDLRA is there since the beginning.
As you can see above, the Silver by MAA blueprints improves compared with Bronze architecture that I spoke at the last post. But the basic points are there: RPO and RTO. They continue to base rule here. And the goals are the same: Data Availability, Data Protection, Performance (no impact), Cost (lower cost), and Risk (reduce). More technical details here at the MAA Overview doc.
Oracle Maximum Availability Architecture (MAA) means more than just Data Guard or Golden Gate to survive outages, is related to data protection, data availability, and application continuity. MAA defines four reference architectures that can be used to guide during the deploy/design of your environment, and ZDLRA is there for all architectures.
Image above taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf.
With the MAA references, we have the blueprints and highlights how to protect them since the standalone/single instance until the multiple site database. The MAA goal is to survive an outage but also sustain: Data Availability, Data Protection, Performance (no impact), Cost (lower cost), and Risk (reduce).
The native replication for ZDLRA does not require a lot of maintenance or complicate tasks to keep it running. In my previous posts, I already wrote about an explanation about replication, how to configure the replication network between ZDLRA’s, how to configure the replication server, how to create the replication config (that links everything is done before), and how the replication protect the database. In this post, I will show some details that you need to monitor and to do maintain it running without errors.
The replication for ZDLRA works differently than normal DataGuard, but you can reach almost the same level of multiple site protection with that. The replication for ZDLRA is not complicated but can be divided into several steps. Basically, to protect a database (since you have everything configure) is done linking the database with the protection policy that is replicated.
In my previous posts, I already wrote about all the steps to reach this configuration. Starting with an explanation about replication, how to configure the replication network between ZDLRA’s, how to configure the replication server, and how to create the replication config (that links everything is done before).
But most of the time we don’t need to pass through all of these steps. Usually, the ZDLRA is deployed with the replication network already configured, or you already deploy two ZDLRA’s that will operate replicated. This part I consider the “physical” part of the configuration because evolves network and details that we usually don’t touch after configured. The “logical” part comes after and evolves all the definitions about what policies will be replicated, which databases will be part of each policy, and so on. This “logical” configuration I explained in this previous post.
But it is important to know how it’s working to understand all the details. And if you need, you can check my posts about the replication for ZDLRA.
In this post, I will show more details on how the ZDLRA replication impact over the backup for your database, and show the protection occurs to reduce your RPO to a minimum.
The replication from ZDLRA is easy to configure and operate. Most of complex part resides for policy management and define correctly what will be replicated. I already wrote about the basics for ZDLRA Replication in this post, and how to configure the dedicated network for replication in another post.
But also wrote how to startup and configure the replication server in another post. This is the first step and needs to be done before what I will describe in this post, they are the “physical” configuration. Here I will show the “logical” configuration for native ZDLRA replication and how correctly define it to avoid problems.
The replication for ZDLRA operates in several ways, from a single upstream/downstream config to a multiple replication config, but both are done using the same procedure. The process is not complicated but has some details that are needed to be aware to avoid reconstruct (or even loss) replicated data. In this post, I will show the details to create the replication config.
The base about how the replication works for ZDLRA I wrote in this post. And how to configure the replication network config in this other post. This network configuration needs to be done just when you are adding the replication after the ZDLRA has been deployed, if you already deployed with replication enabled it is not needed. The official documentation about replication can be found here.
Is common that our systems grow with time, and the environment that sustains it needs to improve. And the same occurs for ZDLRA. Imagine that now you added a new datacenter and bought a new ZDLRA and want to replicate between them, or that now you want to enable the replication, configuring it.
This is possible and is not complicated to do, and I will show here how to do that. So, in this post, I will show how to configure the replication network for ZDLRA that was already deployed. Basically a post-install procedure.