Proteger Bancos de Dados Críticos contra Falhas e Desastres Usando o Autonomous Data Guard

Sobre o Autonomous Data Guard

O Autonomous Data Guard cria e mantém duas cópias completamente separadas do seu banco de dados: um banco de dados primário com o qual seus aplicativos se conectam e usam e um banco de dados stand-by que é uma cópia sincronizada do banco de dados principal. Em seguida, se o banco de dados principal ficar indisponível por algum motivo, o Autonomous Data Guard poderá converter o banco de dados stand-by no banco de dados principal e, portanto, começará a atender aos seus aplicativos.

Os bancos de dados principal e standby geralmente são chamados de bancos de dados de pareamento um do outro. Você pode ter até dois bancos de dados stand-by por Autonomous Container Database.

Observação:

Os aplicativos devem ser configurados para usar a TAC (Continuidade Transparente de Aplicativos) para obter todos os benefícios dos recursos de disponibilidade do banco de dados fornecidos pelo Autonomous Data Guard.

O diagrama a seguir mostra como cada banco de dados standby é mantido sincronizado com o banco de dados principal.

Descrição da ilustração autonomous-data-guard.eps

As alterações feitas no banco de dados principal são registradas no redo log do banco de dados principal. O Autonomous Data Guard transmite esses registros de redo como um stream pela rede para o redo log do banco de dados stand-by. Em seguida, o banco de dados stand-by aplica esses registros ao banco de dados stand-by. Dessa forma, o banco de dados stand-by é mantido sincronizado com o banco de dados principal.

A sincronização é quase instantânea, mas, como o processo descrito implica, há duas operações que consomem tempo: transportar os registros de redo para o banco de dados stand-by e aplicar os registros de redo ao banco de dados stand-by. A primeira é chamada de atraso no transporte, e a outra é chamada de atraso na aplicação. Você pode exibir valores de atraso atuais para um Autonomous Database na página Detalhes do banco de dados do Autonomous Data Guard em Recursos, em Recursos no menu lateral. Você pode exibir valores de atraso atuais em todos os Autonomous Databases em um banco de dados contêiner na página Detalhes do banco de dados contêiner de maneira semelhante.

Observação:

Com vários bancos de dados stand-by, o Transporte de Redo em Cascata não é suportado.

Configurando o Autonomous Data Guard

No Autonomous Database em uma Infraestrutura Dedicada do Exadata, você configura e gerencia o Autonomous Data Guard no nível do ACD (Autonomous Container Database). Você pode ativar o Autonomous Data Guard para ACDs já provisionados e adicionar até dois ACDs stand-by em sua página Detalhes usando a console do Oracle Cloud Infrastructure. Consulte Ativar o Autonomous Data Guard em um Autonomous Container Database e Adicionar um Segundo Autonomous Container Database Stand-by para obter instruções.

Observe o seguinte antes de configurar o Autonomous Data Guard:

Os Autonomous Databases implantados no Exadata Cloud@Customer devem ter a Porta 1522 aberta para permitir o tráfego TCP entre o banco de dados principal e o banco de dados stand-by em uma configuração do Autonomous Data Guard.
O Autonomous Data Guard não pode ser ativado em um ACD com uma execução de manutenção ativa programada nos próximos três dias. Você pode executar a manutenção ativa primeiro e depois ativar o Autonomous Data Guard ou alterar a programação de execução de manutenção para que ela não comece até que o segundo banco de dados stand-by seja adicionado.
A adição de um segundo banco de dados stand-by requer uma reinicialização não incremental automática para o primeiro banco de dados stand-by. O banco de dados principal não é afetado por essa reinicialização não incremental.

Configurar o Autonomous Data Guard com chaves gerenciadas pelo cliente

