Perubahan skema yang terjadi selama tugas migrasi aktif tidak akan
dimigrasikan secara otomatis. Jika Anda mengubah skema selama migrasi, Anda harus
memperbarui ruang kerja konversi terlebih dahulu dengan perubahan skema, lalu
memuat ulang tugas migrasi yang relevan. Untuk mengetahui informasi selengkapnya, lihat
Menambahkan skema atau tabel yang diperbarui ke tugas migrasi.
Pernyataan SAVEPOINT tidak didukung dan dapat
menyebabkan perbedaan data jika terjadi rollback.
Database Migration Service mereplikasi jenis data yang ditentukan pengguna, tetapi hanya menyimpan jenis data dasar dari mana Anda mendapatkan jenis yang ditentukan pengguna.
Misalnya, jika Anda menentukan jenis data USERNAME berdasarkan jenis data
VARCHAR2, data akan disimpan di tujuan sebagai
VARCHAR.
Database, transaksi, dan konsistensi data
Migrasi pada akhirnya konsisten, karena Database Migration Service tidak
mereplikasi setiap transaksi saat terjadi. Migrasi ini mengambil data
dari beberapa tabel. Urutan pemuatan data ke tujuan dapat bervariasi, tetapi akan disesuaikan kembali dengan sumber setelah penulisan di sumber dihentikan dan buffer migrasi dikosongkan.
Untuk migrasi Oracle heterogen, Database Migration Service hanya dapat memigrasikan
satu database per tugas migrasi.
Database Migration Service mendukung arsitektur multi-tenant Oracle (CDB/PDB),
tetapi Anda hanya dapat memigrasikan satu database yang dapat di-plug per tugas migrasi.
Oracle Label Security (OLS) tidak direplikasi.
Database tujuan harus memiliki nama yang sama dengan nama pengguna yang
digunakan untuk terhubung ke database.
Setiap transaksi yang di-roll back di database sumber Anda selama
proses migrasi mungkin terlihat di tujuan untuk sementara
(jika transaksi cukup lama).
Database Migration Service tidak mendukung konektivitas langsung ke database menggunakan fitur Nama Akses Klien Tunggal (SCAN) di lingkungan Oracle Real Application Clusters (RAC). Untuk mengetahui potensi solusi penggunaan konektivitas daftar yang diizinkan IP publik dengan lingkungan tersebut, lihat
Memecahkan masalah error SCAN Oracle.
Encoding data
Database Migration Service hanya mendukung encoding yang ditetapkan UTF8 untuk
database tujuan. Nama skema dan tabel yang menyertakan karakter yang bukan bagian dari set encoding UTF8 tidak didukung.
Database Migration Service mendukung encoding set karakter berikut untuk database Oracle:
AL16UTF16
AL32UTF8
IN8ISCII
IW8ISO8859P8
JA16SJIS
JA16SJISTILDE
KO16MSWIN949
US7ASCII
UTF8
WE8ISO8859P1
WE8ISO8859P9
WE8ISO8859P15
WE8MSWIN1252
ZHT16BIG5
Tabel, skema, dan objek lainnya
Selama migrasi, perubahan bahasa definisi data (DDL) pada data, skema,
dan metadata tidak didukung. Jika Anda memperbarui skema selama migrasi,
Anda perlu menarik perubahan ke ruang kerja konversi, mengonversi kode,
membersihkan tujuan, dan menjalankan tugas migrasi lagi.
Nama kolom tabel yang menyertakan karakter selain karakter alfanumerik
atau garis bawah (_) tidak didukung.
Panjang maksimum nama untuk tabel atau kolom adalah 30 karakter.
Database Migration Service tidak dapat mereplikasi tabel yang melebihi batas ini, atau tabel
yang berisi kolom dengan nama yang melebihi batas ini.
Tabel yang diatur indeks (IOT) tidak didukung.
Tabel sementara global memerlukan ekstensi pgtt PostgreSQL
yang diinstal dan dibuat di tujuan.
Untuk kolom berjenis BFILE, hanya jalur ke file yang akan direplikasi. Isi file tidak akan direplikasi.
Untuk Oracle 11g, tabel yang memiliki kolom jenis data ANYDATA
atau UDT tidak didukung, dan seluruh tabel tidak akan direplikasi.
Definisi tampilan terwujud dimigrasikan, tetapi data terwujudnya tidak. Setelah selesai melakukan migrasi, refresh tampilan terwujud Anda untuk
mengisinya dengan data dari tabel yang dimigrasikan.
Nilai urutan dimigrasikan, tetapi nilainya dalam database sumber
mungkin terus bertambah sebelum migrasi selesai. Setelah selesai
migrasi, perbarui nilai urutan pada instance tujuan agar
sesuai dengan nilai di database sumber.
Tugas migrasi dibatasi hingga 10.000 tabel.
Baris memiliki batasan ukuran 100 MB. Baris yang melebihi batas 100 MB tidak dimigrasikan, dan muncul sebagai error dalam tugas migrasi.
Tabel apa pun yang dibuat setelah migrasi dimulai tidak akan dimigrasikan secara otomatis. Pertama, Anda perlu menarik skema mereka di ruang kerja konversi,
menerapkan definisi yang dikonversi ke tujuan, dan memperbarui tugas migrasi.
Batasan jenis data
Jenis data berikut tidak didukung untuk migrasi Oracle:
ANYDATA (Untuk Oracle 11g, tabel dengan ANYDATA
tidak didukung sepenuhnya dan tidak direplikasi.)
BFILE
INTERVAL DAY TO SECOND
INTERVAL YEAR TO MONTH
LONG/LONG RAW
SDO_GEOMETRY
UDT
UROWID
XMLTYPE
Zero dates di TIMESTAMP
Pertimbangan untuk kunci utama
Tabel tanpa kunci utama tidak menjanjikan replikasi yang konsisten.
Database Migration Service hanya memigrasikan tabel yang memiliki kunci utama.
Jika database sumber Anda menyertakan tabel yang tidak memiliki kunci utama,
ruang kerja konversi Database Migration Service akan otomatis membuat kunci utama
yang tidak ada di tabel tujuan saat Anda
mengonversi kode sumber dan skema.
Jika menggunakan ruang kerja konversi lama, Anda harus membuat batasan kunci primer secara manual di tabel yang dikonversi dalam database tujuan sebelum memulai migrasi. Untuk mengetahui informasi selengkapnya, lihat
Ruang kerja konversi lama.
Pertimbangan untuk kunci asing dan pemicu
Kunci asing dan pemicu yang ada di database sumber Anda dapat menyebabkan masalah integritas data, atau bahkan menyebabkan tugas migrasi gagal.
Anda dapat mencegah masalah ini jika Anda melewati kunci asing dan pemicu
dengan menggunakan opsi REPLICATION untuk pengguna migrasi.
Atau, Anda juga dapat menghapus semua kunci asing dan pemicu di database tujuan
dan membuatnya ulang setelah migrasi selesai.
Pemicu
Data yang direplikasi oleh Database Migration Service sudah menggabungkan perubahan apa pun yang dilakukan oleh pemicu pada database sumber. Jika pemicu diaktifkan di tujuan, pemicu dapat diaktifkan lagi dan berpotensi memanipulasi data, sehingga menyebabkan masalah integritas atau duplikasi data.
Kunci asing
Database Migration Service tidak mereplikasi data secara transaksional, sehingga tabel mungkin dimigrasikan secara tidak berurutan. Jika ada kunci asing,
dan tabel turunan yang menggunakan kunci asing dimigrasikan sebelum induknya, Anda mungkin
menemui error replikasi.
Rekomendasi
Saat Anda
membuat database Cloud SQL tujuan,
pastikan Anda menggunakan resource komputasi dan memori yang cukup untuk memenuhi
kebutuhan migrasi Anda. Sebaiknya gunakan jenis mesin dengan CPU minimal dual-core.
Misalnya, jika nama mesin Anda adalah db-custom, dan memiliki
2 CPU dan RAM 3840 MB, maka format nama jenis mesin
adalah db-custom-2-3840.
Database Cloud SQL tujuan dapat ditulis selama migrasi
untuk memungkinkan perubahan Bahasa Pengolahan Data (DML) diterapkan jika diperlukan.
Berhati-hatilah agar tidak membuat perubahan apa pun pada konfigurasi database atau struktur tabel yang dapat mengganggu proses migrasi atau memengaruhi integritas data.
Kuota
Hingga 2.000 profil koneksi dan 1.000 tugas migrasi dapat ada pada waktu tertentu. Untuk mengosongkan ruang, tugas migrasi (termasuk yang telah selesai)
dan profil koneksi dapat dihapus.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
