Migrar para o Oracle Exadata Database Service on Dedicated Infrastructure

Esta seção descreve como migrar suas cargas de trabalho do Oracle Exadata para o Oracle Exadata Database Service on Dedicated Infrastructure e migrar seus aplicativos VMware para o Oracle Cloud VMware Solution.

Arquitetura

Essa arquitetura mostra uma migração de bancos de dados Oracle Exadata locais e aplicativos VMware para o Oracle Exadata Database Service on Dedicated Infrastructure e a Oracle Cloud VMware Solution.

Usando o Oracle Zero Downtime Migration, automatize sua migração de banco de dados e experimente um tempo de inatividade mínimo ao migrar seus dados do local para a nuvem.

Migre seus aplicativos locais em execução em VMware para o Oracle Cloud VMware Solution usando ferramentas VMware, como HCX e vMotion. O Oracle Cloud VMware Solution oferece uma implementação totalmente automatizada de um data center definido por software (SDDC) VMware na tenancy do OCI, em execução em instâncias bare metal do OCI.

O diagrama a seguir ilustra essa arquitetura de referência.

Veja a seguir a descrição da ilustração migration-vmware-cloud-solution-exadata-dedicated-architecture.png

Descrição da ilustração mig-vmware-cloud-solution-exadata-dedicated-architecture.png

migrar-vmware-cloud-solution-exadata-dedicated-architecture.zip

Essa arquitetura suporta os seguintes componentes:

Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).
Rede virtual na nuvem (VCN) e sub-rede
Uma VCN é uma rede personalizável e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
Oracle Exadata Database Service on Dedicated Infrastructure
O Oracle Exadata Database Service on Dedicated Infrastructure fornece o Oracle Exadata Database Machine como um serviço em um data center do OCI. O serviço Oracle Exadata Database Service on Dedicated Infrastructure pode hospedar muitos bancos de dados Oracle que são executados em um ou mais clusters de VMs executados em um único rack Exadata em uma região OCI. O Oracle Exadata Database Service on Dedicated Infrastructure é uma plataforma ideal para consolidação de banco de dados.
Oracle Cloud VMware Solution SDDC (Software-Defined Data Center)
A Oracle e a VMware fizeram uma parceria para desenvolver uma implementação de SDDC (Software-Defined Data Center) certificada por VMware para uso no Oracle Cloud Infrastructure. Essa implementação, chamada Oracle Cloud VMware Solution, usa o Oracle Cloud Infrastructure para hospedar um SDDC VMware altamente disponível. Também permite a migração perfeita de todas as suas cargas de trabalho do SDDC VMware locais para o Oracle Cloud VMware Solution. O Oracle Cloud VMware Solution contém os seguintes componentes VMware:
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (opcional)
bare metal
Um Oracle Cloud VMware Solution SDDC (Software-Defined Data Center) contém servidores bare metal que hospedam o Oracle Cloud VMware Solution. O servidor bare metal suporta aplicativos que exigem altas contagens de núcleos, grandes volumes de memória e alta largura de banda (como Oracle Cloud VMware Solution). Você pode implantar o Oracle Cloud VMware Solution em servidores bare metal e configurar máquinas virtuais com melhorias de desempenho significativas em comparação com outras nuvens públicas e data centers locais.
Gateway de serviço
O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle passa pela malha da rede Oracle e nunca atravessa a internet.
Gateway de roteamento dinâmico (DRG)
O DRG é um roteador virtual que fornece um caminho para o tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.
FastConnect
O Oracle Cloud Infrastructure FastConnect fornece uma maneira fácil de criar uma conexão privada dedicada entre o seu data center e o Oracle Cloud Infrastructure. FastConnect oferece opções de largura de banda mais alta e uma experiência de rede mais confiável quando comparada com conexões baseadas em internet.
Armazenamento de arquivos
O serviço OCI File Storage é usado durante a migração lógica para importar o banco de dados migrado de um sistema de arquivos compartilhado.
Object Storage
O OCI Object Storage é usado para migração lógica e física para armazenamento temporário durante a migração.

