Aula 24: Oracle em produção — RAC, Data Guard e alta disponibilidade - BLOG

Chegamos à aula final do curso Oracle SQL — Do Zero ao Avançado, e o tema não poderia ser mais relevante: Oracle em produção. Até aqui, você dominou modelagem, consultas, PL/SQL, tuning e administração local. Agora, o foco muda para o ambiente real das empresas, onde o banco precisa continuar disponível mesmo diante de falhas de hardware, manutenção programada ou até desastres no datacenter. Nesta aula, você vai aprender os pilares de alta disponibilidade do Oracle: RAC (Real Application Clusters) e Data Guard, além de práticas essenciais para operar, monitorar e diagnosticar um Oracle em produção com segurança e previsibilidade.

Ao longo desta aula, vamos entender por que simplesmente instalar uma instância Oracle em um único servidor não é suficiente para ambientes críticos. Vamos explorar a arquitetura de RAC, que permite que várias instâncias compartilhem o mesmo banco físico, e o Data Guard, que mantém cópias de contingência sincronizadas em tempo real ou quase real. Você verá comandos reais de configuração, arquivos de parâmetros completos, verificações de saúde do cluster e testes de switchover/failover. Nosso objetivo é que, ao final desta aula, você consiga planejar, configurar e validar uma solução de alta disponibilidade Oracle em produção do zero, executando cada passo em um ambiente de laboratório.

Esta aula é avançada e exige que você tenha concluído as aulas anteriores, especialmente as que tratam de instalação do Oracle Database, listener, tnsnames, arquivos de controle, redo logs e RMAN. Você também precisará de acesso a dois servidores Linux (físicos ou virtuais) para construir o cenário de Data Guard. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente exatamente os procedimentos que você verá aqui, porque alta disponibilidade não é um luxo, é uma necessidade de negócio em bancos que suportam sistemas de missão crítica, ERPs e ambientes de segurança da informação.

Prepare-se para uma aula densa, mas extremamente prática. Vamos começar entendendo a arquitetura e, em seguida, executar a configuração completa de um Data Guard físico com base ativa, além de verificar um cluster RAC já provisionado. Se você seguir os passos exatamente como descritos, terá ao final um ambiente funcional e os conhecimentos necessários para operar Oracle em produção com confiança. Ao final, você encontrará uma seção de erros comuns, dicas avançadas e o encerramento completo do curso.

O que você vai aprender nesta aula

Compreender a arquitetura de alta disponibilidade no Oracle e as diferenças entre RAC, Data Guard e GoldenGate.
Identificar os componentes críticos do RAC: Oracle Clusterware, OCR, Voting Disk, ASM e SCAN.
Configurar um ambiente Data Guard físico completo, do zero, usando RMAN DUPLICATE FROM ACTIVE DATABASE.
Preparar o banco primário com force logging, standby redo logs e parâmetros de envio de archivelogs.
Criar e editar arquivos tnsnames.ora, listener.ora e init.ora/spfile para suportar o Data Guard.
Verificar o funcionamento do transporte e da aplicação de logs no standby usando SQL*Plus e DGMGRL.
Testar switchover e failover com segurança em um ambiente de testes.
Diagnosticar erros comuns de rede, parâmetros e permissões em ambientes Oracle em produção.

Pré-requisitos e Ambiente

Antes de iniciar esta aula, você precisa ter um ambiente mínimo preparado. Recomendamos duas máquinas virtuais com Oracle Linux 8 ou Ubuntu Server 22.04, cada uma com pelo menos 4 vCPUs, 8 GB de RAM e 40 GB de disco. É fundamental que as duas máquinas consigam se comunicar pela rede e que o firewall esteja configurado para liberar as portas 1521 (listener) e 1522 (se usar listener dedicado ao standby). Você também precisará do Oracle Database instalado e com um banco de dados criado em uma das máquinas, que será o primário. A outra máquina terá apenas o software Oracle instalado, sem banco, para receber o standby.

