Category Archives: Restore

Duplicate, Restore and ZDLRA

From time to time we need to clone/duplicate some databases and we have several ways to do that, most common are duplicate and restore (with a new name) commands. But when using RMAN catalogs we need to take extra care because we can up lose the backups of the entire database because of the wrong way to do that. And this is even more crucial when using ZDLRA.

You need to choose between The Good and The Bad. Because if you choose wrong you will have troubles with The Ugly. The key factor here is the RMAN/ZDLRA catalog, choose wrong and you will automatically add bad data in the internal catalog tables and if you will try to clean, can delete database backups.

In this post, I will show how correctly clone one database when you are using the RMAN/ZDLRA catalog and the reasons for that. I will show the problems and the collateral effects for ZDLRA when you choose the bad way.

Click here to read more…

ZDLRA + MAA, Protection for Platinum Architecture

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

Click here to read more…

ZDLRA + MAA, Protection for Gold Architecture

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.

Click here to read more…

ZDLRA + MAA, Protection for Silver Architecture

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.

Click here to read more…

ZDLRA + MAA, Protection for Bronze Architecture

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).

Click here to read more…

RMAN, Allocate channel, CDB, and CLOSE: bug

Allocate channel for RMAN is used in various scenarios, most of the time is useful when you use tape as device type or you need to use some kind of format. The way to do the allocation not changed since a long time ago, but when you run the database in container mode you can hit a bug that turns your channel unusable. I will show you the bug and how to avoid it with a simple trick.

This bug hit every version since 12 and I discovered it last year when testing some scenarios, but I was able to test and post just recently. It just occurs for CDB databases and exists just one one-off solution published for 12.2. But there is one workaround more useful and works for every version.

The most interesting part is that everything that we made until now when allocate channel will not work. You can search in all doc available for allocate channel since 9i until 19c the first thing that you made after open the run{} is allocate channel. This is the default and recommended in the docs: for 19c, 18c, and 9i.

More…

Oracle e MAA – Artigo III – Reinstate

Após fazer o failover no artigo anterior você precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate é recuperar o banco para que assuma a nova função.

No mundo real as falhas que podem deixar seu ambiente primary fora e forçar o failover para o standby são diversas. Muitas vezes perde-se o ambiente por completo e precisamos recriar o primary, quando acontece isso a solução é recriar o ambiente e adicionar o banco ao DG. Aqui, o antigo primary teve a sua falha corrigida e ele foi religado. Se no caso você perdeu completamente o antigo primary não há o que fazer, você precisará recriar ele através de um backup do novo primary.

TERCEIRO ARTIGO

Neste artigo irei demonstrar como fazer o reinstate manual do antigo primary. Além disso, também demonstrarei como adicionar este banco como standby ao ambiente para que possamos a ter um ambiente MAA. Como este artigo é uma sequência dos anteriores eu recomendo a leitura dos anteriores para ficar familiarizado, não é obrigatório mas pode ajudar.

Continue lendo…

Oracle e MAA – Artigo I

Este artigo é o primeiro de uma série sobre Maximum Availability Architecture (MAA), com os passos, dicas e afins para configurar e manter um ambiente deste porte. No final da série teremos um ambiente com Oracle RAC tanto no primary quanto no standby. Ambos sincronizados com Data Guard (DG) rodando em alta disponibilidade.

Não é a intenção aqui mostrar com configurar um ambiente RAC, já partirei de um ambiente com o RAC instalado e um banco rodando. Utilizarei o Oracle 11GR2 versão 11.2.0.3, já que a intenção também é mostrar como atualizar um ambiente em DG. Além disso, tentarei cobrir alguns pontos como “real-time apply” e criação do banco standby usando Media Management Layer (MML).

Tentarei ser o mais didático e claro possível e caso tenha alguma dúvida, pergunte. Todos os comandos que executei estarão no artigo. Infelizmente este primeiro artigo será extenso (muito) e cheio de detalhes técnicos, não tem como montar um ambiente assim de forma rápida e sem os diversos detalhes envolvidos. Infelizmente não existe um guia rápido de 10 passos para MAA com RAC, isso não existe. Você verá aqui um guia detalhado do início ao fim sobre como configurar MAA com RAC em ambos os lados.

Provavelmente alguns passos utilizados aqui para a configuração do ambiente podem ser mais simples na prática. Espero no final cobrir boa parte de um ambiente DG e MAA: switchover, failover, reisntate, broker, observer e afins.

Uma configuração como esta seria a aplicada em um ambiente Exadata que necessita de alta disponibilidade. Você teria que configurar MAA com DG entre dois Exadatas, como é RAC seria um DG sobre RAC.

PRIMEIRO ARTIGO

Neste primeiro artigo iremos configurar um ambiente DG em dois sites, somente o banco será replicado. Neste artigo não iremos ver a configuração do Broker nem failover, switchover e reinstate; isso ficará para próximos artigos.

Continue lendo…