Category Archives: RAC

Oracle Real Application Cluster e assuntos relacionados

21c, Zero-Downtime Oracle Grid Infrastructure Patching

Oracle 21c delivered a lot of new features and for Grid infrastructure one of the most interesting is the zero-downtime patch (zeroDowntimeGIPatching). This basically allows your database continues to be running while you patch/upgrade your GI. The official doc can be seen here. Let’s say that is an evolution of the Out of Place (OOP) patch for GI.

In this post I will show how to do that, but some details before starting:

  • This post shows how to do the zero-downtime patch using GUI mode.
  • I will do another post showing how to do in silent mode the same procedure. So, it can be automatized.
  • In a third post, I will detail how the zero-downtime works behind the scenes and will discuss some logs.

Click here to read more…

ZDLRA, Multi-site protection – ZERO RPO for Primary and Standby

ZDLRA can be used from a small single database environment to big environments where you need protection in more than one site at the same time. At every level, you can use different features of ZDLRA to provide desirable protection. Here I will show how to reach zero RPO for both primary and standby databases. All the steps, doc, and tech parts are covered.

You can check the examples the reference for every scenario int these two papers from the Oracle MAA team: MAA Overview On-Premises and Oracle MAA Reference Architectures. They provide good information on how to prepare to reduce RPO and improve RTO. In resume, the focus is the same, reduce the downtime and data loss in case of a catastrophe (zero RPO, and zero RPO).

Multi-site protection

If you looked both papers before, you saw that to provide good protection is desirable to have an additional site to, at least, send the backups. And if you go higher, for GOLD and PLATINUM environments, you start to have multiple sites synced with data guard. These Critical/Mission-critical environments need to be protected for every kind of catastrophic failure, from disk until complete site outage (some need to follow specific law’s requirements, bank as an example).

And the focus of this post is these big environments. I will show you how to use ZDLRA to protect both sites, reaching zero RPO even for standby databases. And doing that, you can survive for a catastrophic outage (like entire datacenter failure) and still have zero RPO. Going further, you can even have zero RPO if you lose completely on site when using real-time redo for ZDLRA, and this is not written in the docs by the way.

Click here to read more…

Exadata: Gerenciado Recursos

Depois de apresentar de forma breve alguns conceitos do Oracle Exadata em artigos anteriores (aqui e aqui) vou falar um pouco sobre como usar tudo isso de forma inteligente. Você já deve ter notado que no Oracle Exadata existem muitos recursos disponíveis como cluster Oracle RAC, grande quantidade de discos, Storage Servers entre outros.

Um dos cenários mais comuns para o Oracle Exadata é a consolidação de bancos de dados distintos (e requisitos distintos) no mesmo ambiente. De qualquer forma não há nada errado, você já faz isso no ambiente tradicional. O seu storage já armazena os blocos de diversas bases, provavelmente compartilhando os mesmos discos do raid group.

Mas onde que o Oracle Exadata se sai melhor? Basicamente na integração entre hardware e software que não existe no ambiente tradicional, a granularidade do que pode ser controlado é muito maior. Muitos dos conceitos aqui podem ser aplicados no ambiente tradicional, o detalhe é utilizá-los com inteligência.

Muitos destes tópicos já foram comentados por mim no Webinar sobre Gerenciamento de Recursos que fiz para o Exadata SIG do GUOB. Fiz um post sobre o Webinar que está disponível aqui e lá existe uma descrição mais detalhada do está neste artigo. De qualquer forma, tentarei passar alguns detalhes para que você consiga utilizar os recursos disponíveis de forma inteligente.

Continue lendo…

Oracle e MAA – Artigo IV – Switchover

Seguindo a ordem dos artigos o próximo passo é realizar o switchover entre primary e standby. Se você seguiu os artigos até aqui, já realizou um failover manual e um reinstate do seu ambiente. O switchover pode ser realizado sem que ocorra um failover, ele é uma operação legítima de um Data Guard. Os passos deste artigo podem ser realizados em um ambiente que não sofreu nenhuma falha até o momento.

QUARTO ARTIGO

Neste quarto artigo vamos realizar o switchover manual do ambiente, mostrarei os passos envolvidos e mais alguns detalhes. Citei acima que esse é uma sequência dos anteriores, mas os passos são os mesmos para um ambiente que necessita de um switchover sem que antes tenha ocorrido um failover.

Continue lendo…

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 II – Failover

No artigo anterior demonstrei como configurar um DG para que você possa ter MAA no seu ambiente. Foram apresentados os passos para criar um DG entre um banco primary ORACLE RAC e standby também em ORACLE RAC. Até o momento o ambiente não está 100%, ainda não configuramos o DG para utilizar o broker e nem fast-start failover, tudo será manual.

A função básica do DG é proteger quanto a possíveis falhas inesperadas em nosso banco primary. Existem vários tipos de falhas que podem deixar indisponível um banco de dados: hardware, software, estagiário, DBA Senior; inúmeras.

Quando trabalhamos com o Oracle em RAC as falhas que podem deixar o seu ambiente indisponível por completo reduzem, no caso de uma falha de um único nó o outro assume a carga e o banco continua disponível ao usuário. Mas ele não protege para falhas mais complexas. Se o seu storage falhar? Ou se a sua rede apresentar problema e o seu RAC cair?

É nesses cenários que o DG pode ajudar, ele irá proteger seu banco Oracle contra possíveis falhas do seu ambiente primary. Com MAA você teria tudo replicado no outro ambiente e em um ambiente RAC você estará protegido contra falhas de ambos os nós.

SEGUNDO ARTIGO

Neste artigo vamos dar sequência ao anterior e simular um failover no ambiente. Neste artigo você verá os passos e o que fazer para realizar o failover do primary para o seu standby, tudo isso de forma manual.

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…