Category Archives: ZDLRA

Category about Zero Data Loss Recovery Appliance (ZDLRA). List of related posts.

MAA, Blueprints and On-Premise Architecture Reference

1 Reply

The Oracle Maximum Availability Architecture (MAA) is the correct way to protect your Oracle database environment (and investment). It covers from a simple single instance to Exadata/Engineered Systems RAC and a multi-site database with Data Guard protection. But do you know that to reach the MAA (whatever the architecture level that you are protecting) you need to use ZDLRA?

So, I will start a series of posts to cover the MAA and ZDLRA. Discussing what you need to do (and how) to reach the maximum level of availability as is at the MAA architecture (as defined in the documentation and best practices: Oracle Maximum Availability Architecture (MAA) Blueprints for On-Premises,  MAA Best Practices – Oracle Database, and Maximum Availability with Oracle Database 19c).

Why ZDLRA?

The question is why ZDLRA is needed? The point from ZDLRA is that it can (and needed to be used) to protect and reach zero RPO to all architectures. ZDLRA is more (much more) than just a backup appliance, is the core of every MAA design. You can’t reach zero RPO without using it.

Click here to read more…

ZDLRA, How to Maintain the Native Replication

Leave a reply

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.

Click here to read more…

ZDLRA, Protecting Databases with Replication

Leave a reply

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.

Click here to read more…

ZDLRA, Creating the Replication Config

Leave a reply

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.

Click here to read more…

ZDLRA, Creating the Replication Server

Leave a reply

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.

Click here to read more…

ZDLRA, Configuring Replication Network

1 Reply

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.

Click here to read more…

ZDLRA, Replication

6 Replies

The replication for ZDRLA works differently than a “normal” for Oracle Database that uses Data Guard (or even Golden Gate). The point is to replicate the ingested backup “as is” between ZDLRA’s and not datafile block replication. And, of course, it is completely different from tape clones.

ZDLRA replication is not just sent backup from one site to another, it is how to increase your protection and be part of the disaster recovery strategy. The replication does not occur just for “rman backups”, but also for archivelogs generated for Real-Time Redo. And adding, this is how you integrate ZDLRA at your MAA architecture that makes the difference and how you protect your environment and reach zero RPO. There are several points about replication, how it operates, modes, and integration for Oracle MAA universe. I will discuss some points here in this post.

The architecture

The architecture for ZDLRA replication it is simple. There are two important definitions:

  • Upstream: It is the ZDLRA that receives the backup and forward it to another ZDLRA
  • Downstream: Is the ZDLRA that receives the backup from another ZDLRA

Click here to read more…

ZDLRA, ORDERING_WAIT task state

Leave a reply

Tasks for ZDLRA are the pillar of how the backups are processed, everything is one task. So, when you ingest incremental backup one task is created but can occur that it get a freeze at ORDERING_WAIT state. These tasks are hard to identify and can create a big problem for your virtual full backup and backup strategy. Below I will show how they occur and how to solve the problem.

Click here to read more…

ZDLRA, Patch/Update the Recovery Appliance

1 Reply

The process of patch ZDLRA is not complicated, but it is important to be aware of some details. The most important is from where you are until where you want to go. This is crucial because it will define what commands you will need to execute.

If you read the previous post about the process, you can notice that I was running the ZDLRA 12.2 version, and forwarded to 19.2 version. In that case, I needed to use the upgrade path since I was changing the major release and the racli commands had the “upgrade” parameter.

In this post I will show how to do a simple update (or patch apply) for ZDLRA, this means that I will remain inside the same major release for recovery appliance library. Some steps and checks are the same.

Whatever you need to do (patch or upgrade), the startup point it is the note 1927416.1 that cover the supported versions for ZDLRA. There it is possible to find all the supported versions for the recovery appliance library as well as the Exadata versions. Please, not upgrade the Exadata stack with a version that is not listed on this page.

Click here to read more…

Exadata and ZDLRA, Patch Exadata Stack

4 Replies

The process to patch Exadata stack and software changed in the last years and it became easier. Now, with patchmgr to be used for all (database servers, storage cells, and switches) the process is much easier to control the steps. Here I will show the steps that are involved in this process.

Independent if it is ZDLRA or Exadata, the process for Engineering System is the same. So, this post can be used as a guide for the Exadata patch apply as well. In 2018 I already made a similar process about how to patch/upgrade Exadata to 18c (you can access here) and even made a partial/incomplete post for 12c in 2015.

The process will be very similar and can be done in rolling and non-rolling mode. In the first, the services continue to run and you don’t need to shutdown databases, but will take more time because the patchmgr applies server by server. At the second, you need to shutdown the entire GI and the patch is applied in parallel and will be faster.

Click here to read more…