Sobre o Autonomous Container Database

O Autonomous Container Database (ACD) é um dos quatro componentes do modelo de arquitetura de banco de dados de quatro níveis, que é a base para um Autonomous Database em uma Infraestrutura Dedicada do Exadata. Os ACDs são provisionados em um Cluster de VMs do Autonomous Exadata (AVMC) e servem como contêineres para um ou mais Autonomous Databases.

Você pode criar vários recursos ACD em um único recurso AVMC, mas deve criar pelo menos um antes de criar qualquer Autonomous Database. Para obter uma compreensão abrangente da arquitetura de quatro camadas usada com o Autonomous Database em uma Infraestrutura Dedicada do Exadata e entender o posicionamento do ACD nessa arquitetura, consulte Componentes do Autonomous Database em uma Infraestrutura Dedicada do Exadata.

Os ACDs oferecem o benefício de operar isoladamente, permitindo que você separe os Autonomous Databases pelos usos pretendidos. Por exemplo, você pode criar diferentes ACDs para fins de produção e teste ou até mesmo ter vários ACDs usando diferentes versões de banco de dados.

Embora os Administradores de Frota criem, monitorem e gerenciem ACDs, os DBAs de Aplicativos os usam principalmente para criar Autonomous Databases. Consulte Atribuições de Usuário Associadas ao Autonomous Database na Infraestrutura Dedicada do Exadata para saber mais.

Tópicos Relacionados

Requisitos do Autonomous Container Database

Requisitos de Política de IAM

Você deve ter uma conta do Oracle Cloud Infrastructure com privilégios concedidos por meio das Políticas do IAM necessárias. As políticas necessárias dependem da operação que você está executando. Para obter uma lista de políticas do serviço IAM pertencentes a Autonomous Container Databases, consulte Políticas para Gerenciar Autonomous Container Databases.

Requisitos Mínimos de Recursos

Para criar um Autonomous Container Database, você precisa de pelo menos:

8 ECPUs ou 2 OCPUs por nó
50 GB de armazenamento local por nó

Requisitos de Versão do Software Oracle Database

Para provisionar um ACD com a versão do software Oracle Database como 23ai, escolha um AVMC (Autonomous Exadata VM Cluster) baseado em ECPU que foi criado com a tag DatabaseVersion definida como 23ai.
Da mesma forma, para provisionar um ACD com a versão do software Oracle Database como 19c, escolha um Cluster de VMs do Autonomous Exadata (AVMC) cuja tag DatabaseVersion não esteja definida como 23ai.
Você não pode provisionar ACDs 19c e 23ai dentro do mesmo AVMC.

Observação:

As implementações Multicloud não exigem uma tag especial e suportarão automaticamente os bancos de dados 19c e 23ai.

Recursos de Banco de Dados Gerenciados pelo Autonomous Container Database

Os recursos a seguir do Autonomous Database podem ser definidos e gerenciados no nível do Autonomous Container Database (ACD).