Além do software, você deve garantir que os comandos sqlplus, rman, srvctl, crsctl e dgmgrl estejam no PATH do usuário oracle. Em nossos projetos na JRT Technology Solutions, padronizamos o diretório de instalação do Oracle em /u01/app/oracle/product/19.0.0/dbhome_1 e o repositório de dados em /u01/oradata. Você pode adaptar os caminhos conforme seu ambiente, mas mantenha consistência entre os servidores para evitar confusão durante a configuração. Para o laboratório desta aula, considere os seguintes nomes:

Banco primário: ORCL_PRI, com instância ORCL_PRI, servidor dbpri (IP 192.168.56.101).
Banco standby: ORCL_STB, com instância ORCL_STB, servidor dbstb (IP 192.168.56.102).
Sistema operacional: Oracle Linux 8 (ou Ubuntu Server 22.04, com pequenas variações nos pacotes).
Senha do usuário SYS: Oracle123 (altere em produção!).

Se você ainda não tem um banco primário criado, execute um DBCA simples com o nome ORCL_PRI antes de continuar. O standby será criado no decorrer da aula, e não requer banco pré-existente. Todos os comandos devem ser executados como usuário oracle, salvo indicação contrária para root. Verifique também se o ASM está disponível ou, se preferir, utilize file system tradicional — para simplificar o laboratório, vamos usar file system. Em produção real, o ASM é altamente recomendado, mas não é obrigatório para entender o Data Guard.

Por fim, certifique-se de que o Oracle Net está funcionando no primário: o listener deve estar ativo e o tnsnames.ora deve permitir conexão local. Vamos partir do princípio de que o banco primário está em modo ARCHIVELOG. Se não estiver, rode SHUTDOWN IMMEDIATE, STARTUP MOUNT, ALTER DATABASE ARCHIVELOG e ALTER DATABASE OPEN. Esse é o pré-requisito inegociável para o Data Guard, porque a replicação é baseada em archivelogs.

Arquitetura de Alta Disponibilidade no Oracle em produção

Quando falamos de Oracle em produção, a alta disponibilidade se baseia em duas abordagens complementares: escalabilidade horizontal e local com RAC, e proteção contra desastres e contingência com Data Guard. O RAC permite que múltiplas instâncias Oracle, rodando em servidores diferentes, acessem simultaneamente o mesmo banco físico, armazenado em discos compartilhados. Isso elimina o servidor único como ponto de falha dentro do datacenter e permite balanceamento de carga entre as instâncias. Já o Data Guard mantém uma ou mais cópias independentes do banco em servidores separados, geralmente em outro local geográfico, protegendo contra perda total do site primário.

Essas tecnologias não são concorrentes: em um ambiente maduro, é comum encontrar RAC no site primário e RAC no site de contingência, com Data Guard sincronizando os dois clusters. Esse é o desenho que implementamos em grande parte dos clientes da JRT Technology Solutions. Além disso, existe o Oracle GoldenGate, que faz replicação lógica heterogênea, mas seu escopo é diferente e não substitui o Data Guard para proteção física. Para esta aula final, vamos focar nos fundamentos do RAC e na implementação prática do Data Guard físico, que é a solução mais adotada em Oracle em produção.

O RAC depende de um conjunto de componentes chamado Oracle Clusterware. Esse software gerencia o cluster, monitora a saúde dos nós e coordena o acesso ao armazenamento compartilhado. Dentro do Clusterware, dois arquivos são vitais: o OCR (Oracle Cluster Registry), que guarda a configuração do cluster, e o Voting Disk, que é usado para evitar o efeito split-brain, quando os nós perdem comunicação e ambos tentam assumir o controle. O armazenamento compartilhado é normalmente gerenciado pelo ASM (Automatic Storage Management), um gerenciador de volumes e sistema de arquivos nativo do Oracle. O SCAN (Single Client Access Name) simplifica a conexão dos clientes, abstraindo a lista de nós.

Já o Data Guard trabalha com o conceito de redo transport e redo apply. O banco primário gera redo logs continuamente. Quando um log é preenchido e arquivado, o parâmetro log_archive_dest_2 envia esse archivelog para o standby através do Oracle Net. No standby, o processo RFS (Remote File Server) recebe o arquivo, e o processo MRP (Managed Recovery Process) aplica as mudanças no banco em modo de recuperação contínua. Dependendo da configuração, o transporte pode ser síncrono (Maximum Availability ou Maximum Protection) ou assíncrono (Maximum Performance), cada um com implicações diferentes em latência e proteção contra perda de dados.