No Autonomous Database on Dedicated Exadata Infrastructure, você pode configurar e gerenciar o Autonomous Data Guard com chaves gerenciadas pelo cliente no nível do ACD (Autonomous Container Database). Você pode ativar o Autonomous Data Guard para ACDs já provisionados e adicionar até dois ACDs stand-by na respectiva página Detalhes usando a console do Oracle Cloud Infrastructure. Consulte Ativar o Autonomous Data Guard em um Autonomous Container Database e Adicionar um Segundo Autonomous Container Database Stand-by para obter instruções.

Observe o seguinte antes de configurar o Autonomous Data Guard com chaves gerenciadas pelo cliente:

Se você estiver usando o Oracle Cloud Infrastructure Key Management System (OCI KMS) e quiser ativar o Autonomous Data Guard entre Regiões, primeiro precisará replicar o vault do OCI para a região em que deseja adicionar o banco de dados stand-by. Consulte Replicando Vaults e Chaves para obter mais detalhes.

Observação:
Os vaults virtuais criados antes da introdução do recurso de replicação de vault entre regiões não podem ser replicados entre regiões. Crie um novo vault e novas chaves se você tiver um vault que precise replicar em outra região e a replicação não for suportada para esse vault. No entanto, todos os vaults privados suportam replicação entre regiões. Consulte Replicação entre regiões do vault virtual para obter detalhes.
Se você estiver usando o Oracle Key Vault (OKV) e quiser ativar o Autonomous Data Guard entre Regiões, certifique-se de ter adicionado endereços IP de Conexão ao Cluster do OKV no Armazenamento de Chaves.

Modelos do Autonomous Data Guard

A partir de março de 2025, os ACDs (Autonomous Container Databases) podem ativar o Autonomous Data Guard em sua página Detalhes e criar até dois ACDs stand-by. Com essa release, o modelo anterior de Associações do Autonomous Data Guard e as APIs associadas serão obsoletos e substituídos pelo modelo e pelas APIs novos Grupos do Autonomous Data Guard. Todos os novos ACDs provisionados após março de 2025 na console do Oracle Cloud Infrastructure (OCI) usarão automaticamente o novo modelo de Grupos do Autonomous Data Guard.

Para fazer a transição de ACDs existentes, os clientes podem migrar para o novo modelo clicando em Fazer Upgrade para Grupos do Autonomous Data Guard na página Detalhes do ACD na Console do OCI ou usando a API MigrateAutonomousContainerDatabaseDataguardAssociation.

Ao fazer upgrade:

Você alternará para a nova experiência do usuário na qual as operações do Autonomous Data Guard são executadas no recurso Autonomous Container Database, em vez do recurso Associação do Autonomous Container Database Data Guard.
Seu recurso Associações do Autonomous Data Guard é convertido em um recurso Grupos do Autonomous Data Guard com suporte a vários stand-by. Não há impacto na configuração existente do Autonomous Databases ou do Data Guard.
Ative o Autonomous Data Guard na página Detalhes do ACD após provisioná-lo para usar o recurso Autonomous Data Guard.
Inicie as operações de Switchover e Failover do ACD stand-by para o qual você deseja alternar atribuições com o ACD principal ou o failover, respectivamente.
Você alternará para as novas APIs de Grupos do Autonomous Data Guard listadas como APIs de substituição na API para Gerenciar a Configuração do Autonomous Data Guard. A API existente de Associações do Autonomous Data Guard está obsoleta e não estará disponível a partir de março de 2026.
Você deve se inscrever nos novos eventos dos Grupos do Autonomous Data Guard listados em Tipos de Evento do Autonomous Data Guard. Os eventos existentes das Associações do Autonomous Data Guard só funcionarão com a API antiga do Autonomous Data Guard Associations e ficarão obsoletos com essas APIs.

Transições e Operações de Atribuição

Depois que um ACD (Autonomous Container Database) é criado, você pode alterar a atribuição dos bancos de dados de pareamento usando uma operação de switchover ou failover. Se o failover automático estiver ativado, o Autonomous Data Guard executará automaticamente uma operação de failover sempre que o banco de dados principal ficar indisponível, por qualquer motivo.