Antes de Começar

Antes de começar, verifique as versões dos principais componentes usados nesta configuração e consulte a documentação do produto para referência posterior.

Verificar Requisitos

Certifique-se de que o banco de dados de origem esteja executando o Oracle Database versão 19.18 Enterprise Edition ou superior.
O banco de dados de destino deve ser Oracle Exadata Database Service on Dedicated Infrastructure X8 ou mais recente, no Oracle Database versão 19.18 Enterprise Edition ou mais recente.
O Oracle Zero Downtime Migration deve ser da versão 21.4 ou superior.
O armazenamento intermediário deve incluir OCI Object Storage, Oracle ZFS Storage Appliance (NAS) e OCI File Storage.

Revisar Documentação

Este manual de soluções descreve como migrar cargas de trabalho de banco de dados. Consulte a solução abaixo para saber como migrar suas cargas de trabalho VMware. Os recursos adicionais são úteis para contexto, detalhes e referência para a migração do banco de dados.

Saiba como migrar os componentes VMware da sua carga de trabalho para o Oracle Cloud VMware Solution.

Migre suas cargas de trabalho do VMware on-premises para a nuvem

Revise os recursos do Oracle Zero Downtime Migration:

Revise os recursos de migração física:

Revisar recursos de migração lógica:

Revise os recursos do Oracle Database:

Sobre Funções e Produtos Necessários

Esta solução requer os seguintes produtos:

Oracle Cloud Infrastructure Identity and Access Management
Computação do OCI
OCI Object Storage
Armazenamento de Arquivos no OCI
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

Estas são as funções necessárias para cada produto.

Nome do Produto: Função	Obrigatório para...
Oracle Cloud Infrastructure Identity and Access Management: `OCI_user`	Criar tokens de autenticação para migração física Criar chaves de API para migração lógica
Computação OCI: `admin`	Criar instância do OCI Compute para executar o software Oracle Zero Downtime Migration
OCI Object Storage: `Storage Admin`	Criar buckets do serviço OCI Object Storage para migração lógica e física
Armazenamento de Arquivos do OCI: `Storage Admin`	Criar Armazenamento de Arquivos OCI para migração lógica
Oracle Zero Downtime Migration: `opc`	Crie `zdmuser` para instalar e executar o software Oracle Zero Downtime Migration
Oracle Zero Downtime Migration: `zdmuser`	Instalar o software Oracle Zero Downtime Migration Executar o Oracle Zero Downtime Migration
Oracle Exadata: `root/sudoer user`	Montar compartilhamento do sistema de arquivos de rede do dispositivo de armazenamento conectado à rede para exportar banco de dados para migrações lógicas Ativar ssh sem senha na máquina virtual do Oracle Zero Downtime Migration Execute comandos `sudo` para instalar o agente de software do Oracle Zero Downtime Migration Execute comandos `sudo` para fazer backup ou exportar banco de dados
Banco de Dados Oracle Exadata: `sys/system`	Fazer backup de dados usando o Oracle Recovery Manager (RMAN) para migração física Executar Data Pump para exportar banco de dados para migração lógica
Oracle Exadata Database Service on Dedicated Infrastructure: `Database Admin`	Criar banco de dados de destino do Oracle Exadata Database Service on Dedicated Infrastructure
Nós de Cluster de VMs do Oracle Exadata Database Service on Dedicated Infrastructure: `opc`	Montar o compartilhamento do sistema de arquivos de rede do OCI File Storage para importar o banco de dados para migrações lógicas Ativar ssh sem senha na máquina virtual do Oracle Zero Downtime Migration Instalar o agente de software do Oracle Zero Downtime Migration Execute comandos `sudo` para restaurar ou importar banco de dados
Banco de Dados do Oracle Exadata Database Service on Dedicated Infrastructure: `sys/system`	Restaurar dados usando o Oracle Recovery Manager (RMAN) para migrações físicas Executar Data Pump para importar o banco de dados para migração lógica

