AWS DMS migrações GoldenGate Migrações da Oracle Migrações do Oracle Data Pump Migrações do Oracle RMAN Migrações do Oracle Data Guard

Exadata para ferramentas de migração AWS

Existem mais de 15 abordagens de AWS migração do Exadata. A tabela a seguir mostra as ferramentas mais usadas. A tabela não inclui exportação/importação convencional da Oracle, Oracle SQL*Loader, Oracle SQL Developer Database Copy, Oracle SQL*Developer Export/Import Wizard, Oracle Transportable Tablespaces, links de banco de dados Oracle usando Criar Tabela como Seleção (CTAS), tabelas externas da Oracle ou soluções de extração, transformação e carregamento (ETL).

Abordagem de migração	Suporta a estratégia de migração	Físico ou lógico	Suporta captura de dados de alteração (CDC)	Requer rede para AWS
AWS DMS	Todos	Lógico	Sim	Sim
Oráculo GoldenGate	Todos	Lógico	Sim	Sim
Oracle Data Pump	Rehospede, reformule a plataforma	Lógico	Não	Não
Gerenciador de Recuperação Oracle (RMAN)	Redefinir a hospedagem	Físico	Não	Se você usa o `RMAN DUPLICATE` Oracle Secure Backup para o Amazon S3
Oracle Data Guard	Redefinir a hospedagem	Físico	Sim	Sim

O Oracle Data Guard e o Oracle Recovery Manager (RMAN) são excelentes opções para migrar um banco de dados Exadata para o Amazon EC2. No entanto, o Amazon RDS for Oracle não oferece suporte a nenhuma dessas ferramentas.

Você pode implementar o Oracle Data Guard usando o método de espera lógica ou espera física. Um banco de dados lógico em espera aplica instruções de linguagem de manipulação de dados (DML) no banco de dados em espera para manter os dados sincronizados. Os bancos de dados lógicos em espera são normalmente usados para descarregar os relatórios do banco de dados primário. Todas as referências do Oracle Data Guard nesta seção se aplicam diretamente ao standby físico. Um banco de dados físico em espera corresponde ao banco de dados primário exatamente no nível do bloco.

AWS DMS migrações

AWS Database Migration Service (AWS DMS) é uma solução de replicação lógica. Ele suporta migrações homogêneas, como a migração de um banco de dados Oracle local para um banco de dados Oracle no AWS, bem como migrações heterogêneas entre diferentes plataformas de banco de dados, como Oracle para Microsoft SQL Server e Oracle para Amazon Aurora PostgreSQL Compatible Edition. AWS DMS suporta uma ampla variedade de fontes e alvos. Os AWS DMS alvos compatíveis incluem Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, Amazon Kinesis Data Streams,Amazon DocumentDB e Redis.

Você pode usar AWS DMS para migrar suas cargas de trabalho do Exadata para o Amazon RDS for Oracle ou para um banco de dados Oracle no Amazon EC2. AWS DMS manipula a carga inicial, bem como as atualizações de captura de dados de alteração (CDC) do Exadata. O Exadata está totalmente operacional durante o processo de migração. Se você usa o CDC, o banco de dados de destino permanece continuamente sincronizado com o Exadata, para que a transferência do aplicativo possa ocorrer em um momento conveniente.

As ferramentas nativas da Oracle, como Oracle RMAN, Oracle Data Guard e Oracle Data Pump, são mais flexíveis e podem carregar dados mais rapidamente do que AWS DMS. Se você estiver migrando bancos de dados Exadata grandes (com vários TiB), recomendamos que você escolha esses utilitários nativos da Oracle em vez de usar o carregamento inicial de AWS DMS dados.

O Oracle Data Pump suporta vários processos de trabalho que podem realizar paralelismo entre tabelas e entre partições para carregar e descarregar tabelas em fluxos múltiplos, paralelos ou de caminho direto. Todo o processamento de importação e exportação no Data Pump, incluindo leitura e gravação de arquivos de despejo, é feito pelo servidor e não envolve o cliente. O formato de armazenamento de arquivos de despejo do Data Pump é o formato de fluxo interno da API de caminho direto. Esse formato é muito semelhante ao formato armazenado nos arquivos de dados do Oracle Database dentro de espaços de tabela. Portanto, o Data Pump não precisa realizar a conversão do lado do cliente para variáveis de associação de INSERT instruções. Além disso, o Data Pump oferece suporte a métodos de acesso a dados, caminho direto e tabelas externas, que são mais rápidos do que o SQL convencional. A API de caminho direto fornece o desempenho mais rápido de fluxo único. O recurso de tabelas externas faz uso eficiente das consultas paralelas e dos recursos de DML paralelos do Oracle Database. Se a migração do Exadata para o Amazon RDS for Oracle exigir pouco tempo de inatividade, uma abordagem comum de migração do Exadata é usar o Data Pump para a carga inicial e depois usar o Oracle para CDC. AWS DMS GoldenGate