Para operar Oracle em produção com Data Guard, você precisará dominar três fases: preparação do primário, criação do standby e validação contínua. A preparação envolve habilitar FORCE LOGGING, criar Standby Redo Logs no primário (e depois no standby) e configurar parâmetros como log_archive_config, log_archive_dest_2, standby_file_management e fal_server. A criação do standby pode ser feita de várias formas, mas a mais eficiente em versões modernas é o RMAN DUPLICATE FROM ACTIVE DATABASE, que copia os arquivos diretamente pela rede, sem necessidade de backup intermediário em disco.

RAC: Fundamentos e Componentes Críticos

Antes de partir para a configuração do Data Guard, é essencial entender como verificar um cluster RAC já existente, pois você pode assumir um ambiente Oracle em produção que já utiliza essa tecnologia. O RAC exige pelo menos dois nós, cada um com sua própria instância Oracle, mas compartilhando o mesmo banco físico via ASM ou sistema de arquivos clusterizado. O objetivo é duplo: continuidade em caso de falha de um nó e aumento de capacidade de processamento, já que conexões podem ser distribuídas entre as instâncias.

Os principais comandos para inspecionar um cluster RAC são fornecidos pelas ferramentas crsctl e srvctl. O crsctl controla o Oracle Clusterware e seus recursos, enquanto o srvctl gerencia recursos específicos do Oracle, como bancos, instâncias, listeners e serviços. No dia a dia da JRT Technology Solutions, utilizamos esses comandos em scripts de monitoramento e em auditorias de ambientes críticos. Vamos ver na prática como obter o estado do cluster e de seus componentes.

Para verificar se o cluster está ativo e saudável, execute como usuário oracle:

# Verificar o estado do cluster em todos os nós
crsctl check cluster -all

**************************************************************
dbpri:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
dbstb:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************

O comando crsctl check cluster -all consulta o estado do Oracle High Availability Services e do Cluster Ready Services em todos os nós configurados. A saída mostra três componentes fundamentais: Cluster Ready Services (CRS), Cluster Synchronization Services (CSS) e Event Manager (EVM). Se qualquer um deles estiver offline, o cluster não está funcional e precisa de intervenção imediata. Em seguida, você deve listar os recursos do cluster para verificar bancos, listeners e serviços:

# Listar o status resumido dos principais recursos do cluster
crsctl status resource -t

--------------------------------------------------------------------------------
Name           Target  State        Server                   State details       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       dbpri                   STABLE
ora.diskmon
      1        OFFLINE OFFLINE                              STABLE
ora.evmd
      1        ONLINE  ONLINE       dbpri                   STABLE
ora.orcl.db
      1        ONLINE  ONLINE       dbpri                   Open,HOME=/u01/app/o
      2        ONLINE  ONLINE       dbstb                   Open,HOME=/u01/app/o
ora.scan1.vip
      1        ONLINE  ONLINE       dbpri                   STABLE
--------------------------------------------------------------------------------

A saída do crsctl status resource -t é uma tabela com os recursos e seus estados. Repare que o banco ora.orcl.db aparece com duas entradas, uma para cada instância do RAC, ambas no estado ONLINE e com o status Open. Isso indica que as duas instâncias estão abertas e prontas para receber conexões. O recurso ora.scan1.vip representa o SCAN, que os clientes utilizam para conectar sem precisar saber qual nó está ativo. Se você está começando agora, não precisa criar um RAC do zero, mas saber interpretar essas saídas é indispensável para atuar em Oracle em produção.

Para consultar a configuração de um banco RAC com srvctl, use:

# Exibir a configuração do banco de dados ORCL no cluster
srvctl config database -d ORCL

Database unique name: ORCL
Database name: ORCL
Oracle home: /u01/app/oracle/product/19.0.0/dbhome_1
Oracle user: oracle
Spfile: +DATA/ORCL/PARAMETERFILE/spfile.276.1100000000
Password file: +DATA/ORCL/PASSWORD/pwdorcl.256.1100000000
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: 
Disk Groups: DATA, FRA
Mount point paths: 
Services: 
Type: RAC
Start concurrency: 
Stop concurrency: 
OSDBA group: dba
OSOPER group: oper
Database instances: ORCL1,ORCL2
Configured nodes: dbpri,dbstb
Database is administrator managed