Consulte Produtos, Soluções e Serviços da Oracle para obter o que você precisa.

Sobre a Migração Lógica e Física

O Oracle Zero Downtime Migration suporta dois tipos de migrações de banco de dados do Oracle Exadata para o Oracle Exadata Database Service on Dedicated Infrastructure: migração lógica e migração física.

A migração lógica usa uma combinação de Oracle Data Pump e Oracle GoldenGate, enquanto a migração física usa uma combinação de Oracle Recovery Manager (RMAN) e Oracle Data Guard. A tabela a seguir explica os cenários nos quais uma migração lógica ou física deve ser usada.

Migração Lógica	Migração Física
Recomendado quando alguns bancos de dados e/ou esquemas plugáveis são migrados.	Recomendado quando bancos de dados completos são migrados. Por exemplo, bancos de dados contêineres com todos os bancos de dados plugáveis ou lift and shift.
É possível migrar bancos de dados plugáveis (PDBs) e/ou esquemas seletivos.	Os bancos de dados contêineres serão migrados para bancos de dados contêineres, e os bancos de dados não contêineres serão migrados para bancos de dados não contêineres.
A senha `Sys` na origem e no destino pode ser diferente. Os nomes de banco de dados entre a origem e o destino podem ser diferentes.	A senha `Sys` e o nome do banco de dados na origem e no destino devem ser idênticos. DB_UNIQUE_NAME na origem e no destino devem ser diferentes.
Os bancos de dados podem ser atualizados durante a migração.	Não é possível fazer upgrade dos bancos de dados como parte da migração.

Migrar Usando Migração Lógica

Esta seção descreve como executar uma migração lógica off-line. Para migração on-line, consulte a seção Revisar Documentação.

Antes de executar sua migração, anote o seguinte:

O banco de dados de origem no Oracle Exadata não precisa ser criptografado. O Oracle Zero Downtime Migration criptografará o banco de dados de destino durante a migração.
Os bancos de dados de origem e de destino não precisam ter a mesma senha sys, senha da wallet, versão do banco de dados, nome do banco de dados e nível de patch.
O Oracle Zero Downtime Migration permite migrar determinados bancos de dados plugáveis (PDBs) e/ou esquemas para bancos de dados plugáveis no Oracle Exadata Database Service on Dedicated Infrastructure.
Um sistema de arquivos compartilhados é necessário para migrações lógicas. Durante a migração lógica, o Oracle Zero Downtime Migration não exportará os dados diretamente para o OCI Object Storage. No banco de dados Exadata de origem, o Oracle Zero Downtime Migration exporta dados para um sistema de arquivos compartilhado (sistema de arquivos de rede ou Oracle Advanced Cluster File System). Os dados exportados são então submetidos a upload para o OCI Object Storage. O Oracle Zero Downtime Migration então move os dumps de dados do OCI Object Storage para o OCI File Storage. Por fim, o Oracle Exadata Database Service on Dedicated Infrastructure pode importar os dados do OCI File Storage por meio do sistema de arquivos de rede.
O Oracle Exadata local pode executar bancos de dados de instância única e RAC. O Oracle Exadata Database Service on Dedicated Infrastructure executa bancos de dados RAC. Durante a migração do banco de dados, o Oracle Zero Downtime Migration converte a instância única em bancos de dados RAC quando necessário.
No Oracle Exadata local, o uso do Oracle Transparent Data Encryption para criptografar bancos de dados é opcional. Ao migrar bancos de dados do Exadata para o Oracle Exadata Database Service on Dedicated Infrastructure, o banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino sempre será criptografado.
As etapas a seguir pressupõem que haja conectividade de rede direta entre o Data Center em que o Oracle Exadata está instalado e a Rede Virtual na Nuvem do OCI em que o Oracle Exadata Database Service on Dedicated Infrastructure e a máquina virtual do Oracle Zero Downtime Migration estão configurados (via FastConnect ou IPSec VPN, conforme mostrado no diagrama de arquitetura).

