Limitações e recomendações conhecidas

Nesta página, descrevemos as limitações conhecidas (incluindo considerações especiais para processar entidades como chaves primárias ou chaves externas e acionadores), bem como práticas recomendadas para migrações heterogêneas do Oracle com o Database Migration Service.

O que não é migrado

• Os usuários e as permissões não são migrados.
• As alterações de esquema que ocorrem durante um job de migração ativo não são migradas automaticamente. Se você mudar o esquema durante a migração, primeiro atualize o espaço de trabalho de conversão com as mudanças no esquema e, em seguida, atualize os jobs de migração relevantes. Para mais informações, consulte Adicionar esquemas ou tabelas atualizados ao job de migração.
• As instruções SAVEPOINT não são compatíveis e podem causar discrepância de dados em caso de reversão.
• O Database Migration Service replica tipos de dados definidos pelo usuário, mas só armazena o tipo de dados base do qual você deriva os tipos definidos pelo usuário. Por exemplo, se você definir um tipo de dados USERNAME com base no tipo de dados VARCHAR2, os dados serão armazenados no destino como VARCHAR.

Banco de dados, transações e consistência de dados

• A migração tem consistência posterior, 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 é realinhada 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 é compatível com a arquitetura multilocatária da 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 que forem revertidas no banco de dados de origem durante o processo de migração poderão ficar visíveis no destino temporariamente (quando a transação for longa o suficiente).
• O Database Migration Service não é compatível com a conectividade direta a 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 do Oracle SCAN.

Codificação de dados

• O Database Migration Service só aceita codificações de conjunto UTF8 para o banco de dados de destino. Nomes de esquema e tabela que incluem caracteres que não fazem parte do conjunto de codificação UTF8 não são compatíveis.
• O Database Migration Service é compatível com as seguintes codificações de conjunto de caracteres para bancos de dados Oracle:
  • AL16UTF16
  • AL32UTF8
  • IN8ISCII
  • IW8ISO8859P8
  • JA16SJIS
  • JA16SJISTILDE
  • KO16MSWIN949
  • US7ASCII
  • UTF8
  • WE8ISO8859P1
  • WE8ISO8859P9
  • WE8ISO8859P15
  • WE8MSWIN1252
  • ZHT16BIG5

Tabelas, esquemas e outros objetos

• Durante uma migração, as alterações de linguagem de definição de dados (DDL) em dados, esquemas e metadados não são compatíveis. Se você atualizar o esquema durante a migração, será necessário extrair as alterações para o espaço de trabalho de conversão, converter o código, limpar o destino e executar o job de migração novamente.
• Nomes de colunas de tabela que incluem caracteres que não sejam alfanuméricos ou um sublinhado (_) não são aceitos.
• O tamanho 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 pgtt do PostgreSQL esteja 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.
• No Oracle 11g, as tabelas com colunas de tipos de dados ANYDATA ou UDT não são compatíveis, e a tabela inteira não será replicada.
• Os jobs programados usando dbms_job ou dbms_scheduler nã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 que a migração seja concluída. 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 um limite 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, é preciso extrair o esquema no espaço de trabalho de conversão, aplicar as 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.
• As colunas virtuais (GENERATED ALWAYS AS (...) VIRTUAL) não são replicadas durante a migração de dados porque o Oracle não grava valores de coluna virtual em redo logs. Se uma coluna virtual fizer parte de uma chave primária composta, somente as colunas não virtuais serão usadas como chave primária durante a replicação.

Limitações do tipo de dados

Os seguintes tipos de dados não são compatíveis com migrações do Oracle:

• ANYDATA (No Oracle 11g, as tabelas com ANYDATA não são compatíveis e não são replicadas.)
• BFILE
• INTERVAL DAY TO SECOND
• INTERVAL YEAR TO MONTH
• LONG/LONG RAW
• SDO_GEOMETRY
• UDT
• UROWID
• XMLTYPE
• Datas zero em TIMESTAMP

Considerações sobre chaves primárias

Tabelas sem chaves primárias não garantem uma 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 sem chaves primárias, os espaços de trabalho de conversão do Database Migration Service vão criar automaticamente as chaves primárias ausentes nas tabelas de destino quando você converter o código-fonte e o esquema. Esse processo automatizado exige que as tabelas de origem:

• Não têm chaves primárias.
• Não use uma restrição UNIQUE sem colunas anuláveis.
• Não tenha um índice UNIQUE sem colunas anuláveis.

Se as tabelas não atenderem a esses requisitos, será necessário adicionar manualmente as chaves primárias ausentes às tabelas no esquema do PostgreSQL convertido. Também é possível desativar a geração automática de chave primária com a diretiva de conversão GENERATE_MISSING_PK.

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ê usa espaços de trabalho de conversão legados, precisa 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

Chaves externas e gatilhos presentes no banco de dados de origem podem causar problemas de integridade de dados ou até mesmo falhas no job de migração. Para evitar esses problemas, pule as chaves externas e os gatilhos usando a opção REPLICATION para o usuário da 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 as alterações 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 de dados 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 tabela pai, talvez ocorram 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 suas 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-custom e 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 é gravável durante a migração para permitir que as alterações da linguagem de manipulação de dados (DML) sejam aplicadas, se necessário. Tenha cuidado para não fazer mudanças na configuração do banco de dados ou nas estruturas de tabela que possam interromper o processo de migração ou afetar a integridade de dados.

Cotas

• Até 2.000 perfis de conexão e 1.000 jobs de migração podem existir ao mesmo tempo. Para liberar espaço, é possível excluir jobs de migração (incluindo os concluídos) e perfis de conexão.