Esse comando mostra detalhes como o Spfile e o Password file armazenados no ASM, o tipo do banco (RAC), as instâncias configuradas e o papel atual do banco (PRIMARY). Em um ambiente com Data Guard, o papel pode aparecer como PHYSICAL STANDBY no site de contingência. Entender essa saída permite documentar e auditar o ambiente rapidamente, uma habilidade que valorizamos muito em nossos especialistas da JRT Technology Solutions.

Configurando Data Guard no Oracle em produção — Passo a Passo Completo

Agora vamos ao coração da aula: criar um Data Guard físico do zero. Nosso cenário terá um banco primário ORCL_PRI no servidor dbpri e um standby ORCL_STB no servidor dbstb. O primeiro passo é garantir que o primário esteja em modo ARCHIVELOG e com FORCE LOGGING ativado. O FORCE LOGGING impede que operações como nologging deixem de gerar redo, o que é crítico para a consistência do standby. Conecte-se ao primário com SQL*Plus como SYS e execute a sequência abaixo.

-- Conectar no banco primário como SYS
sqlplus sys/Oracle123@ORCL_PRI as sysdba

-- 1. Habilitar force logging para garantir que todas as operações gerem redo
ALTER DATABASE FORCE LOGGING;

-- 2. Adicionar standby redo logs no primário (o standby também precisará deles)
-- Vamos criar 4 grupos adicionais, iniciando no grupo 4
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 
  '/u01/oradata/ORCL_PRI/srl04.log' SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 
  '/u01/oradata/ORCL_PRI/srl05.log' SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 
  '/u01/oradata/ORCL_PRI/srl06.log' SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 
  '/u01/oradata/ORCL_PRI/srl07.log' SIZE 200M;

-- 3. Configurar parâmetros de transporte de redo no primário
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(ORCL_PRI,ORCL_STB)' SCOPE=both;
ALTER SYSTEM SET log_archive_dest_2='SERVICE=ORCL_STB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STB' SCOPE=both;
ALTER SYSTEM SET log_archive_dest_state_2=ENABLE SCOPE=both;

-- 4. Configurar o gerenciamento automático de arquivos e FAL no primário
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=both;
ALTER SYSTEM SET fal_server=ORCL_STB SCOPE=both;

-- 5. Definir nomes de arquivo no standby para facilitar a conversão
ALTER SYSTEM SET db_file_name_convert='/u01/oradata/ORCL_STB/','/u01/oradata/ORCL_PRI/' SCOPE=spfile;
ALTER SYSTEM SET log_file_name_convert='/u01/oradata/ORCL_STB/','/u01/oradata/ORCL_PRI/' SCOPE=spfile;

Cada bloco tem uma função específica. O comando ALTER DATABASE FORCE LOGGING ativa o registro obrigatório de redo. Os Standby Redo Logs (SRLs) são usados pelo standby para receber e aplicar redo em tempo real; criamos quatro grupos porque o primário tem quatro grupos de redo online, e a regra prática é ter no mínimo o mesmo número de grupos mais um. O parâmetro log_archive_config define a lista de bancos participantes do Data Guard, permitindo que o primário reconheça o standby. O log_archive_dest_2 aponta para o serviço de rede do standby com transporte assíncrono (ASYNC), priorizando performance. Os parâmetros db_file_name_convert e log_file_name_convert instruem o standby a converter caminhos de arquivos quando um switchover ocorrer.

Após configurar o primário, precisamos preparar os arquivos de rede. No primário, edite o tnsnames.ora e adicione as entradas para os dois bancos. O conteúdo completo do arquivo em $ORACLE_HOME/network/admin/tnsnames.ora deve ficar assim:

# tnsnames.ora do servidor primário (dbpri)
# Entrada para o banco primário local
ORCL_PRI =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = dbpri)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL_PRI)
    )
  )

# Entrada para o banco standby remoto
ORCL_STB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = dbstb)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL_STB)
    )
  )