As etapas a seguir descrevem como executar uma migração lógica off-line.

Na console do OCI, crie uma instância de computação na mesma VCN na qual o banco de dados do Oracle Exadata Database Service on Dedicated Infrastructure de destino será configurado.
Esta instância de computação pode ser qualquer configuração, com pelo menos duas OCPUs e 16 GB de RAM, executando o sistema operacional Oracle Linux 7.9. Essa máquina virtual será usada para executar o software Oracle Zero Downtime Migration.
Siga a documentação de instalação do Oracle Zero Downtime Migration na seção Revisar Documentação para fazer download e instalar o software Oracle Zero Downtime Migration 21.4 na instância de computação do OCI.
Execute o software Oracle Zero Downtime Migration como zdmuser.
Faça log-in como zdmuser na instância de computação que executa o software Oracle Zero Downtime Migration e gere um par de chaves ssh. Ative o ssh sem senha da conta zdmuser para todos os nós no banco de dados Exadata de origem (root, privilege-sudoer user) e para todos os nós de cluster de VMs na conta opc user do banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino.
Garanta que a VM do Oracle Zero Downtime Migration possa se comunicar com os hosts do banco de dados de origem usando o nome do host e o endereço IP. Verifique o seguinte:
- Modifique o resolvedor de DNS da VCN ou o arquivo /etc/hosts na VM do Oracle Zero Downtime Migration, se necessário.
- Verifique se há uma regra de segurança que permite que a VM do Oracle Zero Downtime Migration se conecte ao banco de dados de origem na porta do listener padrão 1521 e na porta ssh 22.
- Certifique-se de que a VM do Oracle Zero Downtime Migration possa acessar os hosts do Oracle Exadata Database Service on Dedicated Infrastructure de destino na porta do listener padrão 1521 e na porta ssh 22.
No Oracle ZFS Storage Appliance, ou no dispositivo de armazenamento conectado à rede, crie um compartilhamento de sistema de arquivos de rede para ser usado como um espaço reservado para os dumps de dados do banco de dados enquanto a migração avança.
Monte o compartilhamento do sistema de arquivos de rede em todos os nós do banco de dados Exadata.
Certifique-se de que todos os usuários tenham permissões de leitura, gravação e execução (rwx). Anote o ponto de montagem.
Na console do OCI, crie um Armazenamento de Arquivos do OCI.
Observe o ponto de acesso NFS, a exportação e o endereço IP. Por padrão, o endereço IP está na rede de backup do Oracle Exadata Database Service on Dedicated Infrastructure.
Use o endereço IP e exporte da etapa 7 para montar esse armazenamento de arquivos por meio do sistema de arquivos de rede em todos os nós do cluster de VMs do Oracle Exadata Database Service on Dedicated Infrastructure.
Certifique-se de que a Rede Virtual na Nuvem inclua uma política de segurança para permitir o protocolo do sistema de arquivos de rede na rede de backup do Oracle Exadata Database Service on Dedicated Infrastructure. Observe o ponto de montagem.
Crie um banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino usando a console do OCI ou a API REST. Configure o banco de dados da seguinte forma:
- O novo banco de dados de destino pode ter um nome diferente do banco de dados de origem.
- O novo banco de dados pode ser uma versão mais recente que o banco de dados de origem.
- Informe uma senha para o usuário admin. Anote a senha.
- Não selecione um destino de backup ou ative backups automáticos durante a criação do banco de dados. Essas definições podem ser ativadas após a migração do banco de dados.
Observe o OCID do banco de dados após a criação do banco de dados.
Na console do OCI, crie um bucket do OCI Object Storage se ainda não existir um.
Observe o URL Swift, o namespace de armazenamento de objetos e o nome do bucket.
Use a console do OCI para criar uma chave de API para o usuário do OCI que possui o banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino e também tem permissões para fazer upload de dados para o bucket do OCI Object Storage criado na etapa 10.
Observe o OCID do usuário, o OCID da tenancy, a impressão digital e a região do OCI. Salve as chaves privadas e públicas correspondentes em arquivos PEM. Essa chave de API será usada pelo Oracle Zero Downtime Migration para estabelecer conexão com o OCI para obter informações do banco de dados de destino durante a migração do banco de dados e fazer upload de dumps de dados para o OCI Object Storage.
Copie os arquivos PEM da etapa anterior para a VM do Oracle Zero Downtime Migration.
Faça log-in como o usuário sys no banco de dados Exadata de origem para garantir que o parâmetro Streams_Pool_Size esteja definido como pelo menos 2G, por exemplo:
```
SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;                  
```
Use o modelo de arquivo de resposta de migração lógica do Oracle Zero Downtime Migration incluído no Zero Downtime Migration para criar um arquivo de resposta para a migração. Os parâmetros-chave são:
- TARGETDATABASE_OCID: OCID do banco de dados de destino do Oracle Exadata Database Service on Dedicated Infrastructure.
- MIGRATION_METHOD: OFFLINE_LOGICAL
- DATA_TRANSFER_MEDIUM: OSS
- TARGETDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_CONNECTIONDETAILS_HOST: IP/nome do host do primeiro nó no banco de dados Exadata de origem.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: Nome do serviço do PDB de origem ou banco de dados não contêiner (não CDB). Use lsnrctl para localizar.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: OCID da Tenancy na etapa 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: OCID do Usuário na etapa 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: Impressão digital da etapa 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: Caminho do arquivo para o arquivo PEM de chave privada no servidor do Oracle Zero Downtime Migration na etapa 12.
- OCIAUTHENTICATIONDETAILS_REGIONID: ID da região do OCI para o usuário do OCI na etapa 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: Nome do serviço para o banco de dados plugável de destino no banco de dados de destino. Use lsnrctl para localizar.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/nome do host do primeiro nó no banco de dados Exadata de origem.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: Nome do serviço para o banco de dados contêiner de origem no banco de dados Exadata. Use lsnrctl para localizar).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: Ponto de montagem do sistema de arquivos de rede na etapa 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: Ponto de montagem do sistema de arquivos de rede na etapa 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE: Namespace do OCI Object Storage na etapa 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME: Nome do bucket do OCI Object Storage da etapa 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Execute um job de migração de execução seca do Oracle Zero Downtime Migration (-eval) para validar todos os pré-requisitos para migração são possíveis. Isso executa a Ferramenta Cloud Pre-Migration Advisor (CPAT) para validar se o banco de dados de origem é adequado para migração para o Oracle Exadata Database Service on Dedicated Infrastructure usando a migração lógica do Oracle Zero Downtime Migration. Resolva problemas reportados pelo CPAT antes de continuar. Por exemplo:
```
zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14 \
-eval
```
Esse comando solicita a senha do usuário sys dos bancos de dados de origem e de destino.

