Sobre a Clonagem do Autonomous Database on Dedicated Exadata Infrastructure

A clonagem é o processo de criar uma cópia pontual do seu Autonomous Database ou do seu conjunto de backup. Você pode usar o recurso de clonagem para configurar rapidamente um Autonomous Database com dados históricos para fins como teste, desenvolvimento ou análise.

Dica:

A velocidade da operação de clone depende do número de CPUs especificadas para o clone que você está criando. Portanto, você pode melhorar a velocidade da operação de clonagem especificando mais CPUs para o clone e, em seguida, dimensionando-a para o número desejado de CPUs (conforme descrito em Remover Recursos de CPU ou Armazenamento do Autonomous Database on Dedicated Exadata Infrastructure) após a conclusão da operação de clonagem.

Tipos de Clone

O Autonomous Database oferece suporte aos seguintes tipos de clone:
  • Clone Completo: Um clone completo cria um novo banco de dados que inclui os metadados e dados do banco de dados de origem.

  • Clone de Metadados: Este tipo de clone cria um novo banco de dados que inclui todos os metadados de esquema do banco de dados de origem, mas não os dados do banco de dados de origem.

Origens de Clonagem

Você pode criar um clone do banco de dados com base em qualquer uma das seguintes origens:
  1. Uma instância do banco de dados em execução: Você pode criar uma nova instância do banco de dados clonando uma instância do Autonomous Database.

    Ao clonar uma instância de banco de dados, você pode:
    • Escolha outro Exadata Infrastructure, Cluster de VMs do Autonomous Exadata ou Autonomous Container Database para o banco de dados clone.

    • Crie o banco de dados clone na mesma região ou em uma região diferente da origem do clone.

    • Crie o banco de dados clone na mesma tenancy ou em uma tenancy diferente da origem do clone. Um clone entre tenancies pode estar na mesma região ou em uma região diferente da origem do clone. A clonagem entre tenancies só é suportada em implantações do Oracle Public Cloud.

  2. Um backup de uma instância de banco de dados: Você pode criar uma nova instância de banco de dados clonando um backup automático do Autonomous Database, seja um backup sob demanda ou de longo prazo.

    Em uma configuração do Autonomous Data Guard, você pode clonar de um backup no local principal ou stand-by.

    Ao criar uma instância de banco de dados com base em um backup, você pode:
    • Selecione um backup em uma lista de backups dentro de um intervalo de datas ou crie um clone pontual. Os clones pontuais contêm todos os dados até um timestamp específico. O timestamp especificado deve estar dentro do período de retenção definido no nível do Autonomous Container Database.

      Observação:

      Você não pode clonar um backup de longo prazo usando a opção de clonagem Point-in-time. Os backups de longo prazo são backups manuais que podem ser retidos por no mínimo 90 dias e no máximo 10 anos. Consulte Sobre Backup e Recuperação para obter mais detalhes.
    • Escolha outro Exadata Infrastructure, Cluster de VMs do Autonomous Exadata ou Autonomous Container Database para o banco de dados clone.

    • Crie o banco de dados clone na mesma região ou em uma região diferente da origem do clone.

    • Crie o banco de dados clone na mesma tenancy ou em uma tenancy diferente da origem do clone. Um clone entre tenancies pode estar na mesma região ou em uma região diferente da origem do clone. A clonagem entre tenancies só é suportada em implantações do Oracle Public Cloud.

Depois de enviar uma solicitação de clone, o banco de dados clone será exibido como PROVISIONING até que o novo banco de dados dedicado esteja disponível. Não é possível iniciar uma nova operação de clone em um banco de dados dedicado que já está sendo clonado até que a operação atual seja concluída.

Observe também as seguintes informações sobre o banco de dados recentemente clonado:

  • As estatísticas do otimizador são copiadas do banco de dados de origem para o banco de dados clonado. Em seguida:
    • Para clones completos, os carregamentos em tabelas se comportam da mesma forma que os carregamentos em uma tabela com estatísticas já existentes.
    • Para clones de metadados, o primeiro carregamento em uma tabela limpa as estatísticas dessa tabela e atualiza as estatísticas com o novo carregamento.

    Para obter mais informações sobre Estatísticas do Otimizador, consulte Optimizer Statistics Concepts no Oracle Database 19c SQL Tuning Guide ou no Oracle Database 23ai SQL Tuning Guide.

  • As regras de gerenciamento de recursos alteradas pelo usuário no banco de dados de origem são transferidas para o banco de dados clonado.
  • Os dados de desempenho do tempo antes da operação de clonagem não estão disponíveis no banco de dados clonado.

