Documentação do Oracle Cloud Infrastructure

Preparação para o Oracle Exadata Database Service na Infraestrutura do Exascale

Verifique o OCI, bem como os requisitos de local, rede e armazenamento para preparar e implantar o Oracle Exadata Database Service no Exascale Infrastructure no data center.

Requisitos do OCI (Oracle Cloud Infrastructure) para o Oracle Exadata Database Service no Exascale Infrastructure

Aprenda os conceitos básicos para começar a usar o Oracle Cloud Infrastructure.

O Oracle Exadata Database Service no Exascale Infrastructure é gerenciado pelo plano de controle do Oracle Cloud Infrastructure (OCI). Os recursos do Oracle Exadata Database Service no Exascale Infrastructure são implantados na sua Tenancy do OCI.

Para que você possa provisionar o Oracle Exadata Database Service na infraestrutura do Exascale Infrastructure, a tenancy do Oracle Cloud Infrastructure deve estar ativada para usar o Oracle Exadata Database Service na Infraestrutura do Exascale. Verifique as informações desta publicação para obter mais detalhes.

As tarefas a seguir são comuns para todas as implantações do OCI. Consulte os links nos Tópicos Relacionados para encontrar a documentação associada do Oracle Cloud Infrastructure.

  • Conceitos Básicos do OCI.

    Se você for iniciante no OCI, conheça os conceitos básicos para começar a utilizá-lo seguindo o Guia de Conceitos Básicos do OCI.

  • Configurando a Tenancy.

    Depois que a Oracle criar a tenancy no OCI, um administrador da empresa precisará executar algumas tarefas de configuração e estabelecer um plano de organização para usuários e recursos da nuvem. As informações deste tópico ajudarão você a começar.

  • Gerenciando Regiões

    Este tópico descreve os conceitos básicos de gerenciamento das assinaturas nas regiões.

  • Gerenciando Compartimentos

    Este tópico descreve os conceitos básicos sobre como trabalhar com compartimentos.

  • Gerenciando Usuários

    Este tópico descreve os conceitos básicos sobre como trabalhar com usuários.

  • Gerenciando Grupos

    Este tópico descreve os conceitos básicos sobre como trabalhar com grupos.

Política do Serviço IAM Obrigatória para o Oracle Exadata Database Service no Exascale Infrastructure

Verifique a política de gerenciamento de acesso de identidade (IAM) para provisionar sistemas Oracle Exadata Database Service no Exascale Infrastructure.

Política é um documento do IAM que especifica quem tem qual tipo de acesso aos seus recursos. Ela é usada de diversas formas:
  • Uma instrução individual escrita no idioma da política
  • Um conjunto de instruções em um documento único, com o nome "política", que tem um OCID (Oracle Cloud ID) designado a ele
  • O corpo geral das políticas que sua organização usa para controlar o acesso aos recursos

Compartimento é uma coleção de recursos relacionados que só podem ser acessados por determinados grupos que receberam permissão de um administrador da sua organização.

Para usar o Oracle Cloud Infrastructure, você deve receber o tipo necessário de acesso em uma política criada por um administrador, quer você esteja usando a Console ou a API REST com um SDK (Software Development Kit), uma interface de linha de comando (CLI) ou outra ferramenta. Se você tentar executar uma ação e receber uma mensagem informando que não tem permissão ou não está autorizado, confirme com o administrador da tenancy o tipo de acesso concedido e em qual compartimento você deve trabalhar.

Para administradores: A política em "Permitir que administradores de banco de dados gerenciem sistemas de BD" permite que o grupo especificado faça tudo com bancos de dados e recursos de banco de dados relacionados.

Se você não conhecer as políticas, consulte "Conceitos Básicos de Políticas" e "Políticas Comuns". Se quiser saber mais sobre a criação de políticas para bancos de dados, consulte "Detalhes do Serviço de Banco de Dados".

Para obter mais detalhes sobre a gravação de políticas específicas dos recursos do Exadata Cloud@Customer, consulte "Detalhes de Política do Oracle Exadata Database Service na Infraestrutura do Exascale".

Configuração de Rede para o Oracle Exadata Database Service em Instâncias de Infraestrutura do Exascale

Este tópico descreve a configuração recomendada da VCN e diversos requisitos relacionados da instância do Oracle Exadata Database Service no Exascale Infrastructure.

Antes de configurar um Oracle Exadata Database Service na instância da Infraestrutura do Exascale, configure uma rede virtual na nuvem (VCN) e outros Componentes do serviço Networking.

Tópico principal: Preparação para o Oracle Exadata Database Service na Infraestrutura do Exascale

VCN e Sub-redes

Para iniciar um cluster de VMs do Oracle Exadata Database Service no Exascale Infrastructure, você deve ter uma Rede Virtual na Nuvem e pelo menos duas sub-redes.

Para iniciar um cluster de VMs do Oracle Exadata Database Service no Exascale Infrastructure, você deve ter uma Rede Virtual na Nuvem, pelo menos duas sub-redes e selecionar o tipo de resolvedor de DNS que usará:

  • Uma VCN na região em que você deseja o cluster de VMs do Oracle Exadata Database Service no Exascale Infrastructure

  • Pelo menos duas sub-redes na VCN. As duas sub-redes são:

    • Sub-rede do cliente
    • Sub-rede de backup
  • Escolha qual método de resolução de nome DNS você usará. Consulte Opções para DNS na Sua VCN

Em geral, a Oracle recomenda o uso de sub-redes regionais , que abrangem todos os domínios de disponibilidade da região. Para obter mais informações, consulte Visão Geral de VCNs e Sub-redes.

Você criará tabelas de roteamento personalizadas para cada sub-rede. Você também criará regras de segurança para controlar o tráfego de/para a rede do cliente e a rede de backup dos nós de computação do Exadata (para o recurso de cluster de VMs na Nuvem, os nós são chamados de máquinas virtuais). São exibidas mais informações a seguir sobre esses itens.

Tópicos Relacionados

Tópico principal: Configuração da Rede para o Oracle Exadata Database Service em Instâncias de Infraestrutura do Exascale

Opção 1: Sub-rede de Cliente Pública com Gateway de Internet

Esta opção pode ser útil ao realizar um trabalho de desenvolvimento ou de prova de conceito.

Você pode usar essa configuração na produção, se quiser usar um gateway de internet com a VCN ou se tiver serviços que são executados apenas em uma rede pública e precisar de acesso ao banco de dados. Consulte o diagrama e a descrição a seguir.

Veja a seguir a descrição de network_exa_public_client.png
Descrição da ilustração network_exa_public_client.png