Após uma migração de dryrun bem-sucedida, vá para a próxima etapa.

Depois que uma migração de dryrun for bem-sucedida, execute o job do Oracle Zero Downtime Migration. Por exemplo:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14

Esse comando solicita a senha do usuário sys dos bancos de dados de origem e de destino.

Migrar Usando Migração Física

Esta seção descreve como executar uma migração física off-line. Para migração on-line, consulte a seção Revisar Documentação.

Antes de executar sua migração física, anote o seguinte:

Há um novo parâmetro para gerenciamento de criptografia de tablespace no Oracle Database 19.16. Este parâmetro pode causar conflitos para migrações físicas. Revise o Gerenciamento de Criptografia de Tablespace na seção Revisar Documentação para obter mais informações.
O Oracle Exadata local pode executar bancos de dados de instância única e RAC. O Oracle Exadata Database Service on Dedicated Infrastructure executa bancos de dados RAC. Durante a migração do banco de dados, o Oracle Zero Downtime Migration converte a instância única em bancos de dados RAC quando necessário.
Uma wallet de Criptografia Transparente de Dados (TDE) deve ser definida no banco de dados de origem antes da migração, mesmo que o banco de dados de origem não seja criptografado.
No Oracle Exadata local, o uso do Oracle Transparent Data Encryption para criptografar bancos de dados é opcional. Ao migrar bancos de dados do Exadata para o Oracle Exadata Database Service on Dedicated Infrastructure, o banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino sempre será criptografado.
As etapas a seguir pressupõem que haja conectividade de rede direta entre o Data Center em que o Exadata está instalado e a Rede Virtual na Nuvem do OCI em que o Oracle Exadata Database Service on Dedicated Infrastructure e a máquina virtual do Oracle Zero Downtime Migration estão configurados (via FastConnect ou IPSec VPN, conforme mostrado no diagrama de arquitetura).
O banco de dados de origem no Oracle Exadata não precisa ser criptografado. O Oracle Zero Downtime Migration criptografará o banco de dados de destino durante a migração.
A senha sys, a senha da wallet, a versão do banco de dados e o nível de patch nos bancos de dados de origem e de destino devem ser iguais.
O Oracle Zero Downtime Migration migrará o banco de dados contêiner (CDB) para o CDB e não para o CDB para o não CDB.
O Oracle Zero Downtime Migration usa o Oracle Database Backup Cloud Service para fazer backup do banco de dados Exadata de origem no OCI Object Storage. O Oracle Zero Downtime Migration então restaura o banco de dados de destino com base nesse backup.