Repare que usamos SERVICE_NAME em vez de SID, uma prática recomendada para ambientes Oracle em produção e obrigatória para conexões com listeners que suportam múltiplos serviços. A mesma configuração deve ser replicada no servidor standby, com os mesmos nomes e IPs, para que os processos de transporte consigam resolver os serviços em ambas as direções. Depois, no primário, verifique se o listener está ativo e registre o banco, se necessário, com ALTER SYSTEM REGISTER.

O próximo passo é criar o arquivo de senha e preparar o standby. No primário, copie o arquivo de senha para o standby usando scp:

# No servidor primário (dbpri), copiar o password file para o standby
scp $ORACLE_HOME/dbs/orapwORCL_PRI oracle@dbstb:$ORACLE_HOME/dbs/orapwORCL_STB

No servidor standby, crie o arquivo de parâmetros inicial initORCL_STB.ora com o conteúdo abaixo. Esse arquivo será usado para iniciar a instância em modo NOMOUNT durante a duplicação. O conteúdo completo deve ser:

# initORCL_STB.ora no servidor standby (dbstb)
db_name=ORCL_PRI
db_unique_name=ORCL_STB
db_domain=
control_files='/u01/oradata/ORCL_STB/control01.ctl'
db_block_size=8192
memory_target=2G
processes=300
audit_file_dest='/u01/app/oracle/admin/ORCL_STB/adump'
db_file_name_convert='/u01/oradata/ORCL_PRI/','/u01/oradata/ORCL_STB/'
log_file_name_convert='/u01/oradata/ORCL_PRI/','/u01/oradata/ORCL_STB/'
standby_file_management=AUTO
fal_server=ORCL_PRI
remote_login_passwordfile=EXCLUSIVE

Esse arquivo de parâmetros diz ao Oracle que a instância pertence ao banco ORCL_PRI (parâmetro db_name), mas que seu nome único no Data Guard é ORCL_STB (db_unique_name). Os parâmetros db_file_name_convert e log_file_name_convert mapeiam os caminhos do primário para o standby, essenciais para a duplicação e para switchovers. O fal_server aponta para o primário, permitindo que o standby solicite logs que eventualmente estejam faltando. O remote_login_passwordfile=EXCLUSIVE permite conexões remotas como SYSDBA, necessárias para o RMAN e o Data Guard.

Com o arquivo pronto, inicie a instância standby em NOMOUNT e execute a duplicação via RMAN. Conecte-se ao primário como TARGET e ao standby como AUXILIARY. O comando DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE copia todos os arquivos diretamente, sem necessidade de backup prévio. Veja a sequência completa:

# No servidor standby (dbstb), como usuário oracle
export ORACLE_SID=ORCL_STB
sqlplus / as sysdba

-- Iniciar a instância em modo NOMOUNT
STARTUP NOMOUNT pfile='/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initORCL_STB.ora'
EXIT

# Executar a duplicação RMAN
rman target sys/Oracle123@ORCL_PRI auxiliary sys/Oracle123@ORCL_STB

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
2>   DORECOVER
3>   SPFILE
4>     SET db_unique_name='ORCL_STB' COMMENT 'Data Guard standby'
5>   NOFILENAMECHECK;

Starting Duplicate Db at 19-SEP-2026 10:35:42
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=54 device type=DISK
...
contents of Memory Script:
{
   restore clone standby controlfile to  '/u01/oradata/ORCL_STB/control01.ctl' from
   '/u01/oradata/ORCL_PRI/control01.ctl';
}
executing Memory Script
...
Finished Duplicate Db at 19-SEP-2026 10:58:17

O RMAN executa várias etapas internas: restaura o controlfile para standby, copia os datafiles, restore os standby redo logs e deixa o banco em modo de recuperação. O parâmetro DORECOVER solicita que a recuperação seja iniciada automaticamente após a cópia, embora você possa controlar isso depois. O NOFILENAMECHECK permite que arquivos com caminhos diferentes entre primário e standby sejam aceitos sem erro. Ao final, se a mensagem Finished Duplicate Db aparecer sem erros, o standby foi criado com sucesso. Em nossos projetos na JRT Technology Solutions, esse é o procedimento padrão para provisionar réplicas físicas em Oracle em produção.