Configure:

  • Sub-redes:

    • Sub-rede de cliente Pública (pública significa que os recursos na sub-rede podem ter endereços IP públicos a seu critério).
    • Sub-rede de backupPrivada (privada significa que os recursos da sub-rede não podem ter endereços IP públicos e, portanto, não podem receber conexões de entrada da internet).

  • Gateway para a VCN:

  • Tabela de roteamento:

    • Tabela de roteamento personalizada para a sub-rede de cliente pública, com uma rota para 0.0.0.0/0 e destino = o gateway de internet.
    • Tabela de roteamento personalizada separada para a sub-rede de backup privada, com uma regra de roteamento para os labels CIDR de serviço (consulte Sobre Labels CIDR em Visão Geral dos Gateways de Serviço e Labels CIDR de Serviços Disponíveis) e destino = o gateway de serviço.
  • Regras de segurança para permitir o tráfego desejado de/para os nós de computação das máquinas virtuais do Exadata.
  • Acesso do Nó ao Object Storage: Rota Estática nos nós de computação da instância do Exadata Cloud Service (para permitir o acesso aos serviços do OCI por meio da sub-rede de backup).
Observação

Consulte esse problema conhecido para obter informações sobre como configurar regras de roteamento com o gateway de serviço como destino em tabelas de roteamento associadas a sub-redes públicas.

Tópico principal: VCN e Sub-redes

Opção 2: Sub-rede Privada

A Oracle recomenda sub-redes privadas para um sistema de produção.

Ambas as sub-redes são privadas e não podem ser acessadas pela internet. Consulte o diagrama e a descrição a seguir.

Veja a seguir a descrição de network_exa_private_client.png
Descrição da ilustração network_exa_private_client.png

Configure:

  • Sub-redes:

    • Sub-rede de cliente Privada.
    • Sub-rede de backup Privada.

  • Gateway para a VCN:

  • Tabela de roteamento:

    • Tabela de roteamento personalizada para a sub-rede de cliente privada, com as seguintes regras:

      • Uma regra para o CIDR da rede on-premises e destino = DRG.
      • Uma regra para o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network e destino = o gateway de serviço. O Oracle Services Network é uma rede conceptual no Oracle Cloud Infrastructure reservada para os serviços Oracle. A regra permite que a sub-rede do cliente acesse o repositório regional YUM da Oracle para atualizações do sistema operacional. Consulte também Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM.
      • Opcionalmente, uma regra para 0.0.0.0/0 e destino = gateway NAT.
    • Tabela de rota personalizada separada para a sub-rede de backup privada, com uma regra:
      • A mesma regra da sub-rede do cliente: para o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network e destino = o gateway de serviço. Essa regra permite que a sub-rede de backup acesse o Object Storage regional para backups.
  • Regras de segurança para ativar o tráfego desejado de/para os nós do Exadata. Consulte Regras de Segurança da instância do Exadata Cloud Service.
  • Opcionalmente, adicione uma Rota estática nos nós de computação a outros serviços do OCI (para clusters de VMs, as máquinas virtuais) para permitir o acesso, se os serviços só puderem ser acessados na sub-rede de backup e não via sub-rede do cliente, por exemplo, ao usar um Gateway NAT.

Tópico principal: VCN e Sub-redes

Requisitos de Espaço de Endereço IP

Você deve criar uma VCN com duas sub-redes e garantir que haja endereços suficientes para o tamanho do cluster de VMs.

Observação

Os endereços IP não devem se sobrepor, especialmente quando as instâncias do Exadata Cloud Infrastructure (e, portanto, VCNs) estiverem em mais de uma região.

Se você estiver configurando Clusters de VMs (e, portanto, VCNs) em mais de uma região, certifique-se de que o espaço de endereço IP das VCNs não se sobreponha. Isso é importante se você quiser configurar a recuperação de desastre com o Oracle Data Guard.

Para a sub-rede do cliente, cada nó exige quatro endereços IP e, além disso, três endereços são reservados para SCANs (Single Client Access Names). Para a sub-rede de backup, cada nó exige três endereços. O serviço Networking reserva três endereços IP em cada sub-rede.

Use a seguinte fórmula para calcular o número mínimo de endereços IP em que a variável n é o número de VMs no cluster de VMs:

O número mínimo de endereços de cliente = 4*n+6

O número mínimo de endereços de backup = 3*n+3

Observação

A alocação de um espaço maior para a sub-rede que o mínimo necessário (por exemplo, pelo menos /25 em vez de /28) pode reduzir o impacto relativo desses endereços reservados no espaço disponível da sub-rede. Para planejar o crescimento futuro, adicione endereços que você espera exigir à medida que amplia seu Cluster de VMs, não apenas o número de VMs que você planeja provisionar para necessidade imediata.

Tópico principal: VCN e Sub-redes

Configurando uma Rota Estática para Acessar o Armazenamento de Objetos
Todo o tráfego de uma instância do Oracle Exadata Database Service on Exascale Infrastructure é, por padrão, roteado pela rede de dados. Para rotear o tráfego de backup para a interface de backup (BONDETH1), é preciso configurar uma rota estática em cada um dos nós de computação do cluster.

Para obter instruções, consulte Acesso do Nó ao Object Storage: Rota Estática.

Tópico principal: VCN e Sub-redes

Configurando o DNS para um Oracle Exadata Database Service na Instância de Infraestrutura do Exascale

O DNS permite que você use nomes de host em vez de endereços IP para comunicação com uma instância do Exadata Cloud Infrastructure.

Você pode usar o Resolvedor de Internet e VCN (o recurso DNS integrado na VCN), conforme descrito em DNS na Sua Rede Virtual na Nuvem. A Oracle recomenda o uso de um Resolvedor de VCN para resolução de nome DNS da sub-rede do cliente. Ele resolve automaticamente os pontos finais Swift necessários para fazer backup de bancos de dados, aplicar patches e atualizar o conjunto de ferramentas da nuvem em uma instância do Exadata.

Tópico principal: VCN e Sub-redes

DNS: Nomes Curtos para a VCN, Sub-redes e Oracle Exadata Database Service na instância de Infraestrutura do Exascale
Para que os nós se comuniquem, a VCN deve usar o Resolvedor de Internet e VCN. O resolvedor de Internet e VCN permite a designação de nomes aos nós e a resolução de DNS deles por recursos na VCN.

O resolvedor de Internet e VCN permite a resolução de repetição alternada dos SCANs do banco de dados. Também permite a resolução de pontos finais de serviços importantes necessários para fazer backup de bancos de dados, aplicar patches e atualizar o conjunto de ferramentas da nuvem em uma instância do Oracle Exadata Database Service on Exascale Infrastructure. O Resolvedor de Internet e VCN é a opção padrão da VCN para DNS na VCN. Para obter mais informações, consulte DNS na sua Rede Virtual na Nuvem e também Opções de DHCP.

Ao criar a VCN, as sub-redes e o Exadata, defina com cuidado os seguintes identificadores que estão relacionados ao DNS na VCN:

  • Label de domínio da VCN
  • Label de domínio da sub-rede
  • Prefixo de nome de host do recurso de cluster de VMs na nuvem ou sistema de banco de dados da instância do Oracle Exadata Database Service no Exascale Infrastructure