Há limitações quando você usa o Exadata como fonte para. AWS DMS Para obter mais informações sobre eles, consulte a AWS DMS documentação. Além disso, a conectividade de rede com a origem (Exadata no local) e o destino (banco de dados Oracle ativado AWS) é necessária para. AWS DMS

Se você usar AWS DMS para a carga inicial, considere as seguintes práticas recomendadas:

Em geral, você pode melhorar o desempenho selecionando uma instância de AWS DMS replicação grande. Tabelas grandes demoram mais para carregar e as transações nessas tabelas devem ser armazenadas em cache até que a tabela seja carregada. Depois que uma tabela é carregada, essas transações armazenadas em cache são aplicadas e não ficam mais armazenadas em disco. Por exemplo, se a carga levar cinco horas e produzir 6 GiB de transações por hora, certifique-se de que 30 GiB de espaço em disco sejam alocados para transações em cache. Quando o carregamento inicial estiver concluído, antes de iniciar o CDC, você poderá modificar a instância de AWS DMS replicação para usar uma instância menor.
Para migrações grandes (de vários TiB) do Exadata, recomendamos que você use o AWS DMS Binary Reader em vez do Oracle LogMiner (que é o padrão). O Binary Reader tem um risco menor de impacto na E/S ou na CPU porque os registros são extraídos diretamente, em vez de exigir várias consultas ao banco de dados. No entanto, o Oracle LogMiner é melhor quando você tem um grande volume de alterações e está usando o Oracle ASM. Para usar o Binary Reader para acessar os redo logs, adicione os seguintes atributos de conexão extras para o endpoint de origem:
```
useLogMinerReader=N;useBfile=Y
```
Para uma comparação completa, consulte Usando o Oracle LogMiner ou o AWS DMS Binary Reader para CDC na AWS DMS documentação.
Desative os backups do Amazon RDS for Oracle ou altere o modo de arquivamento NOARCHIVELOG para se você estiver migrando para o Oracle no Amazon EC2. Ative os backups antes da fase CDC ou após o carregamento inicial dos dados.
Desative todos os bancos de dados em AWS espera ativados. Isso inclui o Amazon RDS for Oracle Multi-AZ e réplicas de leitura. Também inclui espera do Oracle Data Guard ou do Oracle Active Data Guard se você estiver migrando para a Oracle no Amazon EC2.
Elimine índices de chave primária, índices secundários, restrições de integridade referencial e acionadores de linguagem de manipulação de dados (DML) antes dos carregamentos iniciais no banco de dados de destino. Ative esses objetos antes de iniciar a fase CDC.
Para tabelas grandes, considere dividir uma única tabela em várias AWS DMS tarefas usando filtragem de linhas, uma chave ou uma chave de partição. Por exemplo, se seu banco de dados tiver uma ID de chave primária inteira que varia de 1 a 8.000.000, crie oito tarefas usando a filtragem de linhas para migrar um milhão de registros para cada tarefa. AWS DMS Você também pode usar essa técnica com uma coluna de data.
Divida a AWS DMS migração em várias AWS DMS tarefas. A consistência transacional é mantida em uma tarefa, portanto, tabelas em tarefas separadas não devem participar de transações comuns.
Por padrão, AWS DMS carrega oito tabelas por vez. Para melhorar o desempenho, você pode aumentar esse valor se usar um grande servidor de replicação.
Por padrão, AWS DMS os processos mudam em um modo transacional, que preserva a integridade transacional. Mudar para a opção de aplicação otimizada em lote pode melhorar o desempenho. Recomendamos que você desative essas restrições durante o carregamento inicial e as ative novamente para o processo do CDC.
Se a instância de AWS DMS replicação e o banco de dados Oracle AWS estiverem em diferentes nuvens privadas virtuais (VPCs), recomendamos que você use o emparelhamento de VPC.
Ative CloudWatch os registros da Amazon ao criar ou modificar tarefas de AWS DMS migração. Esse parâmetro está disponível na seção Configurações da tarefa quando você cria uma AWS DMS tarefa. A ativação desse parâmetro captura informações como status da tarefa, porcentagem de conclusão, tempo decorrido e estatísticas da tabela durante o processo de migração. Para obter mais informações, consulte Monitoramento de tarefas de replicação usando a Amazon CloudWatch na AWS DMS documentação.