Recurso do Autonomous Database	Notas	Referência Adicional
Versão do software Oracle Database Você pode definir a versão do software de banco de dados contêiner ao provisionar um ACD.	Você pode escolher a versão do software Oracle Database em uma versão de imagem base ou uma imagem de software do Autonomous Database criada com base em outro ACD. Ao selecionar a versão da imagem base, você pode escolher a versão mais recente do software Oracle Database ou seu antecessor imediato. Por exemplo: Suponha que a versão mais recente do Oracle Database suportada pelo Autonomous Database seja 19.26.0.1.0. Em seguida, a lista drop-down Selecionar imagem base lista 19.26.0.1.0 e 19.25.0.1.0 para você escolher. O ACD (Autonomous Container Databases) com a versão do software de banco de dados 23ai só pode ser provisionado em Clusters de VMs do Autonomous Exadata (AVMC) baseados em ECPU criados com as Tags apropriadas. Consulte Requisitos da Tag de Versão do Software de Banco de Dados 23ai para obter detalhes. As implementações Multicloud não exigem uma tag especial e suportarão automaticamente os bancos de dados 19c e 23ai.	-
Autonomous Data Guard A configuração do Autonomous Data Guard permite que você mantenha seus bancos de dados de produção críticos disponíveis para aplicativos de missão crítica, apesar das falhas.	Você pode ativar o Autonomous Data Guard na página Detalhes de um ACD e criar até dois ACDs stand-by. No entanto, o segundo ACD stand-by deve estar na mesma tenancy que o ACD principal. Os ACDs primários e secundários também podem ser implantados em diferentes regiões (entre regiões). Em uma configuração do Autonomous Data Guard entre regiões usando chaves ou KMS gerenciados pelo cliente, dependendo do número de Autonomous Databases no ACD principal, novas versões de chave serão geradas automaticamente para os bancos de dados stand-by no Vault entre regiões.	Proteger Bancos de Dados Críticos contra Falhas e Desastres Usando o Autonomous Data Guard
Programação de Manutenção Em geral, a Oracle programa e executa toda a manutenção da frota distribuída por cada trimestre e correções mensais de segurança de infraestrutura para vulnerabilidades com pontuações de CVSS maiores ou iguais a 7. Você pode deixar a Oracle tratar a programação da manutenção ou pode definir uma janela de manutenção específica em que a Oracle pode iniciar as operações de manutenção.	Você pode escolher entre os métodos de manutenção Contínua ou Não Contínua para um ACD. Se você escolher um método de manutenção não incremental em uma configuração do Autonomous Data Guard, haverá um período de indisponibilidade para o ACD e todos os Autonomous Databases associados até a conclusão da aplicação de patch. Opcionalmente, você também pode selecionar Ativar atualização de fuso horário. Os arquivos de fuso horário só podem ser atualizados usando o método de configuração não incremental. Você pode definir ou modificar as definições de programação de manutenção para um ACD a ser gerenciado pela Oracle ou pode definir uma programação de manutenção personalizada. Ao personalizar a programação de manutenção de um ACD, você pode optar por ignorar a aplicação de patches por um trimestre. No entanto, você não pode ignorar a aplicação de patches por dois trimestres consecutivos. Ao optar por ignorar a aplicação de patches para um trimestre, você precisa selecionar pelo menos um mês a partir desse trimestre. Isso funciona como um fallback no caso de a manutenção não ocorrer no trimestre anterior não ignorado. Nesse cenário, a Oracle executará automaticamente a manutenção no mês selecionado, mesmo que ignorar seja escolhido para esse trimestre. Você pode exibir o número de patches one-off disponíveis para um ACD em sua página Detalhes. Clicar no link Copiar ao lado dele copia todos esses números de patch one-off. Quando você reprogramar um evento de manutenção ACD que já está programado, a Oracle poderá colocá-lo em uma fila se seu recurso Exadata Infrastructure ou recurso de Cluster de VMs do Autonomous Exadata: Já estiver(em) passando por uma atualização de manutenção, ou Programado para uma atividade de manutenção simultaneamente como ACD. Você pode programar uma manutenção sob demanda para atualizar a RU (Atualização da Release) juntamente com o arquivo de fuso horário ou apenas o arquivo de fuso horário para um ACD. Você também pode optar por atualizar usando uma imagem de software de banco de dados personalizada existente. Você pode ter tempo de inatividade para seu ACD e os Autonomous Databases associados, dependendo da configuração da programação de manutenção do seu ACD.	Manutenção do Serviço Programar uma Atualização de Manutenção Trimestre
Backup e Restauração Para suportar alta disponibilidade, o Autonomous Database faz backup automático do seu banco de dados para você. O período de retenção para backups é de até 95 dias, dependendo do período/política de retenção de backup escolhido para o ACD. Você pode restaurar e recuperar o banco de dados a qualquer momento nesse período de retenção.	Uma vez ativados, os backups automáticos não podem ser desativados para um ACD. Com backups automáticos ativados, você tem opções para fazer backups entre regiões, backups de longo prazo e backups manuais. Você pode definir a política/período de retenção de backup ao provisionar um ACD ou modificá-lo posteriormente em sua página de detalhes na console do Oracle Cloud Infrastructure console. Nas implantações do Oracle Public Cloud e do Exadata Cloud@Customer: Você pode manter os backups de um ACD encerrado por até 72 horas ou até o final do período de retenção de backup. Você pode ativar o bloqueio de retenção de backup para impedir qualquer exclusão indesejada dos backups ACD e do Autonomous Database antes do período de retenção. Você pode ativar o bloqueio de retenção ao provisionar o ACD ou posterior. Uma vez ativado, você pode desativar o bloqueio de retenção dentro de 14 dias, além do qual a definição se torna permanente. Depois que o bloqueio de retenção for ativado, você só poderá aumentar o valor do período de retenção e ele não poderá ser reduzido. Todos os backups de longo prazo também serão bloqueados e não poderão ser excluídos quando o bloqueio de retenção estiver ativado. Os backups de longo prazo são automaticamente excluídos após a expiração. No entanto, no caso de implantações do Exadata Cloud@Customer, se o destino de backup for NFS, nenhum dos backups será excluído automaticamente quando um ACD for encerrado. Você precisa excluir manualmente todos os backups automáticos, manuais e de longo prazo após o encerramento do ACD e a data de expiração ter passado. Consulte Política de Retenção de Backup para obter mais detalhes sobre os valores da política de retenção de backup para diferentes implantações do Autonomous Database.	Backup e Restauração de Autonomous Databases.
Destino do Backup Um destino de backup define as propriedades necessárias para estabelecer conexão com um local de backup, e cada destino de backup deve estar acessível em seu data center nos nós de cluster de VMs.	A capacidade de escolher um destino de backup ao provisionar um ACD e os destinos de backup suportados variam de acordo com a plataforma de implantação. Consulte Destino de backup para obter mais detalhes sobre os diferentes tipos de destino de backup.	Para saber mais sobre como configurar o destino de backup NFS para o Cloud@Customer, consulte Pré-requisitos para Destinos de Backup para o Exadata Cloud@Customer. Consulte Editar Definições de Backup do Autonomous Container Database para obter instruções sobre como alterar o tipo de destino de backup após provisionar o ACD.
Utilização de Espaço do NFS	APLICA-SE A: Somente Exadata Cloud@Customer Se o tipo de destino de backup atual for NFS, a utilização do espaço NFS atual será exibida como uma porcentagem junto com um ícone de status.	Consulte Exibir Utilização do Espaço NFS para obter mais detalhes.
Atributos do Resource Management Os atributos de gerenciamento de recursos afetam como os recursos são gerenciados para consolidar mais bancos de dados ou ter a maior disponibilidade de banco de dados.	Opcionalmente, ao provisionar um ACD, você pode definir um valor adequado para os seguintes atributos de gerenciamento de recursos para atender às suas necessidades: Limite de divisão do banco de dados (CPU): O valor da CPU além do qual um Autonomous Database será aberto em vários nós. O valor padrão desse atributo é 16 para OCPUs e 64 para ECPUs. Reserva de failover de nó (%): Determina a porcentagem de CPUs reservadas entre nós para suportar failover de nó. Os valores permitidos são 0%, 25% e 50%, sendo 50% a opção padrão. Afinidade de distribuição: Determina se um Autonomous Database deve ser aberto em um mínimo ou máximo de nós. Por padrão, Mínimo de nós é selecionado.	Para obter mais informações sobre como esses atributos ACD afetam o desempenho de seus bancos de dados, consulte Detalhes do Faturamento de CPU.
Conexões de Servidor Compartilhado A arquitetura de servidor compartilhado permite que um servidor de banco de dados permita que muitos processos de cliente compartilhem muito poucos processos de servidor, de modo que o número de usuários que podem ser suportados seja aumentado.	Ao provisionar um ACD, você pode, opcionalmente, ativar conexões de servidor compartilhado. Não é possível desativar a arquitetura de servidor compartilhado após o provisionamento do ACD.	Recursos de Conexão de Finalidades Especiais.
Chave de Criptografia Por padrão, o Autonomous Database cria e gerencia todas as chaves de criptografia principais usadas para proteger seus dados, armazenando-as em um armazenamento de chaves PKCS 12 seguro nos mesmos sistemas Exadata em que os bancos de dados residem. Se as políticas de segurança da sua empresa exigirem, o Autonomous Database poderá usar chaves que você cria e gerencia.	Ao provisionar um ACD, você pode, opcionalmente, configurar o ACD para usar chaves de criptografia gerenciadas pelo cliente em vez de chaves de criptografia gerenciadas pela Oracle. Você pode escolher entre as seguintes opções ao usar chaves de criptografia gerenciadas pelo cliente: Serviço OCI Vault: com essa opção, você seleciona um Vault e uma Chave de Criptografia Principal. Essa opção só está disponível no Oracle Public Cloud. Oracle Key Vault: Selecione um Armazenamento de Chaves com essa opção e informe um nome de grupo de Pontos Finais do OKV. Você pode usar chaves de criptografia gerenciadas pelo cliente com ACDs ativados para Autonomous Data Guard com os bancos de dados principal e stand-by localizados em diferentes domínios de disponibilidade dentro da mesma região.	Sobre Chaves de Criptografia Principais Usar BYOK (Bring Your Own Keys) no Serviço Vault Usar Chaves Gerenciadas pelo Cliente no Oracle Key Vault Alternar a Chave de Criptografia de um Autonomous Container Database.
E-mail do Contato Você pode fornecer e-mails de contato nos quais pode receber notificações operacionais, anúncios e notificações de manutenção não planejada relacionadas ao Autonomous Container Database.	A Oracle recomenda o uso do endereço de e-mail de um grupo de administradores, em vez do endereço de um indivíduo, sempre que possível, para garantir que não haja notificações ou anúncios importantes.
Full Stack Disaster Recovery O Full Stack DR é um serviço de orquestração e gerenciamento de recuperação de desastre do OCI (Oracle Cloud Infrastructure) que fornece recursos abrangentes de recuperação de desastre para todas as camadas de uma pilha de aplicativos, incluindo infraestrutura, middleware, banco de dados e aplicativo.	Você pode ativar o OCI Full Stack Disaster Recovery e usá-lo para executar operações de switchover/failover ou, opcionalmente, executar somente operações de switchover/failover do Autonomous Database no banco de dados.	Usar o OCI Full Stack Disaster Recovery no Autonomous Database na Infraestrutura Dedicada do Exadata
Cópia do Backup de Região Cruzada Você pode selecionar uma região secundária para uma cópia de seus backups. No caso de uma falha de região, você pode clonar o backup remoto do ACD para restaurar os dados. O backup de um ACD só pode ser clonado para um AVMC (Cluster de VMs do Autonomous Exadata) diferente do AVMC de origem.	APLICA-SE A: Oracle Public Cloud somente A cópia de backup entre regiões pode ser ativada durante o provisionamento de um ACD ou na página de detalhes de um ACD existente. Você não poderá ativar o backup entre regiões se o Autonomous Data Guard estiver ativado.	Sobre a Clonagem do Autonomous Container Database em uma Infraestrutura Dedicada Exadata Clonar um Autonomous Container Database