Um switchover é uma reversão de atribuição entre o banco de dados principal e seu banco de dados stand-by. Um switchover garante que não haja perda de dados. Durante um switchover, o banco de dados principal faz a transição para a atribuição de stand-by, e o banco de dados stand-by faz a transição para a atribuição principal. Para executar uma operação de switchover, consulte Alternar Atribuições em uma Configuração do Autonomous Data Guard.

Um failover ocorre quando o banco de dados principal está indisponível. O failover resulta em uma transição do banco de dados stand-by para a atribuição principal. Se o failover automático não estiver ativado, você poderá executar um failover manual conforme descrito em Fazer Failover para o Stand-by em uma Configuração do Autonomous Data Guard.

A disponibilidade e o status do banco de dados após uma operação de failover são caracterizados por dois objetivos de recuperação:

RTO (Recovery Time Objective). O RTO é o tempo máximo necessário para que o banco de dados fique disponível para os aplicativos após um failover e está relacionado, até certo ponto, ao atraso para aplicação no momento da falha. Para o Autonomous Data Guard, o RTO é de segundos até dois minutos.
RPO. O RPO é a duração máxima da perda de dados potencial do banco de dados principal com falha e está relacionado, até certo ponto, ao atraso no transporte no momento da falha. Para o Autonomous Data Guard, o RPO é quase zero.

Após um failover, o principal com falha se torna um Stand-by Desativado e permanece indisponível para qualquer conexão de banco de dados. Você pode reativá-lo e transformá-lo em um stand-by íntegro executando uma operação de reintegração. Depois que um principal com falha for restabelecido como stand-by, você poderá executar um switchover para retorná-lo à sua atribuição principal original. Para executar uma operação de reintegração, consulte Reintegrar o Stand-by Desativado em uma Configuração do Autonomous Data Guard.

Failover Automático ou Failover de Inicialização Rápida

Com failover automático, sempre que o ACD principal ficar indisponível por causa de uma falha na região, falha no domínio de disponibilidade, falha do Exadata Infrastructure ou do AVMC (Autonomous Exadata VM Cluster) ou da falha do próprio ACD, ele fará failover automático para o ACD stand-by. Isso também é conhecido como Failover de Inicialização Rápida.

Você não pode ativar o failover automático ao configurar o Autonomous Data Guard em um ACD. O failover automático só pode ser ativado ou desativado ao atualizar as definições do Autonomous Data Guard na página Detalhes do ACD.

Observação:

O failover automático não pode ser ativado para Autonomous Databases implantados no Exadata Cloud@Customer com configuração do Autonomous Data Guard entre regiões.

Você não pode adicionar um segundo ACD stand-by com failover automático ativado para o primeiro ACD stand-by. Portanto, desative o failover automático usando Atualizar Definições do Autonomous Data Guard antes de criar o segundo ACD stand-by e reative-o posteriormente, se necessário.

Os modos de desempenho máximo e de proteção de disponibilidade máxima suportam failover automático:

No modo Disponibilidade máxima, o failover automático garante perda de dados zero.
No modo Desempenho máximo, o failover automático garante que o banco de dados stand-by não fique atrás do banco de dados principal além do valor especificado para Limite de atraso do failover de Inicialização Rápida. Por padrão, o Limite de atraso de failover de Inicialização Rápida é definido como 30 segundos e só se aplica ao modo de Desempenho máximo. Nesse caso, o failover automático só será possível quando o lag de aplicação (perda potencial de dados) do stand-by não exceder o limite de lag configurado. Você pode modificar o limite de atraso de failover de Início Rápido para qualquer valor entre 5 e 3600.

Consulte Atualizar Definições do Autonomous Data Guard para obter mais detalhes.

Além de falhas de hardware, interrupções do domínio de disponibilidade e interrupções regionais, há mais algumas condições de integridade do banco de dados que podem acionar um Failover de Inicialização Rápida, conforme listado abaixo:

Condição de Integridade do Banco de Dados	Descrição
Arquivo de Controle Corrompido	O arquivo de controle está permanentemente danificado devido a uma falha no disco.
Dicionário Corrompido	Corrompimento do dicionário de um banco de dados crítico. No momento, esse estado só pode ser detectado quando o banco de dados está aberto.
Erros de Gravação do Arquivo de Dados	Erros de gravação são encontrados em qualquer arquivo de dados, incluindo arquivos temporários, arquivos de dados do sistema e arquivos de undo.

Como resultado do failover automático, a atribuição do banco de dados principal com falha torna-se Stand-by Desativado e, após um breve período, o banco de dados stand-by assume a atribuição do banco de dados principal. Após a conclusão do failover automático, uma mensagem é exibida na página de detalhes do banco de dados stand-by desativado, informando que ocorreu o failover.

Depois que o serviço resolver os antigos problemas do Autonomous Container Database principal, você poderá executar um switchover manual para retornar os dois bancos de dados às atribuições iniciais. Depois de provisionar o banco de dados stand-by, você poderá executar várias tarefas de gerenciamento relacionadas ao banco de dados stand-by, incluindo:

Fazer switchover manualmente de um banco de dados principal para um banco de dados stand-by.
Fazer failover manualmente de um banco de dados principal para um banco de dados stand-by.
Restabelecer um banco de dados principal para a atribuição stand-by após o failover.
Encerrando um banco de dados stand-by.

Em uma configuração do Autonomous Data Guard com vários bancos de dados stand-by e failover automático:

Os failovers manuais exigem que você restabeleça manualmente o banco de dados principal original, que se torna o novo banco de dados stand-by.
Sempre que ocorre um failover automático, o Autonomous Database na Infraestrutura Dedicada do Exadata tenta restabelecer o principal antigo como stand-by. No entanto, se essa tentativa falhar, ela deverá ser reintegrada manualmente.

Banco de Dados Stand-by de Snapshot

Um banco de dados stand-by snapshot é um stand-by totalmente atualizável criado por meio da conversão de um Autonomous Container Database (ACD) stand-by em um ACD stand-by snapshot. Consulte Converter Stand-by Físico em Snapshot Stand-by para obter instruções passo a passo.

Um banco de dados stand-by snapshot recebe e arquiva, mas não se aplica, dados de redo do banco de dados principal. No entanto, isso aumenta o RTO (Recovery Time Objective) porque as alterações em tempo real do banco de dados principal não são aplicadas.

O recurso stand-by snapshot suporta vários casos de uso, mas aqui estão os principais casos de uso;

Conecte instâncias de aplicativos principais e stand-by a bancos de dados principais e stand-by no modo de leitura e gravação para executar configurações iniciais.
Aplique patch no banco de dados stand-by snapshot primeiro e teste com sua instância de aplicativo stand-by para confirmar a estabilidade do patch. Isso requer a conversão do stand-by físico em um stand-by snapshot primeiro, para que o patch possa ser aplicado no stand-by snapshot.

Observação:

Você não pode converter um Autonomous Container Database standby físico em um standby snapshot com o failover automático ativado.

Ao converter para um stand-by snapshot, você pode ativar novos serviços de banco de dados ativos apenas no modo snapshot ou usar o mesmo conjunto de serviços usados com o banco de dados principal. No entanto, a ativação dos serviços de banco de dados principal no banco de dados stand-by snapshot pode resultar em solicitações de conexão stand-by snapshot encaminhadas ao banco de dados principal ou vice-versa se você usar strings de conexão de banco de dados incorretas. Portanto, você deve ter cuidado para usar a string de conexão apropriada ao estabelecer conexão com o banco de dados stand-by principal e de snapshot.

Observação:

Quando você cria novos serviços com stand-by snapshot, as wallets de todos os Autonomous Databases no ACD stand-by snapshot são atualizadas. Para acessar o banco de dados, recarregue as wallets de Autonomous Databases stand-by e use strings de conexão stand-by snapshot.

Você pode converter o ACD stand-by snapshot de volta em um ACD stand-by físico do OCI (Oracle Cloud Infrastructure) manualmente. Consulte Converter Snapshot Stand-by em Stand-by Físico para obter instruções detalhadas. Se um stand-by de snapshot não for convertido manualmente em um stand-by físico, ele será convertido automaticamente de volta para um stand-by físico após 7 dias de sua criação. Em qualquer caso, a conversão do stand-by snapshot de volta para um stand-by físico descartará todas as atualizações locais para seus bancos de dados stand-by snapshot e aplicará os dados de redo recebidos dos bancos de dados principais.

Quando um ACD stand-by está no modo stand-by snapshot, você não pode executar as seguintes operações no ACD principal:

Criar ou encerrar Autonomous Databases
Amplie ou reduza Autonomous Databases
Restaurar Autonomous Databases

Se a situação exigir, você poderá failover manualmente para um stand-by snapshot do banco de dados principal. Nesse caso, o failover converte seu banco de dados stand-by snapshot em um banco de dados stand-by físico, descartando todas as atualizações locais feitas em seu stand-by snapshot e aplicando dados do banco de dados principal. Consulte Fazer Failover para o Stand-by em uma Configuração do Autonomous Data Guard para obter instruções passo a passo.

Não é permitido um switchover entre o banco de dados principal e seu banco de dados stand-by snapshot. Você deve converter manualmente seu stand-by snapshot em um stand-by físico antes de tentar um switchover.

Acessando Bancos de Dados Stand-by de Aplicativos Cliente

Em uma configuração do Autonomous Data Guard, os aplicativos clientes normalmente se conectam e executam operações no banco de dados principal.

Conectando-se com o Banco de Dados Stand-by Físico

Além dessa conectividade normal, o Autonomous Data Guard fornece a você a opção de conectar aplicativos clientes que executam operações somente para leitura no banco de dados stand-by. Para aproveitar essa opção, os aplicativos clientes se conectam ao banco de dados usando nomes de serviço de banco de dados que incluem "_RO" (para "somente para leitura"), conforme descrito em Nomes de Serviço de Banco de Dados Predefinidos para Autonomous Databases.

Conectando-se com o Banco de Dados Stand-by Snapshot

O Autonomous Data Guard também permite que você conecte aplicativos clientes que executam operações de leitura/gravação ao banco de dados stand-by snapshot. Essas operações são locais para o banco de dados stand-by snapshot e não modificam seu banco de dados principal. Para estabelecer conexão com um banco de dados stand-by snapshot, os aplicativos cliente podem usar nomes de serviço de banco de dados que incluem "_SS" (para "standby snapshot"), conforme descrito em Nomes de Serviço de Banco de Dados Predefinidos para Autonomous Databases.

Observação:

Quando o banco de dados stand-by está no modo stand-by snapshot, todos os serviços de banco de dados que incluem os serviços "_RO" em seu nome estão inativos e não podem ser usados para conexões.

Monitorando Tempos de Espera

À medida que seus bancos de dados que usam o Autonomous Data Guard estão em execução, você pode monitorar o atraso no transporte e aplicar tempos de espera na página Detalhes do banco de dados (ou do banco de dados contêiner) escolhendo Associações do Autonomous Data Guard em Recursos no menu lateral. Você também pode usar a console do OCI ou APIs de observabilidade para monitorar o atraso de transporte e configurar alarmes e notificações. Consulte Observabilidade do Banco de Dados com Métricas do Autonomous Database para obter mais informações.

Você deve esperar pequenas flutuações ao longo do tempo à medida que a carga de trabalho em seu banco de dados diminui e flui. No entanto, se você notar uma tendência crescente no tempo de espera, poderá executar estas ações para resolver a situação:

Tendência Crescente no Atraso para Aplicação. Uma tendência crescente no atraso para aplicação indica que o banco de dados stand-by não tem capacidade suficiente para acompanhar os registros de redo provenientes do banco de dados principal. Para resolver essa situação, expanda as OCPUs do banco de dados, conforme descrito em Adicionar Recursos de CPU ou Armazenamento a um Autonomous Database Dedicado.
Tendência Crescente de Atraso no Transporte Uma tendência crescente de atraso no transporte indica um problema de desempenho da rede. A equipe de operações do Oracle Cloud monitora constantemente o desempenho da rede, para que você consiga ver a situação se resolver sem adotar nenhuma medida. No entanto, se quiser, você poderá levar a situação ao conhecimento da equipe de operações gerando uma solicitação de serviço, conforme descrito em Criar uma Solicitação de Serviço no My Oracle Support.

Opções de Configuração do Autonomous Data Guard

Ao criar um Autonomous Container Database com o Autonomous Data Guard ativado, você especifica em qual Exadata Infrastructure e recursos de Cluster de VMs do Autonomous Exadata você deseja que o banco de dados stand-by seja criado e especifica qual modo de proteção de dados você deseja usar.

Você tem as seguintes opções ao especificar quais recursos Exadata Infrastructure e de Cluster de VMs do Autonomous Exadata devem ser usados para o stand-by:

Em outra região do Exadata Infrastructure e do Cluster de VMs do Autonomous Exadata do banco de dados principal:
Essa opção oferece o mais alto nível de proteção contra desastres, incluindo uma perda catastrófica da conectividade de rede externa ou de energia para toda uma região.

Para fazer o melhor uso dessa proteção entre regiões, sua camada de aplicativos também precisa ser configurada para oferecer suporte à proteção entre regiões. Portanto, a Oracle recomenda que você escolha essa opção se sua camada de aplicativos já estiver configurada dessa forma ou se estiver disposto a reconfigurá-la para oferecer suporte à proteção entre regiões.

Se você optar por localizar o banco de dados standby em outra região, a Oracle recomenda que você use o modo de proteção Desempenho Máximo.
Em outro domínio de disponibilidade (AD) do Exadata Infrastructure e do Cluster de VMs do Autonomous Exadata do banco de dados principal:
Essa opção fornece um alto nível de proteção contra desastres, incluindo uma perda catástrofe da conectividade de rede externa ou de energia para um domínio de disponibilidade em uma região.

Essa opção oferece um bom equilíbrio entre a proteção de dados e a simplicidade da configuração em sua camada de aplicativos.

Se você optar por localizar o banco de dados standby em outro domínio de disponibilidade, a Oracle recomenda que você use o modo de proteção Disponibilidade Máxima.
No mesmo domínio de disponibilidade (AD) que o Exadata Infrastructure e o Cluster de VMs do Autonomous Exadata do banco de dados principal:
Esta opção fornece um nível mínimo de proteção contra desastres, e a Oracle recomenda que você não a escolha.

Se os recursos Exadata Infrastructure e de Cluster de VMs do Autonomous Exadata do banco de dados principal estiverem em uma região que só tenha um domínio de disponibilidade, a Oracle recomenda que você use a opção "em outra região".

Se você optar por localizar o banco de dados stand-by no mesmo domínio de disponibilidade, a Oracle recomenda que você use o modo de proteção Disponibilidade Máxima.
Em outra tenancy do Exadata Infrastructure e do Cluster de VMs do Autonomous Exadata do banco de dados principal:
APLICAÇÕES PARA: somente Oracle Public Cloud

Essa opção permite adicionar um banco de dados stand-by de outra tenancy, permitindo o failover ou switchover do banco de dados para esse banco de dados stand-by entre tenancies. Você também pode criar um stand-by snapshot na tenancy remota. Ter um banco de dados stand-by entre tenancies pode ser útil com a migração do banco de dados entre tenancies.

