Oracle RAC 26ai: entendendo a arquitetura antes de começar a instalação

Instalar Oracle RAC não é apenas executar o gridSetup.sh, avançar algumas telas e esperar tudo ficar verde no final.

Antes de abrir o instalador, é preciso entender o que estamos construindo. Caso contrário, nomes como SCAN, VIP, interconnect, OCR, Voting File e ASM viram apenas campos que precisam ser preenchidos — e qualquer erro durante a instalação parece um mistério.

A proposta deste artigo é justamente organizar essas peças. Não será um passo a passo completo de instalação, mas uma visão arquitetural para você entender o que existe em um ambiente Oracle RAC 26ai, para que cada componente serve e como tudo funciona em conjunto.

Primeiro: o que é Oracle RAC?

RAC significa Real Application Clusters. Em uma arquitetura tradicional, normalmente temos uma instância acessando um banco de dados. No RAC, a relação muda: duas ou mais instâncias, executadas em servidores diferentes, acessam o mesmo banco de dados.

Esse ponto merece atenção porque é comum imaginar um RAC de dois nós como se fossem dois bancos independentes sincronizando dados. Não é isso.

Existe apenas um banco de dados, com seus datafiles e control files compartilhados, mas existem várias instâncias acessando esse conjunto de arquivos.

Cada instância possui sua própria:

SGA;
estrutura de processos em background;
thread de redo;
tablespace de UNDO específico.

Portanto, em um cluster com dois nós, poderíamos ter as instâncias RAC1 e RAC2, mas ambas acessando o mesmo banco RAC.

Essa arquitetura permite distribuir conexões e carga de trabalho entre servidores e também elimina o servidor de banco de dados como ponto único de falha. Se um nó ou uma instância falhar, os serviços podem continuar ou ser retomados nos nós sobreviventes — desde que toda a solução tenha sido corretamente planejada.

RAC não transforma automaticamente qualquer aplicação em altamente disponível. Ele fornece a infraestrutura para alta disponibilidade e escalabilidade, mas o resultado também depende dos serviços, da configuração dos clientes e do comportamento da aplicação.

Servidor, nó, instância e banco não são a mesma coisa

Antes de avançar, vale separar quatro conceitos que muitas vezes aparecem misturados:

Conceito	O que representa
Servidor	A máquina física ou virtual que fornece CPU, memória, interfaces de rede e acesso ao storage.
Nó	Um servidor que participa oficialmente do cluster e é reconhecido pelo Oracle Clusterware.
Instância	A SGA e os processos Oracle que executam em um nó.
Banco de dados	O conjunto compartilhado de arquivos físicos acessado pelas instâncias.

Um servidor só passa a fazer parte do cluster depois que a infraestrutura do Grid é configurada e o nó é registrado como membro. Da mesma forma, instalar os binários do Oracle Database em duas máquinas não cria um RAC. É o conjunto formado por Clusterware, redes, storage compartilhado, instâncias e serviços que entrega essa arquitetura.

A fundação: Oracle Grid Infrastructure

Antes de instalar o software do Oracle Database para RAC, instalamos o Oracle Grid Infrastructure. Ele reúne dois componentes fundamentais:

Oracle Clusterware, responsável pelo cluster e pela alta disponibilidade dos recursos;
Oracle ASM, responsável pelo gerenciamento do storage utilizado pelo cluster e pelos bancos.

Na prática, o Grid Infrastructure é a base sobre a qual o RAC será construído. É ele que reconhece os nós, acompanha a saúde do cluster, administra recursos e apresenta o storage de forma organizada para as instâncias.

Existe também uma regra importante de compatibilidade: a versão do Grid Infrastructure deve ser igual ou superior à versão mais alta do Oracle Database executada no cluster. Se o mesmo cluster hospedar bancos 19c e 26ai, por exemplo, o Grid Infrastructure precisa estar no nível do 26ai.

Oracle Clusterware: o maestro do ambiente

O Oracle Clusterware sabe quais nós pertencem ao cluster e gerencia recursos como:

VIPs;
SCAN VIPs e SCAN Listeners;
listeners locais;
ASM;
bancos de dados;
instâncias;
PDBs;
serviços.

Para o Clusterware, esses componentes são recursos. Cada recurso tem dependências e regras de inicialização, parada, monitoramento e recuperação. Por isso, em RAC, não devemos tratar tudo apenas com comandos de uma instância isolada. Ferramentas como o srvctl conversam com o Clusterware e preservam a visão do ambiente como um conjunto.

Se uma instância falhar, o Clusterware identifica a mudança e toma as ações previstas para aquele recurso. Se um nó sair do cluster, ele reorganiza o que for necessário nos nós restantes. É ele quem mantém a visão coordenada da infraestrutura.

OCR e Voting Files

Dois elementos aparecem cedo em qualquer projeto de RAC:

OCR — Oracle Cluster Registry: guarda as informações de configuração do cluster e dos recursos gerenciados pelo Clusterware.
Voting Files: participam da definição de membresia do cluster, ajudando a determinar quais nós continuam ativos e autorizados a participar.