Para obter mais práticas recomendadas, consulte Usando um banco de dados Oracle como fonte AWS DMS e Práticas recomendadas para AWS Database Migration Service na AWS DMS documentação.

GoldenGate Migrações da Oracle

O Oracle GoldenGate é uma solução de replicação lógica. Você pode usar essa ferramenta para replicar, filtrar e transformar dados de um banco de dados para outro. Você pode mover transações confirmadas em vários sistemas heterogêneos e replicar dados dos bancos de dados Oracle para outros bancos de dados homogêneos e bancos de dados heterogêneos compatíveis. A Oracle GoldenGate compartilha muitas das características e limitações positivas do AWS DMS.

Ambas as ferramentas fornecem replicação lógica. No entanto, AWS DMS é um serviço gerenciado que não requer instalação e configuração, enquanto o Oracle GoldenGate deve ser instalado e configurado. Você pode configurá-lo no local ou no AWS. Você pode instalar o Oracle GoldenGate AWS usando uma configuração altamente disponível para migrar dados do Exadata para o. AWS Não instale o Oracle GoldenGate diretamente no Exadata local ou em um nó de banco de dados Oracle no Amazon EC2; os nós do banco de dados devem ser dedicados ao processamento de cargas de trabalho do banco de dados.

Outra grande diferença entre a Oracle AWS DMS e a Oracle GoldenGate é o preço. AWS DMS cobranças pelo uso da instância de replicação e pelo armazenamento de registros. Todas as transferências de dados para dentro AWS DMS são gratuitas, e os dados transferidos entre AWS DMS bancos de dados nas instâncias do Amazon RDS e do Amazon EC2 na mesma zona de disponibilidade também são gratuitos. A Oracle GoldenGate exige uma GoldenGate licença Oracle para cada núcleo nos bancos de dados de origem e destino. Você pode usar o Oracle GoldenGate para migrar cargas de trabalho do Exadata para o Amazon RDS for Oracle ou para o Oracle no Amazon EC2, tanto para a carga inicial quanto para realizar o CDC a partir do Exadata. Esse processo permite que o Exadata esteja totalmente operacional durante o processo de migração.

Para migrar bancos de dados Exadata grandes (com várias TIB) para a Oracle no Amazon EC2, considere usar o Oracle RMAN, o Oracle Data Guard ou o Oracle Data Pump em vez do Oracle pelos seguintes motivos: GoldenGate

O Oracle GoldenGate exige conectividade de rede entre o Exadata e. AWS
O Oracle GoldenGate não tem um desempenho tão bom quanto outras ferramentas de migração da Oracle para o carregamento inicial de dados. Por exemplo, para migrar grandes bancos de dados Exadata para o Amazon RDS for Oracle, considere usar o Oracle Data Pump em vez disso, porque ele é mais flexível e pode carregar dados mais rápido do que o Oracle. GoldenGate

Se a migração do Exadata para o Amazon RDS for Oracle exigir pouco tempo de inatividade, uma abordagem comum de migração é usar o Oracle Data Pump para a carga inicial e o Oracle ou para o CDC. GoldenGate AWS DMS A vantagem do Oracle GoldenGate é que ele pode lidar com a carga inicial tão bem quanto o CDC. O CDC permite que o banco de dados de destino permaneça continuamente sincronizado com o Exadata, para que você possa alternar em um momento conveniente.

Há limitações quando você usa o Exadata como fonte com a Oracle. GoldenGate Para obter informações sobre isso, consulte Entendendo o que é suportado na GoldenGate documentação.

Se você usa o Oracle GoldenGate para a carga inicial, considere as seguintes melhores práticas:

Use o Extract no modo de captura integrado para aproveitar a integração com o LogMiner servidor. A captura integrada permite a extração perfeita de mais tipos de dados do que com o Extract no modo clássico. Esses tipos de dados adicionais incluem dados compactados, incluindo compactação básica, processamento de transações on-line (OLTP) e compressão colunar híbrida do Exadata (HCC). Não há nenhuma configuração adicional necessária para que o Extract leia arquivos de log armazenados no Oracle ASM.
Use o Integrated Replicat. Essa opção usa o processo de aplicação do banco de dados. Ele mantém a integridade referencial e aplica automaticamente as operações de DDL. O Integrated Replicat também oferece paralelismo automático, que aumenta ou diminui automaticamente com base na carga de trabalho atual e no desempenho do banco de dados.
Definido BATCHSQL no arquivo de parâmetros Replicat. Por padrão, o Integrated Replicat tenta reordenar e agrupar instruções DML do mesmo tipo em relação ao mesmo objeto em cada transação. O uso de lotes pode reduzir a CPU e o tempo de execução das instruções DML.
Configure a tabela de GoldenGate pulsação para fornecer visualizações de atraso end-to-end de replicação. Isso permite que você veja a latência da end-to-end replicação visualizando a visualização do GG_LAG banco de dados.
Desative o Amazon RDS para backups do Oracle ou altere o modo de arquivamento NOARCHIVELOG para se você estiver usando o Oracle no Amazon EC2. Ative os backups antes da fase CDC ou após o carregamento inicial dos dados.
Desative todos os bancos de dados em espera na AWS. Isso inclui o Amazon RDS for Oracle Multi-AZ e réplicas de leitura. Também inclui espera do Oracle Data Guard ou do Oracle Active Data Guard se você estiver migrando para a Oracle no Amazon EC2.
Elimine índices de chave primária, índices secundários, restrições de integridade referencial e acionadores de linguagem de manipulação de dados (DML) antes dos carregamentos iniciais no banco de dados de destino. Ative esses objetos antes de iniciar a fase CDC.
Se a instância de GoldenGate replicação Oracle e o banco de dados Oracle AWS estiverem em diferentes nuvens privadas virtuais (VPCs), recomendamos que você use o emparelhamento de VPC.

Migrações do Oracle Data Pump

Você pode usar o Oracle Data Pump para mover dados de um banco de dados Oracle para outro. O Data Pump oferece uma ampla variedade de benefícios, como suporte a versões mais antigas do Oracle Database (de volta à versão 10.1) e plataformas de suporte que têm formatos, arquiteturas de banco de dados e versões diferentes. Você pode optar por exportar seu banco de dados completo ou somente esquemas, espaços de tabela ou tabelas específicos.

Você pode controlar o grau de paralelismo, compactação e criptografia e especificar quais objetos e tipos de objetos incluir ou excluir. O Data Pump também suporta o modo de rede, onde você pode transferir dados usando um link de banco de dados sem a necessidade de armazenamento intermediário.

A API Data Pump fornece uma maneira rápida e confiável de mover dados e metadados entre bancos de dados Oracle. Os utilitários Data Pump Export e Data Pump Import são baseados na API Data Pump. Uma instância do Amazon RDS for Oracle não pode ser acessada por meio do protocolo Secure Shell (SSH), então a API Data Pump é a única maneira de importar dados se você usar o Data Pump para migrar do Exadata para o Amazon RDS for Oracle. A interface de linha de comando (CLI) do Data Pump não é uma opção para migrar para o Amazon RDS for Oracle.

Se você usa o Data Pump para a carga inicial, considere as seguintes práticas recomendadas:

Crie os espaços de tabela necessários antes de importar os dados.
Se você quiser importar dados para uma conta de usuário que não existe, crie a conta de usuário e conceda as permissões e funções necessárias.
Se você estiver migrando para a Oracle no Amazon EC2, desative o Amazon RDS for Oracle backups ou altere o modo de arquivamento para. NOARCHIVELOG Ative os backups antes de iniciar a fase CDC ou após o carregamento inicial dos dados.
Ative todos os bancos de dados em AWS espera. Isso inclui o Amazon RDS for Oracle Multi-AZ e réplicas de leitura. Também inclui espera do Oracle Data Guard ou do Oracle Active Data Guard se você estiver migrando para a Oracle no Amazon EC2.
Elimine índices de chave primária, índices secundários, restrições de integridade referencial e acionadores de DML antes dos carregamentos iniciais no banco de dados de destino. Ative esses objetos antes de iniciar a fase CDC.
Para importar esquemas e objetos específicos, execute importações no modo esquema ou tabela.
Limite os esquemas que você importa aos que seu aplicativo exige.
Carregue e descarregue dados paralelamente usando compressão e vários encadeamentos.
Os arquivos no Amazon S3 devem ter 5 TiB ou menos. Use a PARALLEL opção de criar vários arquivos de despejo do Data Pump para evitar essa limitação.
Se você planeja realizar o CDC após a exportação do Data Pump, use o número de alteração do sistema Oracle (SCN) com o Data Pump.
Se você quiser carregar dados no Amazon RDS for Oracle, execute estas tarefas:
1. Crie uma política AWS Identity and Access Management (IAM) para permitir que o Amazon RDS acesse um bucket do S3.
2. Crie uma função do IAM e anexe a política.
3. Associe a função do IAM à instância do Amazon RDS for Oracle.
4. Configure um grupo de opções do Amazon RDS for Oracle para integração com o Amazon S3 e adicione-o à instância do Amazon RDS for Oracle.
Para obter informações adicionais, consulte a integração com o Amazon S3 na documentação do Amazon RDS.

