As mudanças 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 e depois atualize os jobs de migração relevantes. Para mais informações, consulte
Adicionar esquema 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 rollback.
O Database Migration Service replica tipos de dados definidos pelo usuário, mas armazena apenas o tipo de dados básicos de que você deriva seus tipos definidos pelo usuário.
Por exemplo, se você definir um tipo de dados USERNAME com base no tipo 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, 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 é 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.
As transações revertidas no banco de dados de origem durante o processo de migração podem ficar visíveis temporariamente no destino (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 Oracle Real Application Clusters (RAC). Para possíveis soluções de conectividade usando a lista de permissões de IP público
com esses ambientes, consulte
Solução de problemas de erros do Oracle SCAN.
Codificação de dados
O Database Migration Service só é compatível com codificações de conjunto 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 aceitos.
O Database Migration Service é compatível com as seguintes codificações de conjuntos 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, não há suporte para alterações de 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.
Nomes de colunas de tabelas que incluem caracteres diferentes de alfanuméricos ou um sublinhado (_) não são aceitos.
O comprimento máximo do nome para tabelas ou colunas é de 30 caracteres.
o Database Migration Service não poderá replicar tabelas que excedam esse limite ou 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 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 ANYDATA
ou UDT não são compatíveis, e a tabela inteira não será replicada.
As definições de visualizações materializadas são migradas, mas os dados materializados
não sã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 depois do início da migração não serão migradas automaticamente. Primeiro, extraia o esquema no espaço de trabalho de conversão,
aplique as definições convertidas ao destino e atualize o job de migração.
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 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 iguais a 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 com 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.
Se você usa os espaços de trabalho de conversão legados, é 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 estrangeiras e triggers
Chaves externas e triggers presentes no banco de dados de origem podem causar problemas de integridade de dados ou até mesmo fazer com que o job de migração falhe.
É possível evitar esses problemas se você pular chaves externas e gatilhos
usando a opção REPLICATION para o usuário da migração.
Como alternativa, você também pode 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 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, então as tabelas podem ser migradas fora de ordem. Se houver chaves estrangeiras e uma tabela filha que usa uma chave externa for migrada antes da mãe, poderão ocorrer 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 com pelo menos uma CPU de dois núcleos.
Por exemplo, se o nome da máquina for db-custom e ela 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 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.
Tenha cuidado para não fazer 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 podem ser excluídos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-05 UTC."],[[["\u003cp\u003eDatabase Migration Service only supports \u003ccode\u003eUTF8\u003c/code\u003e encoding for the destination database, and schema or table names not in this set are unsupported.\u003c/p\u003e\n"],["\u003cp\u003eMigration jobs are limited to a maximum of 10,000 tables, and only a single pluggable database can be migrated in one job.\u003c/p\u003e\n"],["\u003cp\u003eCertain data types, including \u003ccode\u003eANYDATA\u003c/code\u003e, \u003ccode\u003eLONG/LONG RAW\u003c/code\u003e, and \u003ccode\u003eXMLTYPE\u003c/code\u003e, are not supported and will be replaced with \u003ccode\u003eNULL\u003c/code\u003e values during migration.\u003c/p\u003e\n"],["\u003cp\u003eThe service does not support schema changes directly; updates must be made in the conversion workspace and relevant migration jobs accordingly.\u003c/p\u003e\n"],["\u003cp\u003eAll tables in the destination database must have a primary key, and if one is not present in the source, one will need to be created.\u003c/p\u003e\n"]]],[],null,["# Known limitations and recommendations\n\nThis page describes known limitations (including special considerations for\nhandling entities like\n[primary keys](#primary-keys-considerations) or\n[foreign keys and triggers](#foreign-keys-triggers-considerations)), as well as\n[recommended practices](#) for heterogeneous Oracle migrations with Database Migration Service.\n\nWhat isn't migrated\n-------------------\n\n- Users and permissions aren't migrated.\n- Schema changes that occur during an active migration job aren't automatically migrated. If you change your schema during the migration, you need to first update the conversion workspace with schema changes, and then refresh the relevant migration jobs. For more information, see [Add updated schema or tables to the migration job](/database-migration/docs/oracle-to-postgresql/manage-migration-jobs#edit-non-draft-job).\n- [`SAVEPOINT` statements](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SAVEPOINT.html) aren't supported and can cause data discrepancy in case of a rollback.\n- Database Migration Service replicates user-defined data types, but only stores the base data type from which you derive your user-defined types. For example, if you define a `USERNAME` data type based on the `VARCHAR2` data type, the data is stored in the destination as `VARCHAR`.\n\nDatabase, transactions and data consistency\n-------------------------------------------\n\n- The migration is eventually consistent, as Database Migration Service doesn't replicate each transaction as it happens. The migration brings in data from multiple tables. The order in which data is loaded into the destination may vary, but re-aligns with the source after writes on the source are stopped and the migration buffer is cleared.\n- For heterogeneous Oracle migrations, Database Migration Service can only migrate one database per migration job.\n- Database Migration Service supports Oracle multi-tenant architecture (CDB/PDB), but you can only migrate a single pluggable database per migration job.\n- Oracle Label Security (OLS) isn't replicated.\n- Any transactions that are rolled back in your source database during the migration process might be visible in the destination temporarily (when the transaction is long enough).\n- Database Migration Service doesn't support direct connectivity to databases using the Single Client Access Name (SCAN) feature in Oracle Real Application Clusters (RAC) environments. For potential solutions to using public IP allowlist connectivity with such environments, see [Troubleshoot Oracle SCAN errors](/database-migration/docs/oracle-to-postgresql/diagnose-issues#troubleshoot-scan).\n\nData encoding\n-------------\n\n- Database Migration Service supports only `UTF8` set encodings for the destination database. Schema and table names that include characters which aren't part of the `UTF8` encoding set are not supported.\n- Database Migration Service supports the following character set encodings for Oracle databases:\n - `AL16UTF16`\n - `AL32UTF8`\n - `IN8ISCII`\n - `IW8ISO8859P8`\n - `JA16SJIS`\n - `JA16SJISTILDE`\n - `KO16MSWIN949`\n - `US7ASCII`\n - `UTF8`\n - `WE8ISO8859P1`\n - `WE8ISO8859P9`\n - `WE8ISO8859P15`\n - `WE8MSWIN1252`\n - `ZHT16BIG5`\n\nTables, schemas, and other objects\n----------------------------------\n\n- During a migration, data definition language (DDL) changes to data, schemas, and metadata aren't supported. If you update your schema during the migration, you need to pull the changes to your conversion workspace, convert the code, clean your destination and run the migration job again.\n- Table column names that include characters other than alphanumeric characters or an underscore (`_`) aren't supported.\n- Maximum name length for tables or columns is 30 characters. Database Migration Service can't replicate tables that exceed this limit, or tables that contain columns whose names exceed this limit.\n- Index-organized tables (IOTs) aren't supported.\n- Global temporary tables require the `pgtt` PostgreSQL extension installed and created on the destination.\n- For columns of type `BFILE`, only the path to the file will be replicated. The contents of the file won't be replicated.\n- For Oracle 11g, tables that have columns of data types `ANYDATA` or `UDT` aren't supported, and the entire table won't be replicated.\n- Jobs that are scheduled by using [`dbms_job`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_JOB.html) or [`dbms_scheduler`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html) aren't migrated.\n- Materialized views definitions are migrated, but their materialized data isn't. After you finish migrating, refresh your materialized views in order to populate them with data from the migrated tables.\n- Sequence values are migrated, but their values in the source database might keep advancing before the migration is completed. After complete the migration, update the sequence values on the destination instance to match those in the source database.\n- Migration jobs are limited to 10,000 tables.\n- Rows have a size limitation of 100 MB. Rows that exceed the 100 MB limit are not migrated, and show up as errors in the migration job.\n- Any tables that are created after the migration has started aren't be migrated automatically. First, you need to pull their schema in the conversion workspace, apply converted definitions to the destination, and update the migration job.\n\n### Data type limitations\n\nThe following data types are unsupported for Oracle migrations:\n\n- `ANYDATA` (For Oracle 11g, tables with `ANYDATA` are completely unsupported and not replicated.)\n- `BFILE`\n- `INTERVAL DAY TO SECOND`\n- `INTERVAL YEAR TO MONTH`\n- `LONG/LONG RAW`\n- `SDO_GEOMETRY`\n- `UDT`\n- `UROWID`\n- `XMLTYPE`\n- **Zero dates** in `TIMESTAMP`\n\n### Considerations for primary keys\n\nTables without primary keys don't promise consistent replication.\nDatabase Migration Service migrates only tables that have primary keys.\nIf your source database includes tables that don't have primary keys,\nDatabase Migration Service conversion workspaces automatically create any missing\nprimary keys in the destination tables when you\n[convert your source code and schema](/database-migration/docs/oracle-to-postgresql/convert-sql).\n\nIf you use legacy conversion workspaces, you need to manually create primary\nkey constraints in the converted tables in the destination database before\nyou start the migration. For more information, see\n[Legacy conversion workspaces](/database-migration/docs/oracle-to-postgresql/legacy-conversion-workspaces).\n\n### Considerations for foreign keys and triggers\n\nForeign keys and triggers present in your source database might lead to\ndata integrity issues, or even cause the migration job to fail.\nYou can prevent these issues if you skip foreign keys and triggers\n[by using the `REPLICATION` option for the migration user](/database-migration/docs/oracle-to-postgresql/configure-your-destination-postgresql-database).\nAlternatively, you can also drop all foreign keys and triggers in the destination\ndatabase and re-create them when the migration is complete.\n\n#### Triggers\n\nData replicated by Database Migration Service already incorporates any changes made by\ntriggers on the source database. If triggers are enabled on the destination,\nthey can fire again and potentially manipulate data, resulting in data integrity\nor duplication issues.\n\n#### Foreign keys\n\nDatabase Migration Service doesn't replicate data in a transactional\nmanner, so tables might be migrated out of order. If foreign keys are present,\nand a child table that uses a foreign key is migrated before its parent, you might\nencounter replication errors.\n\nRecommendations\n---------------\n\n- When you [create your destination Cloud SQL database](/database-migration/docs/oracle-to-postgresql/configure-your-destination-postgresql-database), make sure that you use enough compute and memory resources to cover your migration needs. We recommend a machine type with at least a dual-core CPU.\n\n For example, if your machine name is `db-custom`, and it has\n 2 CPUs and 3840 MB of RAM, then the format for the machine type name\n is `db-custom-2-3840`.\n- The destination Cloud SQL database is writable during the migration to allow Data Manipulation Language (DML) changes to be applied if needed. Take care not to make any changes to the database configuration or table structures which might break the migration process or impact data integrity.\n\nQuotas\n------\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