Agora, conecte-se ao standby e inicie o Managed Recovery Process (MRP) para aplicar os logs recebidos. Execute:

# No standby, como SYS
sqlplus / as sysdba
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Esse comando inicia a recuperação gerenciada em segundo plano, aplicando os redo logs recebidos do primário, inclusive o log online corrente se a transferência estiver ativa. A opção DISCONNECT FROM SESSION libera o terminal, e o processo continua rodando no servidor. Para verificar se o transporte e a aplicação estão funcionando, consulte a view V$ARCHIVE_DEST no primário e a V$MANAGED_STANDBY no standby, como veremos na seção de verificação.

Configuração Detalhada de Arquivos e Parâmetros

Nesta seção, vamos consolidar e detalhar cada arquivo de configuração envolvido no Oracle em produção com Data Guard. Ter esses arquivos documentados e padronizados evita erros recorrentes e facilita a automação. Começaremos pelo listener.ora do standby, que precisa estar ativo para aceitar conexões do primário. O conteúdo completo do arquivo em $ORACLE_HOME/network/admin/listener.ora no servidor standby deve ser:

# listener.ora do servidor standby (dbstb)
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dbstb)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = ORCL_STB)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME = ORCL_STB)
    )
  )

O bloco SID_LIST_LISTENER registra estaticamente o serviço ORCL_STB no listener, garantindo que mesmo antes do registro dinâmico da instância as conexões possam ser aceitas. Isso é particularmente importante durante a duplicação, quando a instância está em NOMOUNT e ainda não registrou serviços dinamicamente. O parâmetro GLOBAL_DBNAME deve ser o nome único do banco standby, e o SID_NAME deve corresponder ao ORACLE_SID da instância.

No primário, o listener.ora não precisa de configuração estática se o registro dinâmico estiver ativo, mas em ambientes de alta disponibilidade recomendamos manter uma entrada semelhante para facilitar failovers. O arquivo tnsnames.ora já foi apresentado na seção anterior e deve ser idêntico em ambos os servidores, exceto pelo endereço do host local quando os nomes DNS não resolvem. Em laboratórios sem DNS, adicione as entradas em /etc/hosts nos dois servidores:

# /etc/hosts no dbpri e no dbstb
192.168.56.101   dbpri
192.168.56.102   dbstb

Os parâmetros principais do banco primário, após a configuração do Data Guard, podem ser consultados com o comando SHOW PARAMETER. A tabela a seguir resume os parâmetros críticos, seus valores recomendados e o efeito prático em Oracle em produção.

Parâmetro	Valor recomendado	Efeito prático
db_unique_name	ORCL_PRI / ORCL_STB	Identifica unicamente cada banco no Data Guard.
log_archive_config	DG_CONFIG=(ORCL_PRI,ORCL_STB)	Lista os membros do Data Guard e evita envio indevido.
log_archive_dest_2	SERVICE=ORCL_STB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STB	Define transporte assíncrono para o standby, priorizando performance.
standby_file_management	AUTO	Permite adicionar datafiles no standby automaticamente.
fal_server	ORCL_PRI no standby / ORCL_STB no primário	Permite solicitar logs ausentes (Fetch Archive Log).

Outro arquivo importante é o spfile do standby, criado durante a duplicação. Você pode revisá-lo com CREATE PFILE FROM SPFILE e inspecionar os parâmetros. Em produção, recomendamos manter o spfile no ASM, mas em laboratório o file system atende. Para converter o standby em um papel primário no futuro, os parâmetros db_file_name_convert e log_file_name_convert devem estar corretos em ambos os lados, pois eles mapeiam os caminhos durante um switchover. Sem eles, o banco pode tentar abrir com caminhos inexistentes e falhar.

Por fim, lembre-se de que o Data Guard Broker pode facilitar a administração com o utilitário DGMGRL. A configuração do broker é opcional, mas fortemente recomendada para Oracle em produção, porque centraliza o switchover, failover e monitoramento. Os comandos básicos seriam CREATE CONFIGURATION ‘DG_ORCL’ AS PRIMARY DATABASE IS ORCL_PRI CONNECT IDENTIFIER IS ORCL_PRI, seguido de ADD DATABASE ORCL_STB AS CONNECT IDENTIFIER IS ORCL_STB e ENABLE CONFIGURATION. Deixaremos essa configuração como exercício avançado, mas a base que você construiu já suporta a operação manual completa.