Recurso do Autonomous Database

Notas

Referência Adicional

Versão do software Oracle Database

Você pode definir a versão do software de banco de dados contêiner ao provisionar um ACD.

Você pode escolher a versão do software Oracle Database em uma versão de imagem base ou uma imagem de software do Autonomous Database criada com base em outro ACD.

Ao selecionar a versão da imagem base, você pode escolher a versão mais recente do software Oracle Database ou seu antecessor imediato. Por exemplo: Suponha que a versão mais recente do Oracle Database suportada pelo Autonomous Database seja 19.26.0.1.0. Em seguida, a lista drop-down Selecionar imagem base lista 19.26.0.1.0 e 19.25.0.1.0 para você escolher.

O ACD (Autonomous Container Databases) com a versão do software de banco de dados 23ai só pode ser provisionado em Clusters de VMs do Autonomous Exadata (AVMC) baseados em ECPU criados com as Tags apropriadas. Consulte Requisitos da Tag de Versão do Software de Banco de Dados 23ai para obter detalhes. As implementações Multicloud não exigem uma tag especial e suportarão automaticamente os bancos de dados 19c e 23ai.

Autonomous Data Guard

A configuração do Autonomous Data Guard permite que você mantenha seus bancos de dados de produção críticos disponíveis para aplicativos de missão crítica, apesar das falhas.