Requisitos de Clonagem

Para clonar uma instância do Autonomous Database ou seu conjunto de backup com sucesso, os seguintes requisitos precisam ser atendidos:
  • Para clonar um Autonomous Database, você precisa do acesso necessário usando as seguintes instruções de política gravadas por um administrador, se você estiver usando a Console ou a API REST com um SDK, uma CLI ou outra ferramenta:
    Allow group <Group_Name>
    to manage autonomous-databases
    in compartment <Compartment_Name>
    Allow group <Group_Name>
    to read autonomous-container-databases
    in compartment <Compartment_Name>

    Dica:

    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 o tipo de acesso concedido e em qual compartimento você deve trabalhar.
  • O ACD (Autonomous Container Database) de destino deve estar na mesma versão do banco de dados ou em uma versão mais recente que a origem.

  • Para oferecer suporte à clonagem em implantações do Exadata Cloud@Customer, abra a Porta 1522 como parte da configuração da rede. Consulte Criar Cluster de VMs do Autonomous Exadata para obter detalhes.

  • Ao clonar de uma instância do banco de dados:
    • A chave de criptografia de origem e de destino deve ser do mesmo tipo de armazenamento de chaves.

    • A senha ADMIN especificada para o banco de dados clone deve ser diferente da senha do usuário do banco de dados ADMIN no banco de dados de origem; caso contrário, a operação de clonagem falhará.

    • Para um Clone Completo, o armazenamento mínimo que você pode especificar para o banco de dados clone é o espaço usado real do banco de dados de origem arredondado para o próximo gigabyte.

  • Ao clonar com base em um backup:
    • Você precisa de um mínimo de 4 ECPUs ou 1 OCPU no Cluster de VMs do Autonomous Exadata de destino. Você pode exibir o número de CPUs disponíveis na listagem de Clusters de VMs do Autonomous Exadata na console do Oracle Cloud Infrastructure. Consulte Exibir uma Lista de Clusters de VMs do Autonomous Exadata para obter mais detalhes.

    • A origem e o destino podem ser diferentes tipos de armazenamento de chaves para a chave de criptografia. No entanto, devem ser atendidos os seguintes requisitos:

      • Se a origem e o destino usarem chaves gerenciadas pelo cliente usando o OKV (Oracle Key Vault), eles deverão usar o mesmo destino do OKV. O Cluster de VMs do Autonomous Exadata e o Autonomous Container Database de destino exigirão acesso ao OKV (Oracle Key Vault) de origem para as chaves.

      • No Oracle Cloud, se a origem usar chaves gerenciadas pelo cliente por meio do KMS, certifique-se de que o Cluster de VMs do Autonomous Exadata de destino tenha acesso ao vault do KMS de origem durante a operação de restauração.

Requisitos de Clone entre Tenancies

APLICAÇÕES PARA: Aplicável somente Oracle Public Cloud

Para criar um clone entre tenancies com base em uma instância do Autonomous Database ou em seu conjunto de backups bem-sucedido, certifique-se de atender aos seguintes requisitos:

Observação:

Os requisitos de clone entre tenancies discutidos abaixo são necessários, além dos requisitos gerais de clone discutidos em Requisitos de Clone.
  • Execute os comandos da CLI ou da API para criar o clone entre tenancies com base na tenancy de destino.

  • Defina grupos e políticas do OCI Identity and Access Management nas tenancies de origem e destino para que você possa executar comandos para criar um clone na tenancy de destino e permitir que a tenancy de destino entre em contato com a tenancy de origem na qual a origem do clone reside. Quando essas políticas forem revogadas, a clonagem entre tenancies não será permitida.
    • Na tenancy de destino, crie um grupo (por exemplo: DestinationGroup) e adicione o(s) usuário(s) que terá(ão) permissão para criar o clone entre tenancies a esse grupo. Consulte Usando a Console para Criar um Grupo para obter orientação.

    • Na tenancy de origem, crie políticas do serviço IAM para permitir que o grupo criado na tenancy de destino (DestinationGroup) crie um clone usando uma origem de clone da tenancy de origem. Consulte Usando a Console para Criar uma Política para obter orientação.

      Por exemplo, você pode definir uma política para permitir que um usuário em DestinationGroup do DestinationTenancy leia de uma instância específica do Autonomous Database no compartimento especificado na tenancy de origem, conforme mostrado abaixo:
      define tenancy DestinationTenancy as ocid1.tenancy.oc1..unique_ID
      define group DestinationGroup as ocid1.group.region1..unique_ID
      admit group DestinationGroup of tenancy DestinationTenancy to read autonomous-database-family
             in compartment ocid1.compartment.region1..unique_ID 
             where target.id = 'oc1.autonomousdatabase.oc1..unique_ID'

      Observação:

      A política só precisa permitir acesso de leitura na instância do Autonomous Database de origem para criar um clone entre tenancies.
      A política acima especifica o seguinte:
      • Linha 1: OCID da tenancy de destino na qual você criará o clone.
      • Linha 2: OCID do grupo de destino ao qual pertence o usuário que criará o clone.
      • Linha 3: OCID do compartimento no qual a origem do clone reside e o OCID da origem do clone (instância do Autonomous Database ou um backup).

        Observação:

        A cláusula where no exemplo acima é opcional. Ele fornece uma maneira mais detalhada de conceder acesso a uma origem de clone específica.
    • Na tenancy de destino, crie políticas do serviço IAM para endossar um grupo para gerenciar a origem do clone na tenancy de origem. Consulte Usando a Console para Criar uma Política para obter orientação.

      Por exemplo:
      Define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
      Endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
      A política acima especifica o seguinte:
      • Linha 1: OCID do OCID da tenancy de origem no qual reside a origem do clone.
      • Linha 2: Especifica o grupo de destino que pode gerenciar Autonomous Databases na tenancy de origem.

      Esta política discutida no exemplo acima permite que DestinationGroup crie clones do Autonomous Database e do Autonomous Database na tenancy de origem. Você pode limitar as permissões de clonagem para que o grupo só possa clonar Autonomous Databases, mas não possa criar Autonomous Databases, ou limitar ainda mais a permissão para criar apenas um tipo específico de clone: Clone Completo ou Clone de Metadados. Consulte Permissões do IAM e Operações de API para o Autonomous Database para obter mais informações e exemplos.

Limitações do Clone

Há algumas limitações com a clonagem do Autonomous Database, conforme listado abaixo:
  • Você pode clonar um banco de dados OCPU no banco de dados OCPU ou ECPU. No entanto, você não pode clonar um banco de dados ECPU em um banco de dados OCPU.
  • Você não pode clonar um Autonomous Database com a versão 23ai em um Autonomous Database com a versão 19c e vice-versa.
  • Ao clonar de uma instância do banco de dados:
    • Para bancos de dados que usam o Autonomous Data Guard, você só pode clonar um banco de dados principal. No entanto, você pode clonar o banco de dados principal ou stand-by durante a clonagem de um backup.
    • Você pode clonar um banco de dados regular em uma instância do Autonomous Database for Developers e vice-versa. No entanto, para clonar com sucesso um banco de dados regular em um banco de dados de desenvolvedor, o espaço usado real do banco de dados de origem, arredondado para o próximo GB, deve ser 32 GB ou menos.
  • Ao clonar com base em um backup:
    • O Clone de Metadados não é suportado. Você só pode usar a opção Clone Total para criar um clone do banco de dados.

    • Você só pode ter uma operação de restauração em execução no Cluster de VMs do Autonomous Exadata de destino em um determinado momento. Em outras palavras, você não pode ter vários clones de backup criados em um único Cluster de VMs do Autonomous Exadata simultaneamente.

    • Você só poderá clonar um backup para um Autonomous Database for Developers se o espaço alocado do banco de dados de origem for 32 GB ou menos.

    • Você não pode clonar um backup de longo prazo usando a opção de clonagem Point-in-time.

    • Você pode redimensionar a CPU para um valor fracionário somente após a clonagem, se necessário. Consulte Superprovisionamento de CPU para saber mais sobre o uso de valores fracionários de CPU.

    • No Exadata Cloud@Customer:
      • Você não pode usar backups locais baseados em disco para clonagem.
      • O tempo gasto para clonar um Autonomous Database depende da Contagem de CPUs e da largura de banda da rede entre o Destino de Backup e o Autonomous Container Database de destino.
  • Clones entre tenancies:
    • Só pode ser criado usando a CLI ou as APIs REST do Autonomous Database. Essa opção não está disponível usando a Console do Oracle Cloud Infrastructure.

    • Só há suporte para implantações do Oracle Public Cloud.

    • Não há suporte para chaves gerenciadas pelo cliente na origem. Consulte Chaves de criptografia principais no Autonomous Database para obter mais informações sobre chaves gerenciadas pelo cliente.

Guias Passo a Passo

Você também pode usar a API CreateAutonomousDatabase para clonar um banco de dados. Para obter informações sobre como usar a API e assinar solicitações, consulte APIs REST e Credenciais de Segurança. Para obter informações sobre SDKs, consulte Kits de Desenvolvimento de Software e Interface de Linha de Comando.