As etapas a seguir descrevem como executar uma migração física off-line.

Na console do OCI, crie uma instância de computação na mesma sub-rede na qual o banco de dados de destino será configurado.
Esta instância de computação pode ser qualquer configuração, com pelo menos duas OCPUs e 16 GB de RAM, executando o sistema operacional Oracle Linux 7.9. Essa máquina virtual será usada para executar o software Oracle Zero Downtime Migration.
Siga a documentação de instalação do Oracle Zero Downtime Migration na seção Revisar Documentação para fazer download e instalar o software Oracle Zero Downtime Migration 21.4 na instância de computação do OCI.
Execute o software Oracle Zero Downtime Migration como zdmuser.
Faça log-in como zdmuser na instância de computação que executa o software Oracle Zero Downtime Migration e gere um par de chaves ssh. Ative o ssh sem senha da conta zdmuser para todos os nós no banco de dados Exadata de origem (root, privilege-sudoer user) e para todos os nós de cluster de VMs na conta opc user do banco de dados de destino.
Garanta que a VM do Oracle Zero Downtime Migration possa se comunicar com os hosts do banco de dados de origem usando o nome do host e o endereço IP. Verifique o seguinte:
- Modifique o resolvedor de DNS da VCN ou o arquivo /etc/hosts na VM do Oracle Zero Downtime Migration, se necessário.
- Verifique se há uma regra de segurança que permite que a VM do Oracle Zero Downtime Migration se conecte ao banco de dados de origem na porta do listener padrão 1521 e na porta ssh 22.
- Certifique-se de que a VM do Oracle Zero Downtime Migration possa acessar os hosts do banco de dados de destino na porta do listener padrão 1521 e na porta ssh 22.
Na console do OCI, crie um bucket do OCI Object Storage se ainda não existir um.
Observe o URL Swift, o namespace de armazenamento de objetos e o nome do bucket.
Na console do OCI, crie um token de autenticação para o OCI_user fazendo upload de dados para o bucket do OCI Object Storage.
Observe que o token não será exibido novamente.
Certifique-se de que as políticas de segurança permitam que o OCI_user faça upload de dados para o bucket do OCI Object Storage.
Crie um banco de dados de destino do Oracle Exadata Database Service on Dedicated Infrastructure usando a GUI ou a API REST do OCI. Configure o banco de dados de destino da seguinte forma:
- Os bancos de dados de destino e de origem devem ter os mesmos nomes, mas diferentes de DB_UNIQUE_NAME.
- A senha sys, a senha da wallet, a versão do banco de dados, o nível de patch e a versão do arquivo de fuso horário nos bancos de dados de origem e de destino devem ser iguais.
- Não selecione um Destino de Backup ou ative Backups Automáticos. Essas definições podem ser ativadas após a migração do banco de dados.
Verifique se o banco de dados de origem está configurado no Modo de Log de Arquivamento. Se o Log de Arquivamento não estiver ativado, consulte Ativar Modo de Log de Arquivamento abaixo.
Se o banco de dados de origem não for criptografado, consulte Configurar um Armazenamento de Chaves de Criptografia de Dados Transparente (TDE) abaixo. Os dados não precisam ser criptografados; apenas a área de armazenamento de chaves TDE é necessária para a migração física. Certifique-se de que a senha do armazenamento de chaves (wallet) seja igual à senha do sistema/wallet usada para criar o banco de dados de destino no Oracle Exadata Database Service on Dedicated Infrastructure.
Crie um arquivo de resposta para que o Oracle Zero Downtime Migration execute a migração. Os parâmetros-chave incluem:
- TGT_DB_UNIQUE_NAME: Nome exclusivo do banco de dados do banco de dados Oracle Exadata Database Service on Dedicated Infrastructure de destino.
- MIGRATION_METHOD: OFFLINE_PHYSICAL ou ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST: O URL Swift para o namespace do OCI Object Storage na etapa 5 no formato: https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. Por exemplo:
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER: Nome do bucket do OCI Object Storage na etapa 4.
- SHUTDOWN_SRC: TRUE