Você pode ativar o Autonomous Data Guard na página Detalhes de um ACD e criar até dois ACDs stand-by. No entanto, o segundo ACD stand-by deve estar na mesma tenancy que o ACD principal.

Os ACDs primários e secundários também podem ser implantados em diferentes regiões (entre regiões). Em uma configuração do Autonomous Data Guard entre regiões usando chaves ou KMS gerenciados pelo cliente, dependendo do número de Autonomous Databases no ACD principal, novas versões de chave serão geradas automaticamente para os bancos de dados stand-by no Vault entre regiões.

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

Programação de Manutenção

Em geral, a Oracle programa e executa toda a manutenção da frota distribuída por cada trimestre e correções mensais de segurança de infraestrutura para vulnerabilidades com pontuações de CVSS maiores ou iguais a 7.

Você pode deixar a Oracle tratar a programação da manutenção ou pode definir uma janela de manutenção específica em que a Oracle pode iniciar as operações de manutenção.

Você pode escolher entre os métodos de manutenção Contínua ou Não Contínua para um ACD. Se você escolher um método de manutenção não incremental em uma configuração do Autonomous Data Guard, haverá um período de indisponibilidade para o ACD e todos os Autonomous Databases associados até a conclusão da aplicação de patch. Opcionalmente, você também pode selecionar Ativar atualização de fuso horário. Os arquivos de fuso horário só podem ser atualizados usando o método de configuração não incremental.