Bancos de dados stand-by entre tenancies:
- Pode ser ativado com o modelo de computação ECPU ou OCPU. O banco de dados standby deve usar o mesmo modelo de computação que o principal.
- Não suporta failover automático. Em vez disso, você só pode usar um failover manual.
- Não pode ser adicionado usando a console do Oracle Cloud Infrastructure. Você só pode adicionar um banco de dados stand-by entre tenancies usando a CLI ou a API REST.

Sobre os Modos de Proteção

O Autonomous Data Guard fornece estes modos de proteção de dados:

Disponibilidade Máxima. Este modo de proteção fornece o mais alto nível de proteção de dados possível sem comprometer a disponibilidade do banco de dados principal.

O banco de dados principal não faz commit das transações até que ele receba confirmação de que os dados foram recebidos no stand-by (não de que foram gravados no disco). Se o banco de dados principal não receber essa confirmação em 30 segundos, ele funcionará como se estivesse no modo de desempenho máximo, para preservar a disponibilidade do banco de dados principal, até receber novamente as confirmações em tempo hábil.

Esse modo de proteção garante que não haja qualquer perda de dados, exceto no caso de determinadas falhas duplas, como falha de um banco de dados principal após falha do banco de dados stand-by.
Desempenho Máximo. Esse é o modo de proteção padrão. Ele fornece o mais alto nível de proteção de dados possível sem afetar o desempenho do banco de dados principal.

O banco de dados principal faz commit das transações assim que todos os dados de redo gerados por essas transações forem gravados em seu redo log on-line. Ele também envia dados de redo para o banco de dados stand-by, mas isso é feito de forma assíncrona com relação ao commit da transação; portanto, o desempenho do banco de dados principal não é afetado pelos atrasos na gravação dos dados de redo para o banco de dados stand-by.

Esse modo de proteção oferece um pouco menos proteção de dados do que o modo de disponibilidade máxima e tem impacto mínimo no desempenho do banco de dados principal.

Você pode alterar o modo de proteção em uma configuração do Autonomous Data Guard na console do OCI (Oracle Cloud Infrastructure). Consulte Atualizar Definições do Autonomous Data Guard para obter instruções passo a passo.

Para obter mais informações sobre modos de proteção no Oracle Data Guard (que são a base do recurso Autonomous Data Guard), consulte Modos de Proteção do Oracle Data Guard em Conceitos e Administração do Oracle Data Guard.

Melhores Práticas ao Configurar o Autonomous Data Guard

Embora o Autonomous Database permita criar até dois ACDs stand-by com o Autonomous Data Guard, você pode optar por usar um ou vários ACDs stand-by, dependendo do seu requisito. No entanto, para usar a opção de recuperação de desastre mais resiliente oferecida por um Autonomous Database, você pode adicionar um ACD stand-by local e um ACD stand-by remoto ou entre regiões com disponibilidade máxima como modo de proteção de dados.

Vamos entender os benefícios deste design:

Stand-by Local:
- O failover automático para um stand-by local na mesma região fornece isolamento de desastre local significativo e simplicidade de failover do aplicativo.
- O valor comercial de um banco de dados stand-by local é visto em failover de perda de dados zero e tempo de inatividade do aplicativo reduzido para segundos.
- Os aplicativos fazem failover de forma automática e transparente para o stand-by local, mantendo a mesma latência entre os servidores de aplicativos e o banco de dados. Isso é particularmente importante para aplicativos OLTP e de pacote porque uma maior latência pode afetar significativamente o throughput e o tempo geral de resposta dos aplicativos.
Stand-by Remoto:
- Se um desastre regional tornar inacessíveis os sistemas stand-by principal e local, o aplicativo e o banco de dados poderão fazer failover para o stand-by remoto.
- Embora o tempo de inatividade do banco de dados ainda seja muito baixo quando ocorre um desastre regional, o tempo de inatividade do aplicativo pode ser maior devido à orquestração adicional necessária para operações de failover de DNS, aplicativo e banco de dados para a região secundária.
Disponibilidade Máxima:
- Se o failover automático ou o FSFO (Fast Start Failover) estiver ativado, sempre que o ACD principal ficar indisponível, o Autonomous Data Guard fará failover para o stand-by local com zero perda de dados e nenhuma alteração na latência do banco de dados no aplicativo.
- Se o failover automático ou o FSFO (Fast Start Failover) estiver ativado, sempre que toda a região principal ficar inacessível, o sistema fará failover para o stand-by remoto com uma possível perda de dados.