Esses valores compõem o FQDN (nome de domínio totalmente qualificado) do nó:

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

Por exemplo:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

Neste exemplo, você designa exacs como o prefixo do nome do host ao criar o cluster de VMs na nuvem ou o sistema de banco de dados. O serviço Database inclui automaticamente um hífen e uma string de cinco letras com o número do nó no final. Por exemplo:

  • Nó 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • Nó 2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • Nó 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • E etc

Requisitos para o prefixo do nome do host:

  • Máximo recomendado: 12 caracteres. Para obter mais informações, consulte o exemplo na seção a seguir, "Requisitos para os labels de domínio da VCN e da sub-rede".
  • Não pode ser a string localhost

Requisitos para labels de domínio da VCN e da sub-rede:

  • Máximo recomendado: 14 caracteres cada. O requisito subjacente real é um total de 28 caracteres nos dois labels de domínio (excluindo o período entre os labels). Por exemplo, ambos são aceitáveis: subnetad1.verylongvcnphx ou verylongsubnetad1.vcnphx. Para simplificar, a recomendação é de 14 caracteres cada.
  • Sem hifens ou sublinhados.

  • Recomendado: inclua o nome da região no label de domínio da VCN e inclua o nome do domínio de disponibilidade no label de domínio da sub-rede.

  • Em geral, FQDN tem um limite total máximo de 63 caracteres. Veja a seguir uma regra geral segura:

    <12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

Os máximos anteriores não são impostos quando você cria a VCN e as sub-redes. No entanto, se os labels excederem o máximo, a implantação do Exadata falhará.

  • DNS: Entre Rede Local e VCN
    A Oracle recomenda o uso de um resolvedor de DNS privado para permitir o uso de nomes de host quando hosts locais e recursos de VCN se comunicarem.

Tópico principal: VCN e Sub-redes

DNS: Entre Rede On-Premises e VCN

A Oracle recomenda o uso de um resolvedor de DNS privado para permitir o uso de nomes de host quando hosts on-premises e recursos de VCN se comunicarem.

Consulte Resolvedores de DNS Privados para obter informações sobre como criar e usar resolvedores privados. Para obter uma arquitetura de referência, consulte Usar DNS privado na VCN no Oracle Architecture Center.

Configurar DNS Privado

Verifique os pré-requisitos necessários para usar o DNS Privado.

  • A view privada e a zona privada devem ser criadas antes da inicialização do provisionamento do sistema de banco de dados. Para obter detalhes, consulte Resolvedores de DNS Privados.
  • O encaminhamento para outro servidor DNS deve ser configurado antecipadamente na console do DNS. Isso pode ser feito indo para o resolvedor da VCN e criando o ponto final e depois as regras. Para obter detalhes, consulte DNS na Sua Rede Virtual na Nuvem.
  • O nome da zona privada não pode ter mais de 4 rótulos. Por exemplo, a.b.c.d é permitido enquanto a.b.c.d.e não for.
  • Também é necessário adicionar a view privada ao resolvedor da VCN. Para obter detalhes, consulte Adicionando uma View Privada a um Resolvedor.
  • Ao provisionar um Cluster de VMs do Exadata usando a funcionalidade de DNS Privado, o Exadata precisa criar zonas de DNS reversas no compartimento do Cluster de VMs do Exadata. Se o compartimento tiver tags ou padrões de tag definidos, políticas adicionais relacionadas ao gerenciamento de tags serão necessárias. Para obter detalhes, consulte:

Tópico principal: VCN e Sub-redes

Acesso do Nó ao Object Storage: Rota Estática

Para poder fazer backup de bancos de dados e aplicar patches e atualizar ferramentas de nuvem em uma instância do Oracle Exadata Database Service on Exascale Infrastructure, a Oracle recomenda que você configure o Autonomous Recovery Service. Independentemente de como você configura a VCN com esse acesso (por exemplo, com um gateway de serviço), se você usar o Object Storage, talvez também precise configurar uma rota estática para o Object Storage para cada nó de computação do cluster. Isso só é necessário se você não estiver usando backups automáticos. Se você estiver usando backups personalizados com as APIs de backup, deverá rotear o tráfego destinado ao serviço Object Storage por meio da interface de backup (BONDETH1). Isso não será necessário se você estiver usando os backups automáticos criados com a Console, APIs ou CLIs.
Observação

A partir de 06 de agosto de 2025, para tenancies criadas nas regiões FRA, PHX ou NRT, o Autonomous Recovery Service será o único destino de backup quando você ativar o backup automático em bancos de dados.

Cuidado:

Configure uma rota estática para acesso ao serviço Object Storage em cada nó de computação de uma instância do Oracle Exadata Database Service no Exascale Infrastructure se você não estiver criando backups automáticos com a Console, APIs ou CLIs. Caso contrário, as tentativas de fazer backup de bancos de dados e aplicar patches ou atualizar ferramentas no sistema poderão falhar.
Observação

Quando você ativar o primeiro backup automático para um banco de dados, a configuração de rota estática será feita automaticamente no serviço.

Se você quiser aplicar patches ao serviço antes de criar um banco de dados, a rota estática manual deverá ser capaz de aplicar patches ao Home do grid infrastructure ou do banco de dados.

A rota estática também pode ser necessária para acessar outros serviços (IAM, KMS) se não for possível acessá-los por meio da sub-rede do cliente e somente a sub-rede de backup usar a definição para acessar todos os serviços em uma região.

Alocações de IP do Object Storage

O Oracle Cloud Infrastructure Object Storage usa a faixa de IP 134.70.0.0/16 do bloco CIDR para todas as regiões.

Desde 1º de junho de 2018, o Object Storage não suporta mais as faixas de IP descontinuadas a seguir. A Oracle recomenda remover esses endereços IP mais antigos das suas listas de controle de acesso, regras de firewall e outras regras depois de adotar as novas faixas de IP.

As faixas de IP descontinuadas são:

  • Centro da Alemanha (Frankfurt): 130.61.0.0/16
  • Sul do Reino Unido ( Londres): 132.145.0.0/16
  • Leste dos EUA (Ashburn): 129.213.0.0/16
  • Oeste dos EUA (Phoenix): 129.146.0.0/16
Para configurar uma rota estática para acesso ao Object Storage

  1. Estabeleça conexão via SSH com um nó de computação na instância do Oracle Exadata Database Service on Exascale Infrastructure. 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. Faça log-in como opc e, em seguida, sudo para o usuário raiz. Use sudo su - com um hífen para chamar o perfil do usuário raiz. 

    
login as: opc
			