Você pode definir ou modificar as definições de programação de manutenção para um ACD a ser gerenciado pela Oracle ou pode definir uma programação de manutenção personalizada.

Ao personalizar a programação de manutenção de um ACD, você pode optar por ignorar a aplicação de patches por um trimestre. No entanto, você não pode ignorar a aplicação de patches por dois trimestres consecutivos. Ao optar por ignorar a aplicação de patches para um trimestre, você precisa selecionar pelo menos um mês a partir desse trimestre. Isso funciona como um fallback no caso de a manutenção não ocorrer no trimestre anterior não ignorado. Nesse cenário, a Oracle executará automaticamente a manutenção no mês selecionado, mesmo que ignorar seja escolhido para esse trimestre.

Você pode exibir o número de patches one-off disponíveis para um ACD em sua página Detalhes. Clicar no link Copiar ao lado dele copia todos esses números de patch one-off.

Quando você reprogramar um evento de manutenção ACD que já está programado, a Oracle poderá colocá-lo em uma fila se seu recurso Exadata Infrastructure ou recurso de Cluster de VMs do Autonomous Exadata:

Já estiver(em) passando por uma atualização de manutenção, ou
Programado para uma atividade de manutenção simultaneamente como ACD.

Você pode programar uma manutenção sob demanda para atualizar a RU (Atualização da Release) juntamente com o arquivo de fuso horário ou apenas o arquivo de fuso horário para um ACD. Você também pode optar por atualizar usando uma imagem de software de banco de dados personalizada existente.

Você pode ter tempo de inatividade para seu ACD e os Autonomous Databases associados, dependendo da configuração da programação de manutenção do seu ACD.

Manutenção do Serviço

Programar uma Atualização de Manutenção Trimestre

Backup e Restauração

Para suportar alta disponibilidade, o Autonomous Database faz backup automático do seu banco de dados para você. O período de retenção para backups é de até 95 dias, dependendo do período/política de retenção de backup escolhido para o ACD. Você pode restaurar e recuperar o banco de dados a qualquer momento nesse período de retenção.

Uma vez ativados, os backups automáticos não podem ser desativados para um ACD. Com backups automáticos ativados, você tem opções para fazer backups entre regiões, backups de longo prazo e backups manuais.

Você pode definir a política/período de retenção de backup ao provisionar um ACD ou modificá-lo posteriormente em sua página de detalhes na console do Oracle Cloud Infrastructure console.

Nas implantações do Oracle Public Cloud e do Exadata Cloud@Customer:

Você pode manter os backups de um ACD encerrado por até 72 horas ou até o final do período de retenção de backup.
Você pode ativar o bloqueio de retenção de backup para impedir qualquer exclusão indesejada dos backups ACD e do Autonomous Database antes do período de retenção.
Você pode ativar o bloqueio de retenção ao provisionar o ACD ou posterior.
Uma vez ativado, você pode desativar o bloqueio de retenção dentro de 14 dias, além do qual a definição se torna permanente.
Depois que o bloqueio de retenção for ativado, você só poderá aumentar o valor do período de retenção e ele não poderá ser reduzido.
Todos os backups de longo prazo também serão bloqueados e não poderão ser excluídos quando o bloqueio de retenção estiver ativado.