Como o Autonomous Data Guard Afeta as Operações de Gerenciamento Padrão

Em alguns casos, as operações de gerenciamento padrão executadas nos Autonomous Container Databases funcionam de forma diferente nos bancos de dados contêineres principal e stand-by em uma configuração do Autonomous Data Guard em comparação com os bancos de dados contêiner padrão. A lista a seguir descreve essas diferenças.

Alterar a programação de manutenção
A programação de manutenção de um banco de dados contêiner principal e seu stand-by estão vinculados: a manutenção no banco de dados stand-by é realizada alguns dias antes da manutenção no banco de dados principal. O padrão é 7 dias; você pode escolher de 1 a 7 dias ao criar o banco de dados contêiner principal ou posteriormente editando seus Detalhes de Manutenção.
Alterar o tipo de manutenção
O tipo de manutenção de um banco de dados contêiner principal e seu stand-by deve ser o mesmo. Você escolhe o tipo de manutenção para os bancos de dados principal e stand-by ao criar o banco de dados contêiner principal ou, posteriormente, editando seus Detalhes de Manutenção.
Desativar backups automáticos
Você não pode desativar backups automáticos ao provisionar um ACD (Autonomous Container Database) com o Autonomous Data Guard.
Gerenciar a manutenção programada
Você pode gerenciar a manutenção programada de um banco de dados contêiner principal e seu stand-by separadamente. No entanto, como a manutenção dos dois está vinculada, você deve executar a manutenção programada no stand-by antes de executá-la no principal se optar por substituir o horário de manutenção programado.
Mover para outro compartimento
Você pode mover bancos de dados contêineres principal e stand-by para diferentes compartimentos de forma separada e independente, como se eles fossem bancos de dados contêiner padrão. No entanto, como acontece com os bancos de dados contêineres padrão, você deve ter muito cuidado ao mover um banco de dados contêiner para garantir que o banco de dados contêiner permaneça acessível aos grupos apropriados de usuários de nuvem.
Reiniciar
Você pode reiniciar bancos de dados contêineres principal e stand-by separadamente e de forma independente, como se eles fossem bancos de dados contêineres padrão.
Alternar a chave de criptografia
Você pode rotacionar as chaves de criptografia do ACD principal ou do banco de dados principal.
Encerrar
Você pode encerrar bancos de dados contêiner principais e stand-by separadamente. No entanto, as consequências de encerrar um banco de dados contêiner principal e encerrar um banco de dados contêiner stand-by diferem:
- O encerramento de um banco de dados contêiner principal encerra os bancos de dados contêiner principal e stand-by. Não é possível encerrar um banco de dados contêiner principal que contenha bancos de dados autônomos.
- O encerramento de um banco de dados contêiner stand-by encerra o banco de dados contêiner stand-by e o remove da configuração do Autonomous Data Guard. Se ela tiver apenas um principal restante, a configuração do Autonomous Data Guard será removida, transformando o principal em um banco de dados contêiner independente.

Guias Passo a Passo

Para obter orientação passo a passo sobre como gerenciar a configuração do Autonomous Data Guard em um Autonomous Container Database, consulte:

Você também pode usar a API para exibir e gerenciar a configuração do Autonomous Data Guard. Para obter mais detalhes, consulte API para Gerenciar a Configuração do Autonomous Data Guard.