Gli utenti e le autorizzazioni non vengono migrati.
Le modifiche allo schema che si verificano durante un job di migrazione attivo non vengono migrate automaticamente. Se modifichi lo schema durante la migrazione, devi
prima aggiornare l'area di lavoro di conversione con le modifiche allo schema e poi
aggiornare i job di migrazione pertinenti. Per ulteriori informazioni, vedi
Aggiungere schemi o tabelle aggiornati al job di migrazione.
Le istruzioni SAVEPOINT non sono supportate e possono
causare discrepanze nei dati in caso di rollback.
Database Migration Service replica i tipi di dati definiti dall'utente, ma
memorizza solo il tipo di dati di base da cui derivano i tipi definiti dall'utente.
Ad esempio, se definisci un tipo di dati USERNAME in base al tipo di dati VARCHAR2, i dati vengono archiviati nella destinazione come VARCHAR.
Database, transazioni e coerenza dei dati
La migrazione è coerente nel tempo, in quanto Database Migration Service non
replica ogni transazione in tempo reale. La migrazione importa i dati
da più tabelle. L'ordine in cui i dati vengono caricati nella destinazione può variare, ma si riallinea all'origine dopo l'interruzione delle scritture sull'origine e la cancellazione del buffer di migrazione.
Per le migrazioni eterogenee di Oracle, Database Migration Service può eseguire la migrazione di un solo database per job di migrazione.
Database Migration Service supporta l'architettura multitenant Oracle (CDB/PDB),
ma puoi eseguire la migrazione di un solo database pluggable per job di migrazione.
Oracle Label Security (OLS) non viene replicato.
Il database di destinazione deve avere lo stesso nome dell'utente
utilizzato per connettersi al database.
Eventuali transazioni di rollback nel database di origine durante il processo di migrazione potrebbero essere visibili temporaneamente nella destinazione (se la transazione è sufficientemente lunga).
Database Migration Service non supporta la connettività diretta ai database utilizzando la funzionalità Single Client Access Name (SCAN) negli ambienti Oracle Real Application Clusters (RAC). Per potenziali soluzioni all'utilizzo della connettività della lista consentita IP pubblici con questi ambienti, consulta
Risolvere i problemi relativi agli errori SCAN di Oracle.
Codifica dei dati
Database Migration Service supporta solo le codifiche del set UTF8 per il database di destinazione. I nomi di schemi e tabelle che includono caratteri non
inclusi nel set di codifica UTF8 non sono supportati.
Database Migration Service supporta le seguenti codifiche dei set di caratteri per i database Oracle:
AL16UTF16
AL32UTF8
IN8ISCII
IW8ISO8859P8
JA16SJIS
JA16SJISTILDE
KO16MSWIN949
US7ASCII
UTF8
WE8ISO8859P1
WE8ISO8859P9
WE8ISO8859P15
WE8MSWIN1252
ZHT16BIG5
Tabelle, schemi e altri oggetti
Durante una migrazione, le modifiche al linguaggio di definizione dei dati (DDL) a dati, schemi e metadati non sono supportate. Se aggiorni lo schema durante la migrazione,
devi trasferire le modifiche all'area di lavoro di conversione, convertire il codice,
pulire la destinazione ed eseguire di nuovo il job di migrazione.
I nomi delle colonne della tabella che includono caratteri diversi da quelli alfanumerici
o da un trattino basso (_) non sono supportati.
La lunghezza massima del nome per tabelle o colonne è di 30 caratteri.
Database Migration Service non può replicare tabelle che superano questo limite o tabelle
che contengono colonne i cui nomi superano questo limite.
Le tabelle organizzate per indice (IOT) non sono supportate.
Le tabelle temporanee globali richiedono l'installazione e la creazione dell'estensione pgtt PostgreSQL nella destinazione.
Per le colonne di tipo BFILE, verrà replicato solo il percorso del file. I contenuti del file non verranno replicati.
Per Oracle 11g, le tabelle con colonne di tipi di dati ANYDATA
o UDT non sono supportate e l'intera tabella non verrà replicata.
Le definizioni delle viste materializzate vengono migrate, ma i relativi dati materializzati
no. Al termine della migrazione, aggiorna le viste materializzate per
popolarle con i dati delle tabelle migrate.
I valori di sequenza vengono migrati, ma i loro valori nel database di origine
potrebbero continuare ad aumentare prima del completamento della migrazione. Al termine
della migrazione, aggiorna i valori della sequenza nell'istanza di destinazione in modo che
corrispondano a quelli del database di origine.
I job di migrazione sono limitati a 10.000 tabelle.
Le righe hanno un limite di dimensioni di 100 MB. Le righe che superano il limite di 100 MB
non vengono migrate e vengono visualizzate come errori nel job di migrazione.
Le tabelle create dopo l'inizio della migrazione non vengono migrate
automaticamente. Innanzitutto, devi estrarre lo schema nell'area di lavoro di conversione,
applicare le definizioni convertite alla destinazione e aggiornare il job di migrazione.
Limitazioni dei tipi di dati
I seguenti tipi di dati non sono supportati per le migrazioni Oracle:
ANYDATA (Per Oracle 11g, le tabelle con ANYDATA
non sono supportate e non vengono replicate.)
BFILE
INTERVAL DAY TO SECOND
INTERVAL YEAR TO MONTH
LONG/LONG RAW
SDO_GEOMETRY
UDT
UROWID
XMLTYPE
Zero date in TIMESTAMP
Considerazioni relative alle chiavi primarie
Le tabelle senza chiavi primarie non garantiscono una replica coerente.
Database Migration Service esegue la migrazione solo delle tabelle con chiavi primarie.
Se il database di origine include tabelle senza chiavi primarie, le aree di lavoro di conversione di Database Migration Service creano automaticamente le chiavi primarie mancanti nelle tabelle di destinazione quando
converti il codice sorgente e lo schema.
Se utilizzi gli spazi di lavoro per le conversioni legacy, devi creare manualmente i vincoli di chiave primaria nelle tabelle convertite nel database di destinazione prima di avviare la migrazione. Per ulteriori informazioni, vedi
Workspace di conversione legacy.
Considerazioni su chiavi esterne e trigger
Le chiavi esterne e i trigger presenti nel database di origine potrebbero causare problemi di integrità dei dati o persino l'esito negativo del job di migrazione.
Puoi evitare questi problemi se ignori le chiavi esterne e i trigger
utilizzando l'opzione REPLICATION per l'utente di migrazione.
In alternativa, puoi anche eliminare tutte le chiavi esterne e i trigger nel database di destinazione e ricrearli al termine della migrazione.
Trigger
I dati replicati da Database Migration Service incorporano già le modifiche apportate dai trigger nel database di origine. Se i trigger sono abilitati nella destinazione,
possono attivarsi di nuovo e potenzialmente manipolare i dati, causando problemi di integrità
o duplicazione dei dati.
Chiavi esterne
Database Migration Service non replica i dati in modo transazionale, quindi le tabelle potrebbero essere migrate in modo non sequenziale. Se sono presenti chiavi esterne e una tabella secondaria che utilizza una chiave esterna viene migrata prima della tabella padre, potresti riscontrare errori di replica.
Consigli
Quando
crei il database Cloud SQL di destinazione,
assicurati di utilizzare risorse di calcolo e memoria sufficienti per coprire le tue
esigenze di migrazione. Consigliamo di utilizzare un tipo di macchina con almeno una CPU dual-core.
Ad esempio, se il nome della tua macchina è db-custom e ha 2 CPU e 3840 MB di RAM, il formato del nome del tipo di macchina è db-custom-2-3840.
Il database Cloud SQL di destinazione è scrivibile durante la migrazione
per consentire l'applicazione delle modifiche DML (Data Manipulation Language) se necessario.
Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere la procedura di migrazione o influire sull'integrità dei dati.
Quote
In qualsiasi momento, possono esistere fino a 2000 profili di connessione e 1000 job di migrazione. Per creare spazio, è possibile eliminare i job di migrazione (compresi quelli completati) e i profili di connessione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[[["\u003cp\u003eDatabase Migration Service has limitations on supported characters, including only allowing \u003ccode\u003eUTF8\u003c/code\u003e encoding for the destination database, and not supporting table column names with non-alphanumeric characters or anything other than an underscore.\u003c/p\u003e\n"],["\u003cp\u003eThe service restricts migration jobs to a maximum of 10,000 tables, and only supports single pluggable database migration for Oracle multi-tenant architecture.\u003c/p\u003e\n"],["\u003cp\u003eCertain Oracle features, such as Index-organized tables, Oracle Autonomous Database, \u003ccode\u003eBFILE\u003c/code\u003e types, and many other data types are not supported or will be replaced with NULL values, and scheduled jobs or schema changes won't be migrated either.\u003c/p\u003e\n"],["\u003cp\u003eUp to 2,000 connection profiles and 1,000 migration jobs can exist at any given time, but if more is needed then previously completed migration jobs and connection profiles can be deleted.\u003c/p\u003e\n"],["\u003cp\u003eDirect connectivity to databases using Oracle Real Application Clusters (RAC) Single Client Access Name (SCAN) is not supported by Database Migration Service, and there is also a 100 MB row size limitation.\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-alloydb/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- The destination database must have the same name as the username that's used to connect to the database.\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-alloydb/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-alloydb/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-alloydb/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-alloydb/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-alloydb/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."]]