Migrações do Oracle RMAN

O Oracle Recovery Manager (RMAN) é uma ferramenta para fazer backup e recuperar um banco de dados Oracle. Ele também é usado para facilitar as migrações de bancos de dados no local e entre bancos de dados locais e na nuvem.

O Oracle RMAN fornece uma abordagem de migração física. Por esse motivo, ele oferece suporte à nova hospedagem (migração para o Amazon EC2), mas não pode ser usado para reformatar seu banco de dados Oracle no Amazon RDS for Oracle. Sua tolerância ao tempo de inatividade da migração deve ser grande o suficiente para fazer backup e restaurar um backup incremental do Oracle RMAN.

Migração para o Amazon S3

Para fazer backup do seu banco de dados Exadata no Amazon S3, você pode usar as seguintes opções:

Use o módulo de nuvem Oracle Secure Backup (OSB) para fazer backup do seu banco de dados Exadata diretamente no Amazon S3.
Copie os conjuntos de backup do Oracle RMAN para o Amazon S3 a partir do local de backup do Exadata RMAN.
Use os dispositivos de armazenamento Oracle ZFS. Os conjuntos de backup Oracle RMAN armazenados nos dispositivos de armazenamento Oracle ZFS podem ser transferidos diretamente para o Amazon S3 usando o serviço de API de objetos do Oracle ZFS Storage Appliance S3.
Armazene os backups do Oracle RMAN diretamente no Exadata Storage Server, no Oracle Zero Loss Recovery Appliance e nas bibliotecas de fitas. Em seguida, você pode transferir os conjuntos de backup do RMAN em qualquer uma dessas plataformas de armazenamento para o Amazon S3.

Migração para o Amazon EC2

Você também pode usar o RMAN para fazer backup do seu banco de dados Exadata diretamente no Oracle Database no Amazon EC2 sem criar conjuntos de backup. Para fazer isso, use o DUPLICATE comando Oracle RMAN para realizar um backup e uma restauração. No entanto, o Oracle RMAN DUPLICATE não é recomendado para migrações grandes (de vários TiB) do Exadata.

As configurações do RMAN geralmente são definidas com base em fatores como o tamanho do backup, a CPU do Exadata, a compactação e o paralelismo ou o número de canais RMAN. Usar o Oracle Service Bus (OSB) e a compactação (baixa, média e alta) com o RMAN requer licenças Oracle Advanced Compression Option (ACO). O OSB também exige licenças Oracle baseadas no número de canais RMAN que você deseja usar com o OSB.

Se você quiser usar o RMAN para migrar o Exadata para o Oracle no Amazon EC2, considere as seguintes melhores práticas.

nota

Os comandos fornecidos nesta seção devem ser executados na instância Oracle on Amazon EC2.

Se você quiser usar nomes diferentes de grupos de discos do Oracle ASM no Amazon EC2, execute set newname o comando com o processo de restauração do RMAN:
```
set newname for datafile 1 to '+<disk_group>'; set newname for datafile 2 to '+<disk_group>';
```

Se os redo logs on-line residirem em um local diferente AWS, renomeie os arquivos de redo log:


alter database rename file '/<old_path>/redo01.log' to '+<disk_group>';
alter database rename file '/<old_path>/redo02.log' to '+<disk_group>';

Depois de abrir o banco de dados com sucesso em AWS:
- Remova os grupos de redo log para threads de redo de outras instâncias:
```
alter database disable thread 2;
alter database drop logfile group 4;
alter database clear unarchived logfile group 4;
```
- Remova os espaços de tabela de desfazer de outras instâncias:
```
drop tablespace UNDOTBS2 including contents and datafiles;
```
- Certifique-se de que exista somente um TEMP espaço de tabela. Remova TEMP os espaços de tabela desnecessários e confirme se o TEMP espaço de tabela existente é grande o suficiente para lidar com a carga de trabalho prevista do banco de dados.