Verificando a Instalação / Testando a Configuração

Depois de configurar o Data Guard, é obrigatório validar se tudo está funcionando corretamente. A primeira verificação deve ser no banco primário, consultando o status do destino de archive. Conecte-se ao primário com SQL*Plus e execute:

-- No primário: verificar status do envio de archivelogs para o standby
SELECT DEST_ID, DEST_NAME, STATUS, TARGET, DB_UNIQUE_NAME, ERROR
FROM V$ARCHIVE_DEST
WHERE STATUS != 'INACTIVE';

   DEST_ID DEST_NAME                              STATUS    TARGET    DB_UNIQUE_NAME    ERROR
---------- -------------------------------------- --------- --------- ---------------- ----------
         1 LOG_ARCHIVE_DEST_1                     VALID     PRIMARY   ORCL_PRI
         2 LOG_ARCHIVE_DEST_2                     VALID     STANDBY   ORCL_STB

A presença do destino 2 com STATUS igual a VALID e TARGET igual a STANDBY indica que o primário reconhece o destino e não há erros de configuração imediatos. Se houver falha de rede ou parâmetro incorreto, o ERROR trará uma mensagem detalhada, como ORA-12541. Em seguida, consulte a visão V$ARCHIVED_LOG para confirmar que archivelogs foram gerados e enviados:

-- No primário: verificar os últimos archivelogs enviados
SELECT SEQUENCE#, NAME, APPLIED, DELETED, COMPLETION_TIME
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 2
ORDER BY SEQUENCE# DESC
FETCH FIRST 5 ROWS ONLY;

No standby, a verificação essencial é a do processo de recuperação ativo. Execute:

-- No standby: verificar o processo de managed recovery
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'MRP%' OR PROCESS LIKE 'RFS%';

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- --------------- -------- ---------- ---------- ----------
MRP0      APPLYING_LOG          1         47          0     204800
RFS       IDLE                  1         48          0     204800
RFS       IDLE                  0          0          0          0

A linha com MRP0 e status APPLYING_LOG confirma que o standby está aplicando redo ativamente. As linhas RFS com status IDLE são processos que recebem os archivelogs do primário. Se o MRP não estiver presente ou o status for WAIT_FOR_LOG, pode ser que os logs ainda não tenham chegado, mas o processo deve estar ativo. Outra verificação importante é o papel do banco no Data Guard:

-- No standby: confirmar que o banco é um physical standby
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE, PROTECTION_LEVEL
FROM V$DATABASE;

DATABASE_ROLE    OPEN_MODE            PROTECTION_MODE      PROTECTION_LEVEL
---------------- -------------------- -------------------- --------------------
PHYSICAL STANDBY MOUNTED              MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE

Se você visualizar PHYSICAL STANDBY e MOUNTED, o banco está no estado correto para operação contínua. O PROTECTION_MODE é MAXIMUM PERFORMANCE, coerente com o transporte assíncrono que configuramos. Para testar o fluxo completo, force um switch de log no primário e observe o sequence aumentar no standby:

-- No primário: forçar a geração de um novo archivelog
ALTER SYSTEM SWITCH LOGFILE;

Depois, aguarde alguns segundos e consulte novamente a V$MANAGED_STANDBY no standby. O SEQUENCE# do MRP deve avançar, confirmando que o transporte e a aplicação estão sincronizados. Esse teste simples é executado diariamente por nossos especialistas da JRT Technology Solutions em ambientes Oracle em produção para garantir a saúde do Data Guard.

Erros Comuns e Como Resolver

Mesmo com os procedimentos corretos, problemas podem surgir. Nesta seção, listamos os erros mais frequentes que encontramos ao configurar e operar Oracle em produção com Data Guard e RAC, com suas causas, sintomas e soluções completas. Estude cada um com atenção, pois eles aparecem em ambientes reais constantemente.

Quer aprender na prática com especialistas?

A JRT Technology Solutions oferece treinamentos e implementação de Oracle SQL para equipes corporativas.

Falar no WhatsApp