[opc@dbsys ~]$ sudo su -

  3. Identifique o gateway configurado para a interface BONDETH1. 

    [root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

  4. Adicione a seguinte regra estática de BONDETH1 ao arquivo /etc/sysconfig/network-scripts/route-bondeth1: 

    10.0.X.0/XX dev bondeth1 table 211
default via <gateway> dev bondeth1 table 211
134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1

  5. Reinicie a interface. 

    
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;

    As alterações do arquivo da etapa anterior ocorrem imediatamente após a execução dos comandos ifdown e ifup.

  6. Repita as etapas anteriores emcada nó de computação do Oracle Exadata Database Service na instância do Exascale Infrastructure.

Gateway de Serviço para a VCN

Sua VCN precisa acessar o Object Storage para backups e o repositório YUM da Oracle para atualizações do sistema operacional.

Tópico principal: Configuração da Rede para o Oracle Exadata Database Service em Instâncias de Infraestrutura do Exascale

Opção 1: Acesso do Gateway de Serviço aos Serviços do OCI

Configure a sub-rede de backup para usar o gateway de serviço para acesso somente ao Object Storage.

Como lembrete, aqui está o diagrama para a opção 1, configuração de rede com uma sub-rede cliente pública:

Esta imagem mostra a instalação de rede com uma sub-rede pública do cliente, conforme descrito anteriormente.

Em geral, você deve:

  • Executar as tarefas para configurar um gateway de serviço em uma VCN e ativar especificamente o label do CIDR de serviço chamado OCI <region> Object Storage.
  • Na tarefa para atualizar o roteamento, adicione uma regra de roteamento à tabela de roteamento personalizada da sub-rede de backup. Para o serviço de destino, use OCI <region> Object Storage e destino = o gateway de serviço.
  • Na tarefa para atualizar regras de segurança na sub-rede, execute a tarefa no NSG (grupo de segurança de rede) da rede de backup ou na lista de segurança personalizada. Configure uma regra de segurança com o serviço de destino definido como OCI <region> Object Storage. Consulte "Regra Obrigatória especificamente para a Rede de Backup" Regra Obrigatória especificamente para a Rede de Backup.
Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM

Você configura a sub-rede do cliente e a sub-rede de backup para usar o gateway de serviço para acesso ao Oracle Services Network, que inclui o Object Storage e o repositório do Oracle YUM.

Observação

Consulte estes problemas conhecidos para obter informações sobre como acessar os serviços YUM da Oracle por meio do gateway de serviço.

Como lembrete, aqui está o diagrama para a opção 2, uma configuração de rede com sub-redes privadas:

Esta imagem mostra a instalação de rede com sub-redes de cliente privado, conforme descrito anteriormente.

Em geral, você deve:

  • Execute as tarefas para configurar um gateway de serviço em uma VCN e ativar especificamente o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network.
  • Na tarefa para atualizar o roteamento em cada sub-rede, adicione uma regra a cada tabela de roteamento personalizada da sub-rede. Para o serviço de destino, use Todos os Serviços <região> no Oracle Services Network e destino = o gateway de serviço.
  • Na tarefa para atualizar regras de segurança da sub-rede, execute a tarefa no NSG (grupo de segurança de rede) da rede de backup ou na lista de segurança personalizada. Configure uma regra de segurança com o serviço de destino definido como OCI <region> Object Storage. Consulte Regras de Segurança. Observe que a sub-rede do cliente já tem uma regra de saída ampla que abrange o acesso ao repositório YUM.

Aqui estão alguns detalhes adicionais sobre o uso do gateway de serviço para a opção 2:

Observação

A partir de 06 de agosto de 2025, para tenancies criadas nas regiões FRA, PHX ou NRT, o Autonomous Recovery Service será o único destino de backup quando você ativar o backup automático em bancos de dados.
  • A sub-rede do cliente e a sub-rede de backup usam o gateway de serviço, mas para acessar serviços diferentes. Você não pode ativar o label do CIDR de serviço OCI <region> Object Storage e Todos os Serviços de <region> no Oracle Services Network para o gateway de serviço. Para abranger as necessidades de ambas as sub-redes, é necessário ativar Todos os Serviços de <region> no Oracle Services Network para o gateway de serviço. A VCN só pode ter um único gateway de serviço.
  • Qualquer regra de roteamento destinada a um determinado gateway de serviço deve usar um label do CIDR de serviço ativado e não um bloco CIDR como destino da regra. Isso significa que, para a opção 2, as tabelas de roteamento de ambas as sub-redes devem usar Todos os Serviços de <region> no Oracle Services Network para suas respectivas regras do gateway de serviço.
  • Diferentemente das regras de roteamento, as regras de segurança podem usar qualquer label do CIDR de serviço (se a VCN tiver ou não um gateway de serviço) ou um bloco CIDR como CIDR de origem ou destino para a regra. Portanto, embora a sub-rede de backup tenha uma regra de roteamento que use Todos os Serviços de <region> no Oracle Services Network, a sub-rede pode ter uma regra de segurança que use o OCI <region> Object Storage. Consulte Regras de Segurança da instância do Exadata Cloud Service.

Regras de Segurança do Oracle Exadata Database Service na Infraestrutura do Exascale

Esta seção lista as regras de segurança a serem usadas com o Oracle Exadata Database Service na Infraestrutura do Exascale.

As regras de segurança controlam os tipos de tráfego permitidos para a rede do cliente e a rede de backup das máquinas virtuais. As regras são divididas em três seções.

Há diferentes formas de implementar essas regras. Para obter mais informações, consulte Formas de Implementar as Regras de Segurança.
Observação

Para sistemas X8M e X9M, a Oracle recomenda que todas as portas na sub-rede do cliente estejam abertas para tráfego de entrada e saída. Esse é um requisito para a adição de mais servidores de banco de dados ao sistema.

Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Há várias regras gerais que permitem conectividade essencial para hosts na VCN.

Se você usar listas de segurança para implementar suas regras de segurança, lembre-se de que as regras a seguir serão incluídas por padrão na lista de segurança padrão. Atualize ou substitua a lista para atender às suas necessidades de segurança específicas. As duas regras do ICMP (regras gerais de entrada 2 e 3) são necessárias para o funcionamento adequado do tráfego de rede no ambiente do Oracle Cloud Infrastructure. Ajuste a regra geral de entrada 1 (a regra SSH) e a regra geral de saída 1 para permitir o tráfego apenas de/para hosts que requerem comunicação com recursos da sua VCN.

Regra de entrada geral 1: Permite o tráfego SSH de qualquer lugar

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: 0.0.0.0/0
  • Protocolo IP: SSH
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino:22

Regra de entrada geral 2: Permite mensagens de fragmentação de Descoberta de MTU do Caminho

Essa regra permite que os hosts na VCN recebam mensagens de fragmentação de Descoberta de MTU do Caminho. Sem acesso a essas mensagens, os hosts da VCN podem ter problemas de comunicação com hosts fora da VCN.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: 0.0.0.0/0
  • Protocolo IP: ICMP
  • Tipo: 3
  • Código: 4

Regra de entrada geral 3: Permite mensagens de erro de conectividade na VCN

Esta regra permite que os hosts da VCN recebam mensagens de erro de conectividade um do outro.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: O CIDR da sua VCN
  • Protocolo IP: ICMP
  • Tipo: 3
  • Código: Todos

Regra de saída geral 1: Permite todo o tráfego de saída

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de Destino 0.0.0.0/0
  • Protocolo IP: Todos

Regras Obrigatórias Especificamente para a Rede do Cliente

As regras de segurança a seguir são importantes para a rede do cliente.

Observação

  • As regras de entrada do cliente 1 e 2 abrangem somente conexões iniciadas na sub-rede cliente. Se você tiver um cliente que resida fora da VCN, a Oracle recomenda configurar duas regras semelhantes adicionais que, em vez disso, tenham o CIDR de Origem definido como o endereço IP público do cliente.
  • As regras de entrada do cliente 3 e 4 e as regras de saída do cliente 1 e 2 permitem tráfego TCP e ICMP dentro da rede do cliente e permitem que os nós se comuniquem entre si. Se a conectividade TCP falhar entre os nós, o cluster de VMs na nuvem Exadata ou o recurso do sistema de banco de dados não será provisionado.

Regra de entrada do cliente 1: Permite tráfego de ONS e FAN na sub-rede do cliente

A primeira regra é recomendada e permite que o ONS (Oracle Notification Services) se comunique sobre eventos de FAN (Fast Application Notification).

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: CIDR da sub-rede do cliente
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Intervalo de Portas de Destino: 6200
  • Descrição: Uma descrição opcional da regra.

Regra de entrada do cliente 2: Permite o tráfego SQL*NET de dentro da sub-rede do cliente

Esta regra é para tráfego SQL*NET e é necessária nestes casos:

  • Se você precisar ativar conexões de cliente com o banco de dados
  • Se você planejar usar o Oracle Data Guard,
  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: CIDR da sub-rede do cliente
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino: 1521
  • Descrição: Uma descrição opcional da regra.

Regra de Entrada do Cliente 3: Permite Aplicar Patch no Tráfego na Sub-rede do Cliente

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: CIDR da sub-rede do cliente
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Intervalo de Porta de Destino: 7085
  • Descrição: Opcionalmente, adicione uma descrição significativa da regra. Por exemplo: "Permitir acesso ao ponto final privado de Atualização da Frota do Exadata dentro da sub-rede".

Regra de saída do cliente 1: Permite todo o tráfego TCP dentro da sub-rede do cliente

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de Destino 0.0.0.0/0
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino:22
  • Descrição: Uma descrição opcional da regra.

Regra de saída do cliente 2: Permite todo o tráfego de saída (permite conexões com o repositório YUM da Oracle)

A regra de saída do cliente 3 é importante porque permite conexões com o repositório YUM da Oracle. Ela é redundante com a regra de saída geral nesse tópico (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de Destino 0.0.0.0/0
  • Protocolo IP: Todos
  • Descrição: Uma descrição opcional da regra.

Políticas de IAM Obrigatórias para Aplicação de Patch do Oracle Database e do Oracle Grid Infrastructure

Conceda políticas de IAM (Identity and Management) para acessar sub-redes, placas de interface de rede virtual (vNICs) e endereços IP privados (private-ips) para os usuários ou grupos que gerenciam o banco de dados e o Oracle Grid Infrastructure. Por exemplo, suponha que o grupo admin-group gerencie o compartimento ABC. Nesse caso, você configuraria as seguintes políticas:

  • Permitir que o grupo admin-group use sub-redes no compartimento ABC
  • Permitir que o grupo admin-group use vNICs no compartimento ABC
  • Permitir que o grupo admin-group use private-ips no compartimento ABC

Regra Obrigatória Especificamente para a Rede de Backup

A regra de segurança a seguir é importante para a rede de backup porque ela permite que o sistema de banco de dados se comunique com o Object Storage por meio do gateway de serviço (e, opcionalmente, com o repositório YUM da Oracle se a rede do cliente não tiver acesso a eles). Ela é redundante com a regra de saída geral nesse tópico (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

Regra de saída de backup: Permite acesso ao Object Storage

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: Serviço

  • Serviço de Destino:

    • O label do CIDR de serviço chamado OCI <region> Object Storage
    • Se a rede do cliente não tiver acesso ao repositório YUM da Oracle, use o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Intervalo de Portas de Destino: 443 (HTTPS)
  • Descrição: Uma descrição opcional da regra.

Tópico principal: Configuração da Rede para o Oracle Exadata Database Service em Instâncias de Infraestrutura do Exascale

Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Este tópico tem várias regras gerais que permitem a conectividade essencial para hosts na VCN.

Se você usar listas de segurança para implementar suas regras de segurança, lembre-se de que as regras a seguir serão incluídas por padrão na lista de segurança padrão. Atualize ou substitua a lista para atender às suas necessidades de segurança específicas. As duas regras do ICMP (regras gerais de entrada 2 e 3) são necessárias para o funcionamento adequado do tráfego de rede no ambiente do Oracle Cloud Infrastructure. Ajuste a regra geral de entrada 1 (a regra SSH) e a regra geral de saída 1 para permitir o tráfego apenas de/para hosts que requerem comunicação com recursos da sua VCN.

Regra de entrada geral 1: Permite o tráfego SSH de qualquer lugar
  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de origem: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocolo IP: SSH
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino:22
Regra de entrada geral 2: Permite mensagens de fragmentação de Descoberta de MTU do Caminho

Essa regra permite que os hosts na VCN recebam mensagens de fragmentação de Descoberta de MTU do Caminho. Sem acesso a essas mensagens, os hosts da VCN podem ter problemas de comunicação com hosts fora da VCN.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de origem: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocolo IP: ICMP
  • Tipo: 3
  • Código: 4
Regra de entrada geral 3: Permite mensagens de erro de conectividade na VCN

Esta regra permite que os hosts da VCN recebam mensagens de erro de conectividade um do outro.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: IPv4: o IPv4 CIDR da sua VCN, IPv6: o CIDR IPv6 da sua VCN
  • Protocolo IP: ICMP
  • Tipo: Tudo
  • Código: Todos
Regra de saída geral 1: Permite todo o tráfego de saída
  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocolo IP: Todos

Se o cliente ativar a notificação de Eventos da VM Convidada do Plano de Dados, a regra de saída padrão será suficiente.

Regras Obrigatórias Especificamente para a Rede do Cliente

As regras de segurança a seguir são importantes para a rede do cliente.

Observação

  • Para sistemas X8M, a Oracle recomenda a abertura de todas as portas na sub-rede do cliente para tráfego de entrada e saída. Esse é um requisito para a adição de mais servidores de banco de dados ao sistema.
  • As regras de entrada do cliente 1 e 2 abrangem somente conexões iniciadas na sub-rede cliente. Se você tiver um cliente que resida fora da VCN, a Oracle recomenda configurar duas regras semelhantes adicionais que, em vez disso, tenham o CIDR de Origem definido como o endereço IP público do cliente.
  • As regras de entrada do cliente 3 e 4 e as regras de saída do cliente 1 e 2 permitem tráfego TCP e ICMP dentro da rede do cliente e permitem que os nós se comuniquem entre si. Se a conectividade TCP falhar entre os nós, o cluster de VMs na nuvem Exadata ou o recurso do sistema de banco de dados não será provisionado.

Tópico principal: Regras de Segurança do Oracle Exadata Database Service na Infraestrutura do Exascale

Regra de entrada do cliente 1: Permite tráfego de ONS e FAN na sub-rede do cliente

A primeira regra é recomendada e permite que o ONS (Oracle Notification Services) se comunique sobre eventos de FAN (Fast Application Notification).

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: IPv4: IPv4 CIDR da sub-rede do cliente, IPv6: CIDR IPv6 da sub-rede do cliente
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Intervalo de Portas de Destino: 6200
  • Descrição: Uma descrição opcional da regra.
Regra de entrada do cliente 2: Permite o tráfego SQL*NET de dentro da sub-rede do cliente

Esta regra é para tráfego SQL*NET e é necessária nestes casos:

  • Se você precisar ativar conexões de cliente com o banco de dados
  • Se você planejar usar o Oracle Data Guard,
  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Origem: CIDR
  • CIDR de Origem: IPv4: IPv4 CIDR da sub-rede do cliente, IPv6: CIDR IPv6 da sub-rede do cliente
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino: 1521
  • Descrição: Uma descrição opcional da regra.
Regra de saída do cliente 1: Permite todo o tráfego TCP dentro da sub-rede do cliente

Esta regra é para tráfego do SQL*NET, conforme observado.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocolo IP: TCP
  • Intervalo de Portas de Origem: Tudo
  • Faixa de Portas de Destino:22
  • Descrição: Uma descrição opcional da regra.
Regra de saída do cliente 2: Permite todo o tráfego de saída (permite conexões com o repositório YUM da Oracle)

A regra de saída do cliente 3 é importante porque permite conexões com o repositório YUM da Oracle.

Ela é redundante com a regra de saída geral 1: Permite todo o tráfego de saída (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocolo IP: Todos
  • Descrição: Uma descrição opcional da regra.
Regra Obrigatória Especificamente para a Rede de Backup

A regra de segurança a seguir é importante para a rede de backup porque ela permite que o sistema de banco de dados se comunique com o Object Storage por meio do gateway de serviço (e, opcionalmente, com o repositório YUM da Oracle se a rede do cliente não tiver acesso a eles).

Ela é redundante com a regra de saída geral 1: Permite todo o tráfego de saída (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

Regras Obrigatórias para o Serviço Events

A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Events.

As regras de saída padrão são suficientes para permitir que a instância de computação envie métricas da instância de computação para o serviço Events.

Se a instância não tiver um endereço IP público, configure um gateway de serviço na VCN (rede virtual na nuvem). O gateway de serviço permite que a instância envie métricas de instância de computação para o serviço Events sem que o tráfego passe pela internet. Veja aqui as observações especiais para configurar o gateway de serviço para acessar o serviço Events:

  • Ao criar o gateway de serviço, ative o label de serviço chamado Todos os Serviços de <region> no Oracle Services Network. Ele inclui o serviço Events.

  • Ao configurar o roteamento da sub-rede que contém a instância, configure uma regra de roteamento com o Tipo de Destino definido como Gateway de Serviço e o Serviço de Destino definido como Todos os Serviços de <region> no Oracle Services Network.

    Para ver instruções, consulte Acesso aos Serviços Oracle: Gateway de Serviço.

Regras Obrigatórias para o Serviço Monitoring

A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Monitoring.

As regras de saída padrão são suficientes para permitir que a instância de computação envie métricas da instância de computação para o serviço Monitoring.

Se a instância não tiver um endereço IP público, configure um gateway de serviço na VCN (rede virtual na nuvem). O gateway de serviço permite que a instância envie métricas de instância de computação para o serviço Monitoring sem que o tráfego passe pela internet. Veja aqui as observações especiais para configurar o gateway de serviço para acessar o serviço Monitoring:

  • Ao criar o gateway de serviço, ative o label de serviço chamado Todos os Serviços de <region> no Oracle Services Network. Ele inclui o serviço Monitoring.

  • Ao configurar o roteamento da sub-rede que contém a instância, configure uma regra de roteamento com o Tipo de Destino definido como Gateway de Serviço e o Serviço de Destino definido como Todos os Serviços de <region> no Oracle Services Network.

    Para ver instruções, consulte Acesso aos Serviços Oracle: Gateway de Serviço.

Formas de Implementar as Regras de Segurança

Saiba como implementar regras de segurança na sua VCN usando o serviço de rede.

O serviço Networking oferece duas maneiras de implementar regras de segurança na sua VCN:

Para obter uma comparação dos dois métodos, consulte Comparação de Listas de Segurança e Grupos de Segurança de Rede.

Se você usar grupos de segurança de rede

Se você optar por usar NSGs (grupos de segurança de rede), este é o processo recomendado:

  1. Crie um NSG para a rede do cliente. Adicione as seguintes regras de segurança a esse NSG:

    • As regras listadas em "Regras Obrigatórias para a Rede do Cliente e a Rede de Backup"
    • As regras listadas em "Regras Obrigatórias Especificamente para a Rede do Cliente"

  2. Crie um NSG separado para a rede de backup. Adicione as seguintes regras de segurança a esse NSG:

    • As regras listadas em "Regras Obrigatórias para a Rede do Cliente e a Rede de Backup"
    • As regras listadas em "Regras Obrigatórias Especificamente para a Rede do Cliente"
  3. Como administrador do banco de dados, ao criar uma instância do Exadata no Exadata Database Service on Exascale Infrastructure, você deve escolher vários componentes de rede (por exemplo, qual VCN e sub-redes usar):
    • Ao escolher a sub-rede do cliente, você também poderá escolher quais NSGs deseja utilizar. Escolha o NSG da rede do cliente.
    • Ao escolher a sub-rede de backup, você também poderá escolher quais NSGs deseja usar. Escolha o NSG da rede de backup.

Em vez disso, você pode criar um NSG separado para as regras gerais. Em seguida, quando os administradores de banco de dados escolherem quais NSGs serão usados para a rede do cliente, eles escolherão o NSG geral e o NSG da rede do cliente. Da mesma forma, para a rede de backup, ele escolhe o NSG geral e o NSG da rede de backup.

Se você usar listas de segurança

Se você optar por usar listas de segurança, este é o processo recomendado:

Se você optar por usar listas de segurança, este é o processo recomendado:

  1. Configure a sub-rede do cliente para usar as regras de segurança obrigatórias:

    1. Crie uma lista de segurança personalizada para a sub-rede do cliente e adicione as regras listadas em Regras Obrigatórias Especificamente para a Rede do Cliente.

    2. Associe as duas seguintes listas de segurança à sub-rede do cliente:

  2. Configure a sub-rede de backup para usar as regras de segurança necessárias:

    1. Crie uma lista de segurança personalizada para a sub-rede de backup e adicione as regras listadas em Regra Obrigatória Especificamente para a Rede de Backup.

    2. Associe as duas seguintes listas de segurança à sub-rede de backup:

Posteriormente, quando o administrador do banco de dados criar a instância do Exadata Cloud Service, ele deverá escolher diversos componentes de rede. Quando ele selecionar a sub-rede do cliente e a sub-rede de backup que você já criou e configurou, as regras de segurança serão automaticamente aplicadas aos nós criados nessas sub-redes.

ADVERTÊNCIA:

Não remova a regra de saída padrão da lista de segurança padrão. Se você fizer isso, inclua a seguinte regra de saída de substituição na lista de segurança da sub-rede do cliente:

  • Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
  • Tipo de Destino: CIDR
  • CIDR de Destino 0.0.0.0/0
  • Protocolo IP: Todos

Requisitos de Rede para o Oracle Database Autonomous Recovery Service

O Oracle Database Autonomous Recovery Service requer uma sub-rede registrada do Recovery Service dedicada a operações de backup e recuperação na sua rede virtual na nuvem (VCN) de banco de dados.

Para usar o Recovery Service para backups, siga as etapas descritas em Configurando o Recovery Service.

Tópicos Relacionados

Tópico principal: Configuração da Rede para o Oracle Exadata Database Service em Instâncias de Infraestrutura do Exascale

Criar um Gateway de Serviço para o Object Storage

Na Console do OCI, crie um gateway de serviço para o Object Storage. O gateway de serviço é necessário para atualizações de automação e metadados de configuração.

Observação

A partir de 06 de agosto de 2025, para tenancies criadas nas regiões FRA, PHX ou NRT, o Autonomous Recovery Service será o único destino de backup quando você ativar o backup automático em bancos de dados.
  1. Abra o menu de navegação. Clique em Networking e, em seguida, clique em Redes Virtuais na Nuvem.
  2. Selecione a VCN na qual os serviços de banco de dados a serem submetidos a backup estão localizados.
  3. Na página Detalhes da Rede Virtual na Nuvem resultante, em Recursos, clique em Gateways de Serviço.
  4. Clique em Criar Gateway de Serviço e forneça os detalhes a seguir.
    1. Nome: um nome descritivo para o gateway de serviço. Ele não precisa ser exclusivo. Evite digitar informações confidenciais.
    2. Compartimento: o compartimento no qual você deseja criar o gateway de serviço, se diferente do compartimento no qual você está trabalhando no momento.
    3. Serviços: Selecione o Label CIDR de serviço, All <region> Services in Oracle Services Network, na lista drop-down.
    4. Tags: ( opção avançada) Se você tiver permissões para criar um recurso, também terá permissões para aplicar tags de formato livre a esse recurso. Para aplicar uma tag definida, você deverá ter permissões para usar o namespace de tag. Para obter mais informações sobre tags, consulte Tags de Recurso. Se você não tiver certeza se deve aplicar tags, ignore essa opção (você poderá aplicar tags posteriormente) ou pergunte ao administrador.

  5. Clique em Criar Gateway de Serviço.

    Aguarde a criação do gateway antes de continuar com a próxima etapa.

  6. Em Recursos, clique em Tabela de Roteamento

    Associação de Tabela de Roteamento: Você pode associar uma tabela de roteamento de VCN específica a esse gateway. Se você associar uma tabela de roteamento, depois o gateway sempre deverá ter uma tabela de roteamento associada a ele. Você pode modificar as regras na tabela de roteamento atual ou substituí-las por outra tabela.

  7. Clique no nome da Tabela de Roteamento que está sendo usada pela sub-rede para o Recovery Service.

  8. Na página Detalhes da Tabela de Roteamento resultante, clique em Adicionar Regras de Roteamento na seção Regras de Roteamento.

    Ao configurar um gateway de serviço para um determinado label de CIDR de serviço, você também deverá criar uma regra de roteamento que especifique esse label como o destino e o alvo como o gateway de serviço. Você deve fazer isso para cada sub-rede que precise acessar o gateway.

  9. Na caixa de diálogo Adicionar Regras de Roteamento resultante, informe os seguintes detalhes:
    1. Tipo de Destino: Gateway de Serviço.
    2. Serviço de Destino: O label CIDR de serviço ativado para o gateway. All <region> Services in Oracle Services Network
    3. Gateway de Serviço de Destino: Selecione o nome fornecido na etapa 4.
    4. Descrição: Uma descrição opcional da regra.
  10. Clique em Adicionar Regras de Roteamento.

Interoperabilidade Entre Serviços ExaDB-D e ExaDB-XS: Data Guard, Backup e Restauração

Agora você pode criar um grupo do Oracle Data Guard entre serviços de banco de dados.

Com esse recurso, você pode estabelecer o recurso de backup e restauração entre serviços para as seguintes configurações:  

  • Banco de dados principal no ExaDB-D com um ou mais bancos de dados stand-by em ExaDB-XS ou ExaDB-D.
  • Banco de dados principal no ExaDB-XS com um ou mais bancos de dados stand-by no ExaDB-D ou ExaDB-XS.
Observação

No momento desta release, o Oracle Data Guard entre serviços do Exadata Database Service on Dedicated Infrastructure e do Exadata Database Service on Exascale Infrastructure só pode ser configurado com a release do Oracle Database 23ai.

Esse recurso permite que você aproveite o potencial dos seus serviços de banco de dados em sua tenancy,

Observação

Para garantir a disponibilidade máxima, a Oracle recomenda que você coloque seus clusters de VMs de mesmo nível em uma infraestrutura diferente do Exadata do cluster de VMs principal.

Opções de Configuração do Banco de dados Stand-by

Ao adicionar um banco de dados stand-by, você pode especificar os seguintes detalhes:

  • Detalhes do Cluster de VMs de Mesmo Nível: Se o destino for ExaDB-D, você poderá selecionar a Infraestrutura do Exadata.
  • Seleção do Serviço de Destino: Escolha ExaDB-D ou ExaDB-XS. Por padrão, o serviço que inicia o grupo do Data Guard é selecionado. Se um serviço estiver indisponível na região selecionada, ele será desativado com a mensagem: 'O serviço não está disponível nesta região'.
  • Tipo de Data Guard: O grupo pode ser configurado com o Data Guard ou o Active Data Guard, e cada banco de dados stand-by pode ter outro tipo.
  • Limitação do Grupo do Data Guard: Um banco de dados principal é limitado a um grupo do Data Guard.
  • Criação do Banco de Dados Stand-by: Somente um banco de dados stand-by pode ser adicionado por vez. No entanto, os bancos de dados stand-by podem ser criados em qualquer uma das seguintes categorias sem restrições de número:
    • Dentro do mesmo serviço
    • Entre serviços
    • No mesmo Domínio de Disponibilidade (AD)
    • Entre Domínios de Disponibilidade na mesma região
    • Entre regiões

Principais Considerações para Bancos de Dados Principais e Stand-by de Serviço Cruzado

  • Os bancos de dados principal e stand-by devem usar a mesma solução de gerenciamento de chaves.
  • O Data Guard pode ser configurado no modo de proteção Desempenho Máximo ou Disponibilidade Máxima com o tipo de transporte Sincronizado ou Assíncrono, sujeito às seguintes regras:
    • Para o primeiro banco de dados stand-by:
      • O padrão é o modo Desempenho Máximo com transporte Assíncrono.
      • O modo de proteção e o tipo de transporte não podem ser alterados.
    • Para o segundo e os subsequentes bancos de dados stand-by:
      • Herda o modo de proteção do primeiro stand-by.
      • O padrão é transporte assíncrono.
      • O modo de proteção e o tipo de transporte não podem ser alterados.

Exibindo e Editando Configurações do Data Guard

  • Exiba todos os bancos de dados que fazem parte do grupo Data Guard na tabela Grupo do Data Guard, independentemente de você estar nas páginas do banco de dados principal ou stand-by.
  • Edite a configuração do Data Guard para atualizar:
    • Tipo de Data Guard: Pode ser diferente para cada banco de dados stand-by. Isso só pode ser alterado de um banco de dados stand-by.
    • Senha do administrador do banco de dados: Pode ser editada em qualquer banco de dados.
    • Modo de proteção: Pode ser alternado entre Desempenho Máximo e Disponibilidade Máxima do banco de dados principal ou de qualquer banco de dados stand-by.
    • Tipo de transporte: Só é possível alternar entre Assíncrono e Sincronização de um banco de dados stand-by.
Observação

Se o Modo de Proteção estiver definido como Disponibilidade Máxima, o sistema verificará se pelo menos um banco de dados stand-by usa o transporte Sync. Se não encontrado, será exibida uma mensagem para o erro:

"Para atingir zero perda de dados, você precisa de pelo menos um stand-by com o transporte Sync. Recomenda-se ter um stand-by com transporte Sync no mesmo serviço que o banco de dados principal."

Switchover e Failover de Bancos de Dados

  • Switchover (em qualquer banco de dados stand-by)
    • O switchover é executado sem impor uma versão principal ou uma verificação de RU (Release Update). No entanto, uma advertência será exibida se o banco de dados stand-by tiver configuração assimétrica, como contagens de nós, memória ou tipo de serviço diferentes.
  • Failover (em qualquer banco de dados stand-by)
    • O failover é executado sem impor uma versão principal ou verificação de Atualização de Release (RU). No entanto, uma advertência será exibida se o banco de dados stand-by tiver uma configuração assimétrica, como contagens de nós, memória ou tipo de serviço diferentes.

Opções de Backup e Restauração do Banco de Dados

Observação

A partir de 06 de agosto de 2025, para tenancies criadas nas regiões FRA, PHX ou NRT, o Autonomous Recovery Service será o único destino de backup quando você ativar o backup automático em bancos de dados.

  • Backups Programados e Automáticos
    • Você pode programar backups automáticos no banco de dados principal, banco de dados stand-by ou ambos.
    • Os backups do Object Storage e do Recovery Service são suportados.
    • Se os backups forem configurados nos bancos de dados principal e stand-by, eles deverão usar o mesmo tipo de destino de backup.
  • Restauração no Local do Mesmo Banco de Dados em ExaDB-XS
    Restaure e recupere um banco de dados usando um backup obtido do mesmo banco de dados em ExaDB-XS:
    • Restaure o principal usando um backup feito no banco de dados principal.
    • Restaurar o stand-by usando um backup feito no banco de dados stand-by.
  • Restauração no Local de um Banco de Dados de Mesmo Nível dentro de ExaDB-XS
    Restaure e recupere um banco de dados de mesmo nível (que não tem backups configurados) usando um backup do banco de dados de origem com o Recovery Service:
    • Cenário 1: restaure o principal usando o backup stand-by.
      • Banco de dados principal: ExaDB-XS (nenhum backup configurado)
      • Banco de dados stand-by: ExaDB-XS (backups configurados para o Recovery Service)
    • Cenário 2: restaure o stand-by usando o backup principal.
      • Banco de dados principal: ExaDB-XS (backups configurados para o Recovery Service)
      • Banco de dados stand-by: ExaDB-XS (nenhum backup configurado)
  • Restauração no Local de um Banco de Dados de Mesmo Nível entre Serviços
    Restaure e recupere um banco de dados no ExaDB-XS ou no ExaDB-D usando um backup do banco de dados de origem no serviço oposto (ExaDB-D ou ExaDB-XS) com o Recovery Service:
    • Cenário 1: Restaure um banco de dados de mesmo nível em ExaDB-XS usando um backup de ExaDB-D
      • Caso de Uso 1: Restaure o principal usando o backup stand-by.
      • Caso de Uso 2: Restaure o stand-by usando o backup principal.
    • Cenário 2: Restaure um banco de dados de mesmo nível no ExaDB-D usando um backup de ExaDB-XS
      • Caso de Uso 1: Restaure o principal usando o backup stand-by.
      • Caso de Uso 2: Restaure o stand-by usando o backup principal.

Restauração Fora do Local (Criando um Novo Banco de Dados)

  • No ExaDB-XSVocê pode criar um novo banco de dados no ExaDB-XS usando um backup do mesmo serviço.
    • Restaurar dentro de:
      • O mesmo Domínio de Disponibilidade (AD)
      • Um AD diferente dentro da mesma região
      • Uma região diferente
    • Suporta o Object Storage ou o Recovery Service como destino de backup.
  • Entre Serviços
    • Cenário 1: Crie um Novo Banco de Dados no ExaDB-D Usando um Backup do ExaDB-XS
      • Origem: ExaDB-XS (banco de dados e backups)
      • Destino: ExaDB-D (qualquer região ou AD)
      • Destino de Backup: Object Storage ou Recovery Service
    • Cenário 2: Crie um Novo Banco de Dados no ExaDB-XS Usando um Backup de ExaDB-D
      • Origem: ExaDB-D (banco de dados e backups)
      • Destino: ExaDB-XS (qualquer região ou AD)
      • Destino de Backup: Object Storage ou Recovery Service