Essa votação é essencial para evitar uma condição de split-brain, na qual partes isoladas do cluster poderiam acreditar, ao mesmo tempo, que estão no controle dos mesmos recursos. Em uma situação de perda de comunicação, o cluster precisa tomar uma decisão segura — não apenas manter todos os nós no ar a qualquer custo.

Oracle ASM: o storage visto como grupos de discos

As instâncias do RAC precisam acessar o mesmo conjunto de dados. Isso exige storage compartilhado, acessível pelos nós que executarão o banco.

O Oracle ASM simplifica a administração desse storage. Em vez de o DBA trabalhar diretamente com dezenas de discos e arquivos, os discos são agrupados em disk groups, como +DATA e +RECO.

De forma resumida:

+DATA pode armazenar datafiles, control files, online redo logs e outros arquivos do banco;
+RECO pode ser usado para a Fast Recovery Area, archived logs, backups e arquivos relacionados à recuperação.

O ASM distribui os dados entre os discos do grupo e pode oferecer redundância, conforme o desenho escolhido. Mas é importante entender um detalhe: ASM não substitui o planejamento de storage. Desempenho, capacidade, caminhos redundantes, multipath, permissões e apresentação consistente dos discos em todos os nós continuam sendo responsabilidades do projeto.

Em cada nó normalmente existe uma instância ASM. Essas instâncias administram o acesso aos mesmos disk groups, enquanto as instâncias do banco consomem o storage gerenciado por elas.

As redes de um Oracle RAC

Rede em RAC não é apenas “ter um IP em cada servidor”. Cada endereço e cada rede possui uma função específica.

Rede pública

É a rede pela qual os servidores se comunicam com o restante do ambiente. Também é onde ficam os endereços públicos, VIPs e SCAN utilizados no acesso dos clientes.

Rede privada ou interconnect

É o canal de comunicação interna entre os nós. Por ele trafegam mensagens do cluster e blocos de dados trocados entre as instâncias.

O interconnect tem participação direta no funcionamento e no desempenho do Cache Fusion. Latência, estabilidade, redundância e configuração incorreta de MTU podem afetar todo o ambiente. Ele não deve ser tratado como uma rede secundária sem importância só porque os usuários não se conectam diretamente a ela.

VIP — Virtual IP

Cada nó possui normalmente uma VIP associada. Quando um nó falha, sua VIP pode ser deslocada para outro nó, permitindo que novas tentativas de conexão recebam uma resposta rápida em vez de esperar longos timeouts de rede.

A VIP não é o mecanismo que preserva uma sessão já conectada. Ela faz parte da estratégia de conectividade e detecção rápida de indisponibilidade. A continuidade das sessões e transações envolve outros recursos e configurações no cliente e na aplicação.

SCAN — Single Client Access Name

O SCAN fornece um nome estável para o acesso ao cluster. A aplicação não precisa conhecer individualmente o hostname ou a VIP de cada nó.

O fluxo, de forma simplificada, funciona assim:

o cliente resolve o nome SCAN;
conecta-se a um SCAN Listener;
o SCAN Listener identifica onde o serviço solicitado está disponível;
a conexão é direcionada ao listener local de um nó adequado;
o listener entrega a conexão à instância que oferece o serviço.

Isso desacopla a configuração do cliente da quantidade e do nome dos nós. Um nó pode ser incluído ou removido sem exigir que todas as aplicações recebam uma nova lista manual de endereços.

Cache Fusion: como as instâncias trabalham sobre os mesmos dados

Agora chegamos a uma das partes mais interessantes da arquitetura.

Imagine que uma sessão conectada à instância RAC1 altere um bloco e, logo depois, uma sessão conectada à RAC2 precise acessar esse mesmo bloco. As instâncias não podem trabalhar como ilhas independentes, pois precisam manter uma visão coerente dos dados.

O Cache Fusion coordena esse acesso e permite a transferência de blocos entre os caches das instâncias pelo interconnect. Em muitos casos, a instância que precisa do bloco pode recebê-lo diretamente da memória de outra instância, em vez de buscá-lo novamente no storage.

Dois serviços globais ajudam nessa coordenação:

GCS — Global Cache Service: coordena o acesso aos blocos mantidos nos caches das instâncias;
GES — Global Enqueue Service: coordena recursos globais e enqueues utilizados pelas instâncias.

Esse funcionamento explica por que o desenho da aplicação também importa. Se sessões espalhadas entre instâncias disputam continuamente os mesmos blocos, aumenta a comunicação pelo interconnect. RAC oferece escalabilidade, mas não elimina contenção e não corrige sozinho um modelo de dados ou uma distribuição de carga inadequados.

Services: a aplicação não deveria escolher uma instância

No RAC, a aplicação deve solicitar um serviço, e não decidir que sempre se conectará à instância 1 ou à instância 2.