Os backups de longo prazo são automaticamente excluídos após a expiração. No entanto, no caso de implantações do Exadata Cloud@Customer, se o destino de backup for NFS, nenhum dos backups será excluído automaticamente quando um ACD for encerrado. Você precisa excluir manualmente todos os backups automáticos, manuais e de longo prazo após o encerramento do ACD e a data de expiração ter passado.

Consulte Política de Retenção de Backup para obter mais detalhes sobre os valores da política de retenção de backup para diferentes implantações do Autonomous Database.

Backup e Restauração de Autonomous Databases.

Destino do Backup

Um destino de backup define as propriedades necessárias para estabelecer conexão com um local de backup, e cada destino de backup deve estar acessível em seu data center nos nós de cluster de VMs.

A capacidade de escolher um destino de backup ao provisionar um ACD e os destinos de backup suportados variam de acordo com a plataforma de implantação.

Consulte Destino de backup para obter mais detalhes sobre os diferentes tipos de destino de backup.

Para saber mais sobre como configurar o destino de backup NFS para o Cloud@Customer, consulte Pré-requisitos para Destinos de Backup para o Exadata Cloud@Customer.

Consulte Editar Definições de Backup do Autonomous Container Database para obter instruções sobre como alterar o tipo de destino de backup após provisionar o ACD.

Utilização de Espaço do NFS

APLICA-SE A: Somente Exadata Cloud@Customer

Se o tipo de destino de backup atual for NFS, a utilização do espaço NFS atual será exibida como uma porcentagem junto com um ícone de status.

Consulte Exibir Utilização do Espaço NFS para obter mais detalhes.

Atributos do Resource Management

Os atributos de gerenciamento de recursos afetam como os recursos são gerenciados para consolidar mais bancos de dados ou ter a maior disponibilidade de banco de dados.

Opcionalmente, ao provisionar um ACD, você pode definir um valor adequado para os seguintes atributos de gerenciamento de recursos para atender às suas necessidades:

Limite de divisão do banco de dados (CPU): O valor da CPU além do qual um Autonomous Database será aberto em vários nós. O valor padrão desse atributo é 16 para OCPUs e 64 para ECPUs.
Reserva de failover de nó (%): Determina a porcentagem de CPUs reservadas entre nós para suportar failover de nó. Os valores permitidos são 0%, 25% e 50%, sendo 50% a opção padrão.
Afinidade de distribuição: Determina se um Autonomous Database deve ser aberto em um mínimo ou máximo de nós. Por padrão, Mínimo de nós é selecionado.

Para obter mais informações sobre como esses atributos ACD afetam o desempenho de seus bancos de dados, consulte Detalhes do Faturamento de CPU.

Conexões de Servidor Compartilhado

A arquitetura de servidor compartilhado permite que um servidor de banco de dados permita que muitos processos de cliente compartilhem muito poucos processos de servidor, de modo que o número de usuários que podem ser suportados seja aumentado.

Ao provisionar um ACD, você pode, opcionalmente, ativar conexões de servidor compartilhado. Não é possível desativar a arquitetura de servidor compartilhado após o provisionamento do ACD.

Recursos de Conexão de Finalidades Especiais.

Chave de Criptografia

Por padrão, o Autonomous Database cria e gerencia todas as chaves de criptografia principais usadas para proteger seus dados, armazenando-as em um armazenamento de chaves PKCS 12 seguro nos mesmos sistemas Exadata em que os bancos de dados residem.

Se as políticas de segurança da sua empresa exigirem, o Autonomous Database poderá usar chaves que você cria e gerencia.

Ao provisionar um ACD, você pode, opcionalmente, configurar o ACD para usar chaves de criptografia gerenciadas pelo cliente em vez de chaves de criptografia gerenciadas pela Oracle.

Você pode escolher entre as seguintes opções ao usar chaves de criptografia gerenciadas pelo cliente:

Serviço OCI Vault: com essa opção, você seleciona um Vault e uma Chave de Criptografia Principal. Essa opção só está disponível no Oracle Public Cloud.
Oracle Key Vault: Selecione um Armazenamento de Chaves com essa opção e informe um nome de grupo de Pontos Finais do OKV.

Você pode usar chaves de criptografia gerenciadas pelo cliente com ACDs ativados para Autonomous Data Guard com os bancos de dados principal e stand-by localizados em diferentes domínios de disponibilidade dentro da mesma região.

Sobre Chaves de Criptografia Principais