Considerações sobre o HCC

Se você usar a compressão colunar híbrida (HCC) no Exadata, todas as tabelas com HCC deverão ser convertidas para o Oracle ACO ou desativadas. AWS Caso contrário, as instruções SQL falharão quando você acessar seu banco de dados Oracle no Amazon EC2. O Oracle ACO exige uma licença Oracle.

Normalmente, os usuários não podem remover o HCC de um banco de dados de produção local do Exadata. Você pode remover o HCC ao migrar seu banco de dados para o. AWS Para determinar se o HCC está ativado em uma tabela ou partição após a migração do banco de dados para AWS, execute a seguinte instrução SQL:


select TABLE_NAME, COMPRESSION, COMPRESS_FOR
from DBA_TABLES
where OWNER like 'SCHEMA_NAME';

select TABLE_NAME, PARTITION_NAME, COMPRESSION, COMPRESS_FOR
from DBA_TAB_PARTITIONS
where TABLE_OWNER = 'SCHEMA_NAME';

Se o valor da compression coluna estiver definido como ENABLED e a compress_for coluna tiver um dos seguintes valores, o HCC será ativado:

QUERY LOW
QUERY HIGH
ARCHIVE LOW
ARCHIVE HIGH
QUERY LOW ROW LEVEL LOCKING
QUERY HIGH ROW LEVEL LOCKING
ARCHIVE LOW ROW LEVEL LOCKING
ARCHIVE HIGH ROW LEVEL LOCKING
NO ROW LEVEL LOCKING

Para desativar o HCC em uma tabela ou partição, execute a seguinte instrução SQL:


alter table table_name nocompress;
alter table table_name modify partition partition_name nocompress;

Para ativar o Oracle ACO AWS, siga as instruções na documentação da Oracle.

Migrações do Oracle Data Guard

O Oracle Data Guard permite criar e gerenciar um ou mais bancos de dados em espera para alta disponibilidade e recuperação de desastres. O Data Guard mantém bancos de dados em espera como cópias do banco de dados principal (normalmente de produção). Se o banco de dados de produção encontrar problemas de disponibilidade planejados ou não planejados, o Data Guard poderá trocar de função para garantir o mínimo de tempo de inatividade e a continuidade do aplicativo.

Você pode usar os métodos de espera lógica e de espera física para implementar o Data Guard. Neste guia, presumimos que você esteja usando um banco de dados físico em espera que corresponda exatamente ao banco de dados principal.

O Data Guard suporta migrações do Exadata para o Oracle Database no Amazon EC2 para criar uma espera física. Ele não pode ser usado para migrar para o Amazon RDS for Oracle, o que requer abordagens lógicas de migração, AWS DMS como Oracle Data Pump ou Oracle. GoldenGate

O Data Guard é uma abordagem mais simples e rápida para migrar um banco de dados Exadata inteiro em comparação com um mecanismo CDC, como o Oracle. AWS DMS GoldenGate Geralmente, é a abordagem recomendada se você tiver requisitos mínimos de tempo de inatividade (por exemplo, você só tem tempo para uma transição).

Você pode configurar o Data Guard com transporte síncrono ou assíncrono. Em geral, os clientes da Oracle têm maior sucesso com o transporte síncrono quando a latência da rede de ida e volta é inferior a 5 ms. Para transporte assíncrono, a Oracle recomenda uma latência de rede de ida e volta inferior a 30 ms.

Normalmente, já existiria um modo de espera do Data Guard para o banco de dados local do Exadata de produção. O Oracle no Amazon EC2 geralmente serve como um banco de dados adicional em espera para o banco de dados local Exadata de produção. Recomendamos que você crie o banco de dados stand-by do Data Guard AWS usando o Oracle RMAN.

Há muitas variáveis que afetam o desempenho do Data Guard. Recomendamos que você realize testes antes de tirar qualquer conclusão sobre o impacto da replicação do Data Guard em sua carga de trabalho.

A latência (medida por meio de um monitor de ping) não é significativa para a replicação do Data Guard, porque o mecanismo usado é diferente. O utilitário Oracle oratcptest ajuda a avaliar os recursos da rede. Você pode baixar oratcptest no formato JAR da Nota 2064368.1 do My Oracle Support (MOS) (requer uma conta Oracle). A nota MOS também fornece mais informações sobre esse utilitário.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Executar a migração

AWS exemplos de padrões de migração