A operação de switchover no Data Guard corresponde a uma mudança planejada/desejada de função, seja para testes periódicos de estratégia de DR, migrações ou upgrades. Nela, um dos ambientes physical standby recebe do primary os redo logs restantes, e trocam de role/função, ou seja, o standby passa a operar como primary. Algumas etapas preliminares que […]

A primeira ferramenta que podemos usar para monitorar um Logical Standby é o Alert.log, conforme exemplo abaixo extraído do primary, onde o mesmo não consegue se comunicar com o standby: A view “V$DATAGUARD_STATUS” também nos reporta os eventos (incluindo mensagens de erro) reportados no alert: A view “DBA_LOGSTDBY_EVENTS” nos reporta as atividades do SQL Apply, […]

Este artigo explorará algumas formas para monitorarmos o Data Guard, e para simular um mínimo de operações sendo executadas no primary, faremos a criação de alguns objetos para execução de DML randômico. Criando a tabela no banco primary que sofrerá as alterações: Criando uma package que contém 2 procedures que executam os processos de DML, […]

Este artigo reproduz uma implementação muito simples, que é dada de exemplo na documentação da Oracle, para os casos onde temos tabelas não suportadas nativamente pelo SQL Apply, e que precisam de uma intervenção manual para que seus dados sejam replicados. Essa operação consiste basicamente na criação de uma tabela paralela, e as triggers que […]

O EDS (Extend Datatype Support) é um recurso no Data Guard (logical) que nos permite replicar mudanças em tabelas com datatypes não suportados de forma nativa pelo SQL Apply de um banco de dados para outro. Seu funcionamento é basicamente o mesmo com a outra estratégia para este tipo de situação, que é baseada em […]

Quando configuramos um Data Guard Logical Standby, a intenção primária é proteger as tabelas replicadas no ambiente standby para evitar que os usuários realizem alterações nelas, como DMLs e DDLs (uma vez que o banco de dados fica aberto neste cenário). Para isso, podemos utilizar no destino a propriedade “Guard”. Seu valor padrão está como […]

Para relembrar, nosso Data Guard com Logical Standby replicará todos os objetos, exceto em 3 situações: Objetos de schemas internos (como SYS e SYSTEM): é possível checarmos essa lista usando a query abaixo no primary: Objetos que possuam algum datatype incompatível (que podem ser coletados nas views DBA_LOGSTDBY_UNSUPPORTED e LOGSTDBY_UNSUPPORTED_TABLES): Regras criadas de forma explícita […]

Quando temos um Data Guard configurado em nosso ambiente, com o Standby do tipo Logical, podemos inicializar o SQL Apply conforme opçoes abaixo. Antes disso, checando se o primary e standby estão com as instâncias e listeners inicializados: No standby: No alert.log do standby, já é possível ver o Oracle iniciando o LogMiner dos archived […]

Verificando que o Redo Apply está OFF: Inicializando o apply: No ambiente primary, vamos criar a procedure abaixo para podermos realizar um teste durante o artigo: Como podemos ver, o modo vigente é o Maximum Performance (que é o valor padrão): Antes de iniciar os testes, vamos definir os parâmetros “NetTimeout”, “ReopenSecs” e “LogXptMode”: Já […]

Do mesmo modo que precisamos coletar com o negócio as suas premissas para que possamos definir a estratégia de backup/restore, do mesmo jeito precisamos ter este alinhamento para implementar o modo de proteção do Oracle Data Guard. Em suma, temos as seguintes opções: Maximum Protection: A prioridade neste caso é garantir que nenhum dado seja […]