Execute um job de migração de execução seca do Oracle Zero Downtime Migration (-eval) para validar todos os pré-requisitos para migração são possíveis. Por exemplo:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”
-eval

Este comando solicita duas senhas. A primeira senha é a senha sys do banco de dados de origem. A segunda senha é a senha OCI_user do usuário que está fazendo upload de dados para o bucket do OCI Object Storage. Não digite a senha do usuário aqui; em vez disso, digite o token de autenticação na etapa 6.

Depois de uma corrida seca bem-sucedida, vá para a próxima etapa.

Execute o job do Oracle Zero Downtime Migration. Por exemplo:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”

A migração física off-line foi concluída.

Ativar Modo de Log de Arquivamento

O modo de log de arquivamento deve ser ativado no banco de dados de origem para migrações físicas do Oracle Zero Downtime Migration. Essas etapas descreverão como configurar o modo de log de arquivamento no banco de dados de origem.

Validar o banco de dados de origem não está configurado no modo de log de arquivamento.
```
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
```

Configure o destino de arquivamento do log do banco de dados de origem. Como essa configuração é para um banco de dados em execução no Exadata, o destino do Archivelog deve ser o grupo de discos do Oracle RECO ASM.

SQL> alter system set log_archive_dest_1='LOCATION=+RECOC1' scope=both SID='*';
System altered.
SQL> select destination,STATUS from v$archive_dest where statuS='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Faça shutdown do banco de dados.
```
$ srvctl stop database -d db_name
```
Inicie a montagem do banco de dados no primeiro nó.
```
SQL> startup mount;
ORACLE instance started.
```
Ativar modo de log de arquivamento.
```
alter database archivelog;
```
Abra o banco de dados.
```
alter database open;
```

Verifique se o banco de dados está no modo Archivelog.

SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG
SQL> select destination,STATUS from v$archive_dest where status='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Reinicie o banco de dados no segundo nó.

$ srvctl start instance -d db_name -n hostname_node2

Verifique se os bancos de dados plugáveis estão no modo aberto, de leitura e gravação nos dois nós. Se os bancos de dados plugáveis não estiverem abertos, abra os bancos de dados plugáveis nos dois nós e salve o estado.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Configurar um Armazenamento de Chaves TDE (Transparent Data Encryption)

As migrações físicas do Oracle Zero Downtime Migration requerem um armazenamento de chaves/wallet de criptografia TDE auto_login (mesmo que o banco de dados de origem não esteja criptografado). Este armazenamento de chaves deve ser configurado com a mesma senha que o armazenamento de chaves do banco de dados de destino. Estas etapas descrevem como configurar um armazenamento de chaves no banco de dados de origem.

Verifique se há um local de armazenamento de chaves padrão configurado para o banco de dados.

SQL> select * from v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
NOT_AVAILABLE UNKNOWN SINGLE NONE UNDEFINED
1
SQL>

Esta saída mostra que não há armazenamento de chaves ou wallet configurado.

Defina a variável TNS_ADMIN para o usuário oracle nos dois nós do Exadata.
```
$ORACLE_HOME/network/admin/db_name
```
Crie um diretório para armazenar o arquivo sqlnet.ora nos dois nós do Exadata apontados por TNS_ADMIN.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```

Crie o arquivo sqlnet.ora no diretório apontado por TNS_ADMIN com o seguinte conteúdo em ambos os nós do Exadata.

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))

Crie um diretório para armazenar o armazenamento de chaves ou a wallet no local apontado por sqlnet.ora nos dois nós do Exadata.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
No primeiro nó, crie o armazenamento de chaves protegido com uma senha.
A área de armazenamento de chaves do banco de dados de destino também deve ser configurada com essa senha.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
No primeiro nó, abra o armazenamento de chaves.
Se o banco de dados de origem não for um CDB, remova container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```
Crie um backup para a área de armazenamento de chaves.
Se o banco de dados de origem não for um CDB, remova container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;
```

Verifique se a área de armazenamento de chaves foi criada e se foi feito backup dela.

SQL> SELECT * FROM v$encryption_keys;
Snip…
ACTIVATING_PDBNAME
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
ATOlrcGaa0/iv/dFeRSkNSIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
db_name
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
1 86B637B62FDF7A65E053F706E80A27CA
Snip…

Crie um armazenamento de chaves auto_login com base no armazenamento de chaves criado na etapa 7.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/db_name/wallet' IDENTIFIED BY keystore_password ;

Feche a área de armazenamento de chaves na etapa 7.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY keystore_password;

Verifique se o armazenamento de chaves auto_login ainda está aberto.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
OPEN AUTOLOGIN SINGLE NONE NO

Crie arquivos de wallet do nó 1 para o nó 2.

cd /u01/app/oracle/admin/db_name/wallet.
scp * node_2:/u01/app/oracle/admin/db_name/wallet

Reinicie o banco de dados nos dois nós do Exadata.

$ srvctl stop database -d db_name
$ srvctl start database -d db_name
$ srvctl status database -d db_name
Instance db_name1 is running on node node_1
Instance db_name2 is running on node node_2

Verifique se a wallet auto_login está aberta em ambos os nós.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet/
OPEN AUTOLOGIN SINGLE NONE NO
1
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN AUTOLOGIN SINGLE UNITED NO
2
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN_NO_MASTER_KEY AUTOLOGIN SINGLE UNITED UNDEFINED
3
SQL>

Verifique se os bancos de dados plugáveis estão no modo aberto, de leitura e gravação nos dois nós. Se os bancos de dados plugáveis não estiverem abertos, abra os bancos de dados plugáveis nos dois nós e salve o estado.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```