Esta página descreve as limitações conhecidas (incluindo considerações especiais para processar entidades como chaves primárias ou chaves estrangeiras e acionadores), bem como práticas recomendadas para migrações heterogéneas do Oracle com o serviço de migração de bases de dados.
O que não é migrado
- Os utilizadores e as autorizações não são migrados.
- As alterações ao esquema que ocorrem durante uma tarefa de migração ativa não são migradas automaticamente. Se alterar o esquema durante a migração, tem de: Primeiro, atualizar o espaço de trabalho de conversão com as alterações ao esquema e, de seguida, atualizar as tarefas de migração relevantes. Para mais informações, consulte o artigo Adicione o esquema ou as tabelas atualizados à tarefa de migração.
- As declarações
SAVEPOINT
não são suportadas e podem causar discrepâncias nos dados em caso de reversão. -
O serviço de migração de bases de dados replica os tipos de dados definidos pelo utilizador, mas apenas
armazena o tipo de dados base a partir do qual deriva os seus tipos definidos pelo utilizador.
Por exemplo, se definir um tipo de dados
USERNAME
com base no tipo de dadosVARCHAR2
, os dados são armazenados no destino comoVARCHAR
.
Base de dados, transações e consistência dos dados
- A migração é eventualmente consistente, uma vez que o serviço de migração de bases de dados não replica cada transação à medida que ocorre. A migração importa dados de várias tabelas. A ordem pela qual os dados são carregados no destino pode variar, mas volta a alinhar-se com a origem depois de as gravações na origem serem interrompidas e o buffer de migração ser limpo.
- Para migrações heterogéneas do Oracle, o serviço de migração de bases de dados só pode migrar uma base de dados por tarefa de migração.
- O serviço de migração de bases de dados suporta a arquitetura multi-inquilino da Oracle (CDB/PDB), mas só pode migrar uma única base de dados conectável por tarefa de migração.
- A segurança de etiquetas da Oracle (OLS) não é replicada.
- Quaisquer transações revertidas na base de dados de origem durante o processo de migração podem ser visíveis no destino temporariamente (quando a transação é suficientemente longa).
- O serviço de migração de base de dados não suporta a conetividade direta a bases de dados através da funcionalidade Single Client Access Name (SCAN) em ambientes Oracle Real Application Clusters (RAC). Para potenciais soluções para usar a conetividade da lista de autorizações de IP público com esses ambientes, consulte o artigo Resolva problemas de erros de SCAN da Oracle.
Codificação de dados
- O Database Migration Service suporta apenas codificações de conjuntos de carateres
UTF8
para a base de dados de destino. Os nomes de esquemas e tabelas que incluem carateres que não fazem parte do conjunto de codificaçãoUTF8
não são suportados. - O serviço de migração de base de dados suporta as seguintes codificações de conjuntos de carateres para bases 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 à linguagem de definição de dados (LDD) aos dados, esquemas e metadados não são suportadas. Se atualizar o esquema durante a migração, tem de extrair as alterações para o espaço de trabalho de conversão, converter o código, limpar o destino e executar novamente a tarefa de migração.
- Os nomes das colunas das tabelas que incluem carateres que não sejam alfanuméricos
ou um sublinhado (
_
) não são suportados. - O comprimento máximo do nome para tabelas ou colunas é de 30 carateres. O Database Migration Service não pode replicar tabelas que excedam este limite nem tabelas que contenham colunas cujos nomes excedam este 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 para o ficheiro é replicado. O conteúdo do ficheiro não é replicado. - Para o Oracle 11g, as tabelas que têm colunas de tipos de dados
ANYDATA
ouUDT
não são suportadas e toda a tabela não é replicada. - As tarefas agendadas através de
dbms_job
oudbms_scheduler
não são migradas. - As definições das vistas materializadas são migradas, mas os respetivos dados materializados não são. Depois de concluir a migração, atualize as vistas materializadas para as preencher com dados das tabelas migradas.
- Os valores de sequência são migrados, mas os respetivos valores na base de dados de origem podem continuar a avançar antes de a migração estar concluída. Após a conclusão da migração, atualize os valores da sequência na instância de destino para corresponder aos da base de dados de origem.
- As tarefas de migração estão limitadas 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 são apresentadas como erros na tarefa de migração.
- As tabelas criadas após o início da migração não são migradas automaticamente. Primeiro, tem de extrair o esquema no espaço de trabalho de conversão, aplicar as definições convertidas ao destino e atualizar a tarefa de migração.
Limitações de tipo de dados
Os seguintes tipos de dados não são suportados para migrações do Oracle:
ANYDATA
(Para o Oracle 11g, as tabelas comANYDATA
não são 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 para chaves primárias
As tabelas sem chaves primárias não garantem uma replicação consistente. O Database Migration Service migra apenas tabelas que tenham chaves principais. Se a base de dados de origem incluir tabelas que não tenham chaves primárias, os espaços de trabalho de conversão do serviço de migração de bases de dados criam automaticamente as chaves primárias em falta nas tabelas de destino quando converte o código fonte e o esquema.
Se usar espaços de trabalho de conversão antigos, tem de criar manualmente restrições de chave primária nas tabelas convertidas na base de dados de destino antes de iniciar a migração. Para mais informações, consulte o artigo Espaços de trabalho de conversão antigos.
Considerações para chaves externas e acionadores
As chaves externas e os acionadores presentes na base de dados de origem podem originar problemas de integridade dos dados ou até fazer com que a tarefa de migração falhe.
Pode evitar estes problemas se ignorar as chaves externas e os acionadores
usando a opção REPLICATION
para o utilizador de migração.
Em alternativa, também pode eliminar todas as chaves externas e acionadores na base de dados de destino e recriá-los quando a migração estiver concluída.
Acionadores
Os dados replicados pelo Database Migration Service já incorporam quaisquer alterações feitas por acionadores na base de dados de origem. Se os acionadores estiverem ativados no destino, podem ser acionados novamente e, potencialmente, manipular dados, o que resulta em problemas de integridade ou duplicação de dados.
Chaves externas
O Database Migration Service não replica os dados de forma transacional, pelo que as tabelas podem ser migradas fora de ordem. Se existirem chaves externas e uma tabela secundária que use uma chave externa for migrada antes da respetiva tabela principal, pode ocorrer um erro de replicação.
Recomendações
- Quando
criar a base de dados do Cloud SQL de destino,
certifique-se de que usa recursos de computação e memória suficientes para cobrir as suas
necessidades de migração. Recomendamos um tipo de máquina com, pelo menos, uma CPU de dois núcleos.
Por exemplo, se o nome do computador for
db-custom
e tiver 2 CPUs e 3840 MB de RAM, o formato do nome do tipo de computador édb-custom-2-3840
. - A base de dados do Cloud SQL de destino é 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 alterações à configuração da base de dados nem às estruturas das tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.
Quotas
- Podem existir até 2000 perfis de ligação e 1000 tarefas de migração em qualquer altura. Para criar espaço para mais, pode eliminar tarefas de migração (incluindo as concluídas) e perfis de ligação.