Limitações e recomendações conhecidas

Esta página descreve limitações conhecidas (incluindo considerações especiais para lidar com entidades como chaves primárias ou chaves estrangeiras 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 alterações de esquema que ocorrem durante um trabalho de migração ativo não são migradas automaticamente. Se você alterar seu esquema durante a migração, primeiro será necessário atualizar o espaço de trabalho de conversão com alterações de esquema e, em seguida, atualizar os trabalhos de migração relevantes. Para obter mais informações, consulte Adicionar esquema ou tabelas atualizados ao trabalho de migração .
  • As instruções SAVEPOINT não são suportadas 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 armazena apenas o tipo de dados base do qual você deriva seus 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 é eventualmente consistente, pois o Database Migration Service não replica cada transação à medida que ela acontece. A migração traz dados de diversas 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 Oracle heterogêneas, o Database Migration Service só pode migrar um banco de dados por trabalho de migração.
  • O Database Migration Service oferece suporte à arquitetura multilocatário Oracle (CDB/PDB), mas você só pode migrar um único banco de dados conectável por trabalho de migração.
  • O Oracle Label Security (OLS) não é replicado.
  • O banco de dados de destino deve ter o mesmo nome do nome de usuário usado para conectar-se ao banco de dados.
  • Quaisquer transações revertidas em seu banco de dados de origem durante o processo de migração poderão ficar visíveis temporariamente no destino (quando a transação for 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 Oracle Real Application Clusters (RAC). Para obter possíveis soluções para usar a conectividade de lista de permissões de IP público com esses ambientes, consulte Solucionar problemas de erros do Oracle SCAN .

Codificação de dados

  • O Database Migration Service oferece suporte apenas a codificações definidas UTF8 para o banco de dados de destino. Nomes de esquemas e tabelas que incluem caracteres que não fazem parte do conjunto de codificação UTF8 não são suportados.
  • O Database Migration Service oferece suporte às seguintes codificações de conjunto de caracteres para bancos de dados Oracle:
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • JA16SJIS
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

Tabelas, esquemas e outros objetos

  • Durante uma migração, não há suporte para alterações de linguagem de definição de dados (DDL) em dados, esquemas e metadados. Se você atualizar seu esquema durante a migração, precisará efetuar pull das alterações em seu espaço de trabalho de conversão, converter o código, limpar seu destino e executar o trabalho de migração novamente.
  • Nomes de colunas de tabela que incluem caracteres diferentes de caracteres alfanuméricos ou sublinhado ( _ ) não são suportados.
  • O comprimento máximo do nome para tabelas ou colunas é de 30 caracteres. O Database Migration Service não pode replicar tabelas que excedam esse limite ou tabelas que contenham colunas cujos nomes excedam esse limite.
  • As tabelas organizadas por índice (IOTs) não são suportadas.
  • As tabelas temporárias globais requerem a extensão pgtt PostgreSQL instalada e criada no destino.
  • Para colunas do tipo BFILE , apenas o caminho do arquivo será replicado. O conteúdo do arquivo não será replicado.
  • Para Oracle 11g, tabelas que possuem colunas de tipos de dados ANYDATA ou UDT não são suportadas e a tabela inteira não será replicada.
  • Os trabalhos agendados usando dbms_job ou dbms_scheduler não são migrados.
  • As definições de visualizações materializadas são migradas, mas seus dados materializados não. Após concluir a migração, atualize suas visualizações materializadas para preenchê-las com dados das tabelas migradas.
  • Os valores de sequência são migrados, mas seus valores no banco de dados de origem podem continuar avançando antes que a migração seja concluída. Após 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 trabalhos de migração estã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 trabalho de migração.
  • Quaisquer tabelas criadas após o início da migração não serão migradas automaticamente. Primeiro, você precisa extrair o esquema no espaço de trabalho de conversão, aplicar as definições convertidas ao destino e atualizar o trabalho de migração.

Limitações de tipo de dados

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

  • ANYDATA (Para Oracle 11g, tabelas com ANYDATA não são totalmente suportadas e não são replicadas.)
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • Zero datas 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 possuem chaves primárias. Se o seu banco de dados de origem incluir tabelas que não possuem chaves primárias, os espaços de trabalho de conversão do Database Migration Service criarão automaticamente quaisquer chaves primárias ausentes nas tabelas de destino quando você converter o código-fonte e o esquema .

Se você usar espaços de trabalho de conversão herdados, 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 obter mais informações, consulte Espaços de trabalho de conversão legados .

Considerações sobre chaves estrangeiras e gatilhos

Chaves estrangeiras e gatilhos presentes em seu banco de dados de origem podem levar a problemas de integridade de dados ou até mesmo causar falha no trabalho de migração. Você pode evitar esses problemas ignorando chaves estrangeiras e acionadores usando a opção REPLICATION para o usuário de migração . Alternativamente, você também pode descartar todas as chaves estrangeiras 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 quaisquer alterações feitas por gatilhos no banco de dados de origem. Se os gatilhos estiverem habilitados no destino, eles poderão disparar novamente e potencialmente manipular os dados, resultando em problemas de integridade ou duplicação de dados.

Chaves estrangeiras

O Database Migration Service não replica dados de maneira transacional, portanto as tabelas podem ser migradas fora de ordem. Se chaves estrangeiras estiverem presentes e uma tabela filha que usa uma chave estrangeira for migrada antes de sua pai, você poderá encontrar erros de replicação.

Recomendações

  • Ao criar seu banco de dados Cloud SQL de destino , certifique-se de usar recursos de computação e memória suficientes para atender às suas necessidades de migração. Recomendamos um tipo de máquina com pelo menos uma CPU dual-core.

    Por exemplo, se o nome da sua máquina for db-custom e tiver 2 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 Cloud SQL de destino pode ser gravado durante a migração para permitir que alterações na linguagem de manipulação de dados (DML) sejam aplicadas, se necessário. Tome cuidado para não fazer alterações na configuração do banco de dados ou nas estruturas da tabela que possam interromper o processo de migração ou afetar a integridade dos dados.

Cotas

  • Podem existir até 2.000 perfis de conexão e 1.000 trabalhos de migração a qualquer momento. Para criar espaço para mais, os trabalhos de migração (incluindo os concluídos) e os perfis de conexão podem ser excluídos.