Esta página descreve limitações conhecidas (incluindo considerações especiais para processar entidades como chaves primárias ou chaves externas e gatilhos), bem como práticas recomendadas para migrações heterogêneas do Oracle com o Database Migration Service.
O que não é migrado
- Usuários e permissões não são migrados.
- As mudanças de esquema que ocorrem durante um job de migração ativo não são automaticamente migradas. Se você mudar o esquema durante a migração, você precisa primeiro atualizar o espaço de trabalho de conversão com as mudanças de esquema e, em seguida atualizar os jobs de migração relevantes. Para mais informações, consulte Adicionar esquema ou tabelas atualizados ao job de migração.
-
As instruções
SAVEPOINTnão são compatíveis e podem causar discrepâncias de dados em caso de reversão. -
O Database Migration Service replica tipos de dados definidos pelo usuário, mas apenas
armazena o tipo de dados de base do qual você deriva os tipos definidos pelo usuário.
Por exemplo, se você definir um tipo de dados
USERNAMEcom base noVARCHAR2tipo de dados, os dados serão armazenados no destino comoVARCHAR.
Banco de dados, transações e consistência de dados
- A migração é eventualmente consistente, já que o Database Migration Service não replica cada transação conforme ela acontece. A migração traz dados de várias tabelas. A ordem em que os dados são carregados no destino pode variar, mas se realinha com a origem depois que as gravações na origem são interrompidas e o buffer de migração é limpo.
- Para migrações heterogêneas do Oracle, o Database Migration Service só pode migrar um banco de dados por job de migração.
- O Database Migration Service oferece suporte à arquitetura multilocatária do Oracle (CDB/PDB), mas só é possível migrar um único banco de dados plugável por job de migração.
- O Oracle Label Security (OLS) não é replicado.
- Todas as transações revertidas no banco de dados de origem durante o processo de migração podem ficar visíveis no destino temporariamente (quando a transação é longa o suficiente).
- O Database Migration Service não oferece suporte à conectividade direta com bancos de dados usando o recurso Single Client Access Name (SCAN) em ambientes do Oracle Real Application Clusters (RAC). Para possíveis soluções para usar a conectividade da lista de permissões de IP público com esses ambientes, consulte Resolver erros de SCAN do Oracle.
Codificação de dados
- O Database Migration Service oferece suporte apenas a codificações de conjunto
UTF8para o banco de dados de destino. Não há suporte para nomes de esquema e tabelas que incluem caracteres que não fazem parte do conjunto de codificaçãoUTF8. - O Database Migration Service oferece suporte às seguintes codificações de conjunto de caracteres para bancos de dados Oracle
:
AL16UTF16AL32UTF8IN8ISCIIIW8ISO8859P8JA16SJISJA16SJISTILDEKO16MSWIN949US7ASCIIUTF8WE8ISO8859P1WE8ISO8859P9WE8ISO8859P15WE8MSWIN1252ZHT16BIG5
Tabelas, esquemas e outros objetos
- Durante uma migração, não há suporte para mudanças na linguagem de definição de dados (DDL) em dados, esquemas, e metadados. Se você atualizar o esquema durante a migração, será necessário extrair as mudanças para o espaço de trabalho de conversão, converter o código, limpar o destino e executar o job de migração novamente.
- Não há suporte para nomes de colunas de tabelas que incluem caracteres diferentes de caracteres alfanuméricos
caracteres ou um sublinhado (
_). - O comprimento máximo do nome de tabelas ou colunas é de 30 caracteres. o Database Migration Service não poderá replicar tabelas que excedam esse limite ou tabelas que contenham colunas com nomes que excedam esse limite.
- As tabelas organizadas pelo índice (IOTs) não são compatíveis.
- As tabelas temporárias globais exigem que a extensão
pgttdo PostgreSQL seja instalada e criada no destino. - Para colunas do tipo
BFILE, somente o caminho para o arquivo será replicado. O conteúdo do arquivo não será replicado. - Para o Oracle 11g, as tabelas com colunas de tipos de dados
ANYDATAouUDTnão são compatíveis, e a tabela inteira não será replicada. - Os jobs programados usando
dbms_joboudbms_schedulernão são migrados. - As definições de visualizações materializadas são migradas, mas os dados materializados não. Depois de concluir a migração, atualize as visualizações materializadas para preenchê-las com dados das tabelas migradas.
- Os valores de sequência são migrados, mas os valores no banco de dados de origem podem continuar avançando antes da conclusão da migração. Depois de concluir a migração, atualize os valores de sequência na instância de destino para corresponder aos do banco de dados de origem.
- Os jobs de migração são limitados a 10.000 tabelas.
- As linhas têm uma limitação de tamanho de 100 MB. As linhas que excedem o limite de 100 MB não são migradas e aparecem como erros no job de migração.
- As tabelas criadas após o início da migração não são migradas automaticamente. Primeiro, é necessário extrair o esquema delas no espaço de trabalho de conversão, aplicar definições convertidas ao destino e atualizar o job de migração.
- As tabelas de origem que contêm colunas binárias e não têm chaves primárias não são compatíveis com a migração de dados em migrações contínuas.
Limitações do tipo de dados
Os seguintes tipos de dados não são compatíveis com migrações do Oracle:
ANYDATA(para o Oracle 11g, as tabelas comANYDATAnão são compatíveis e não são replicadas).BFILEINTERVAL DAY TO SECONDINTERVAL YEAR TO MONTHLONG/LONG RAWSDO_GEOMETRYUDTUROWIDXMLTYPE- Datas zero em
TIMESTAMP
Considerações sobre chaves primárias
Tabelas sem chaves primárias não prometem replicação consistente.
O Database Migration Service migra apenas tabelas que têm chaves primárias.
Se o banco de dados de origem incluir tabelas que não têm chaves primárias,
os espaços de trabalho de conversão do Database Migration Service criarão automaticamente as chaves primárias ausentes nas tabelas de destino quando você
converter o código-fonte e o esquema.
Também é possível desativar a geração automática de chave primária com a
GENERATE_MISSING_PK diretiva de conversão.
Para migrações contínuas: as tabelas de origem que contêm colunas binárias e não têm chaves primárias não são compatíveis com a migração de dados em migrações contínuas.
Se você usar espaços de trabalho de conversão legados, será necessário criar manualmente restrições de chave primária nas tabelas convertidas no banco de dados de destino antes de iniciar a migração. Para mais informações, consulte Espaços de trabalho de conversão legados.
Considerações sobre chaves externas e gatilhos
As chaves externas e os gatilhos presentes no banco de dados de origem podem levar a
problemas de integridade de dados ou até mesmo causar falha no job de migração.
É possível evitar esses problemas se você ignorar chaves externas e gatilhos
usando a opção REPLICATION para o usuário de migração.
Como alternativa, também é possível descartar todas as chaves externas e gatilhos no banco de dados de destino
e recriá-los quando a migração for concluída.
Gatilhos
Os dados replicados pelo Database Migration Service já incorporam todas as mudanças feitas por gatilhos no banco de dados de origem. Se os gatilhos estiverem ativados no destino, eles poderão ser acionados novamente e manipular dados, resultando em problemas de integridade ou duplicação de dados.
Chaves externas
O Database Migration Service não replica dados de maneira transacional portanto, as tabelas podem ser migradas fora de ordem. Se houver chaves externas, e uma tabela filha que usa uma chave externa for migrada antes da mãe, você poderá encontrar erros de replicação.
Recomendações
- Ao
criar o banco de dados de destino do Cloud SQL,
use recursos de computação e memória suficientes para atender às
necessidades de migração. Recomendamos um tipo de máquina que tenha pelo menos uma CPU com dois núcleos.
Por exemplo, se o nome da máquina for
db-custome ela tiver duas CPUs e 3.840 MB de RAM, o formato do nome do tipo de máquina serádb-custom-2-3840. - O banco de dados de destino do Cloud SQL pode ser gravado durante a migração para permitir que as mudanças na linguagem de manipulação de dados (DML) sejam aplicadas, se necessário. Não faça mudanças na configuração do banco de dados ou nas estruturas de tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.
Cotas
- É possível ter a qualquer momento até 2.000 perfis de conexão e 1.000 jobs de migração. Se você quiser criar mais espaço para esses itens, os jobs de migração (incluindo os concluídos) e os perfis de conexão poderão ser excluídos.