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.
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 dados VARCHAR2, os dados são armazenados no destino como VARCHAR.
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ção UTF8 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
ou UDT não são suportadas e toda a tabela não é replicada.
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 com ANYDATA
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.
[[["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-08-21 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."]]