Usar BYOK (Bring Your Own Keys) no Serviço Vault

Usar Chaves Gerenciadas pelo Cliente no Oracle Key Vault

Alternar a Chave de Criptografia de um Autonomous Container Database.

E-mail do Contato

Você pode fornecer e-mails de contato nos quais pode receber notificações operacionais, anúncios e notificações de manutenção não planejada relacionadas ao Autonomous Container Database.

A Oracle recomenda o uso do endereço de e-mail de um grupo de administradores, em vez do endereço de um indivíduo, sempre que possível, para garantir que não haja notificações ou anúncios importantes.

Full Stack Disaster Recovery

O Full Stack DR é um serviço de orquestração e gerenciamento de recuperação de desastre do OCI (Oracle Cloud Infrastructure) que fornece recursos abrangentes de recuperação de desastre para todas as camadas de uma pilha de aplicativos, incluindo infraestrutura, middleware, banco de dados e aplicativo.

Você pode ativar o OCI Full Stack Disaster Recovery e usá-lo para executar operações de switchover/failover ou, opcionalmente, executar somente operações de switchover/failover do Autonomous Database no banco de dados.

Usar o OCI Full Stack Disaster Recovery no Autonomous Database na Infraestrutura Dedicada do Exadata

Cópia do Backup de Região Cruzada

Você pode selecionar uma região secundária para uma cópia de seus backups. No caso de uma falha de região, você pode clonar o backup remoto do ACD para restaurar os dados. O backup de um ACD só pode ser clonado para um AVMC (Cluster de VMs do Autonomous Exadata) diferente do AVMC de origem.

APLICA-SE A:

Oracle Public Cloud somente

A cópia de backup entre regiões pode ser ativada durante o provisionamento de um ACD ou na página de detalhes de um ACD existente.

Você não poderá ativar o backup entre regiões se o Autonomous Data Guard estiver ativado.

Sobre a Clonagem do Autonomous Container Database em uma Infraestrutura Dedicada Exadata

Clonar um Autonomous Container Database

Operações de Gerenciamento do Autonomous Container Database

Você pode executar as operações de gerenciamento a seguir em um Autonomous Container Database.

Operação	Instruções da Tarefa
Criar um Autonomous Container Database	Criar um Autonomous Container Database
Alterar a política de retenção de backup de um Autonomous Container Database	Editar Definições de Backup do Autonomous Container Database
Criar uma imagem de software do Autonomous Database	Criar uma Imagem de Software do Autonomous Database
Editar as preferências de manutenção de um Autonomous Container Database	Atualizar Preferências de Manutenção do Autonomous Container Database
Gerenciar Configuração do Autonomous Data Guard	Gerenciar Configuração do Autonomous Data Guard
Mover um Autonomous Container Database para outro compartimento	Mover um Autonomous Container Database para Outro Compartimento
Alternar uma chave de criptografia do Autonomous Container Database	Alternar a Chave de Criptografia de um Autonomous Container Database
Reiniciar um Autonomous Container Database	Reiniciar um Autonomous Container Database
Encerrar um Autonomous Container Database	Encerrar um Autonomous Container Database
Gerenciar Contatos do Cliente para um Autonomous Container Database	Gerenciar Contatos do Cliente para um Autonomous Container Database
Exibir uma lista de Autonomous Container Databases	Exibir uma lista de Autonomous Container Databases
Exibir detalhes de um Autonomous Container Database	Exibir detalhes de um Autonomous Container Database
Exibir utilização de espaço do NFS	APLICA-SE A: Somente Exadata Cloud@Customer Exibir Utilização de Espaço do NFS

As operações listadas acima também podem ser obtidas usando a API. Consulte API para Gerenciar Autonomous Container Databases para obter referência adicional.

Monitorando o Autonomous Container Database

Você pode usar views dinâmicas de desempenho para monitorar seu Autonomous Container Database (ACD) das seguintes maneiras:

Exiba métricas em tempo real em diferentes eventos de espera e classes de espera.
Exiba snapshots históricos de métricas de classe de espera.
Exiba dados de métricas de desempenho em tempo real, históricos e resumidos.
Exiba limites de recursos e uso atual.

Para obter informações detalhadas, consulte Exibições de Desempenho Dinâmico.

Título e Informações de Copyright

Oracle e/ou suas empresas afiliadas.