Um serviço representa uma carga de trabalho. Podemos criar, por exemplo:

um serviço para o ERP;
outro para relatórios;
outro para rotinas batch;
outro para um PDB específica.

Cada serviço pode ser disponibilizado em instâncias definidas e administrado pelo Clusterware. Isso permite distribuir cargas, estabelecer preferências e controlar onde cada tipo de trabalho executa.

No Oracle RAC 26ai, o DBCA cria um serviço padrão do banco, mas a própria Oracle recomenda reservá-lo para manutenção. Para conexões de usuários e aplicações, devem ser criados serviços dinâmicos, gerenciados pelo Clusterware.

Esse é um detalhe arquitetural que frequentemente passa despercebido: terminar a criação do banco não significa que a estratégia de conexão está pronta.

O que acontece quando um nó falha?

Vamos imaginar um cluster com dois nós. A aplicação acessa um serviço disponível nas duas instâncias e o nó 1 falha.

Em linhas gerais:

o Clusterware detecta que o nó deixou de participar do cluster;
a membresia é reorganizada para proteger a integridade do ambiente;
os recursos daquele nó são avaliados conforme suas políticas;
o serviço permanece ou é iniciado em uma instância sobrevivente;
novas conexões são direcionadas para uma instância que oferece o serviço.

As sessões que estavam no nó perdido serão impactadas. O modo como a aplicação se recupera dependerá da configuração de conexão e de tecnologias como Fast Application Notification e Application Continuity. Por isso, “o banco continuou no ar” e “o usuário não percebeu nada” são afirmações diferentes.

A ordem lógica da instalação

Quando entendemos as dependências, a sequência da implantação deixa de parecer arbitrária:

Preparar os servidores: sistema operacional, pacotes, usuários, grupos, limites, nomes e sincronização de horário.
Preparar redes e nomes: IPs públicos, privados, VIPs, SCAN e resolução no DNS.
Preparar o storage compartilhado: discos, multipath, permissões, capacidade e redundância.
Instalar o Grid Infrastructure: formar o cluster e configurar Clusterware e ASM.
Validar a infraestrutura: nós, redes, recursos, disk groups e listeners.
Instalar o Oracle Database: distribuir o Oracle Home de banco pelos nós do cluster.
Criar o banco RAC com o DBCA: criar a CDB, as instâncias, redo threads, UNDOs e PDBs necessários.
Criar e configurar os serviços: definir como as aplicações realmente acessarão o banco.

No 26ai, vale registrar duas características: a arquitetura suportada é baseada em CDB e PDBs, e a opção de implantação de banco policy-managed foi descontinuada. Portanto, o planejamento deve considerar o modelo administrator-managed.

Checklist arquitetural antes do instalador

Antes de iniciar, eu confirmaria pelo menos estes pontos:

Os nomes dos nós, IPs públicos, privados, VIPs e SCAN estão definidos?
O SCAN está corretamente registrado e resolvido no DNS?
O interconnect é dedicado, redundante e consistente entre os nós?
A configuração de MTU é igual em todo o caminho de rede?
Todos os nós enxergam os mesmos discos pelos caminhos esperados?
Multipath, permissões e persistência dos dispositivos foram validados?
O desenho dos disk groups considera capacidade, desempenho e recuperação?
Os usuários, grupos e diretórios Oracle são consistentes?
O horário dos nós está sincronizado?
A versão do Grid Infrastructure é compatível com todos os bancos previstos?
Os nomes de DB_UNIQUE_NAME, CDBs, PDBs e serviços foram planejados?
Já sabemos quais cargas serão atendidas por cada serviço?
A configuração do cliente prevê failover e recuperação compatíveis com a aplicação?

Se algumas dessas respostas ainda forem “vamos decidir durante a instalação”, o ambiente ainda não está pronto para a instalação.

Conclusão

Entender Oracle RAC não é decorar uma coleção de siglas. É compreender as relações entre os componentes.

O Clusterware mantém a visão do cluster e gerencia os recursos. O ASM organiza o storage compartilhado. O interconnect sustenta a comunicação entre os nós. O Cache Fusion coordena o acesso aos blocos. O SCAN e os listeners encaminham as conexões. E os serviços conectam as aplicações à carga de trabalho correta.

Quando essa arquitetura está clara, o instalador deixa de ser uma sequência de telas. Cada campo passa a representar uma decisão que já foi tomada no projeto.

E é justamente aí que começa uma boa instalação de Oracle RAC: antes de executar o primeiro instalador.

Quer aprender isso na prática?

Na Imersão Oracle RAC 26ai, vamos trabalhar a arquitetura, a preparação do ambiente, a instalação e a administração do cluster de forma prática e acompanhada.

Data: 28 de setembro a 1º de outubro de 2026
Horário: 19h às 23h
Carga horária: 16 horas
Turma: no máximo 5 alunos

Conheça a Imersão Oracle RAC 26ai e faça sua inscrição

Douglas Paiva | Cloud & Database