Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Ruang kerja konversi

Ruang kerja konversi membantu Anda mengonversi skema dan objek dari database sumber ke sintaksis SQL yang kompatibel dengan database tujuan. Halaman ini memberikan ringkasan ruang kerja konversi Database Migration Service:

Opsi inisialisasi skema sumber menjelaskan cara mengisi ruang kerja Anda dengan menghubungkan langsung ke database atau dengan mengupload file skema ke Cloud Storage.
Ringkasan konversi memberikan gambaran umum tentang progres konversi skema Anda.
Objek yang didukung oleh konversi kode dan skema deterministik mencantumkan objek Oracle yang didukung untuk konversi skema deterministik.
Editor SQL interaktif menjelaskan objek yang dapat Anda ubah langsung di editor ruang kerja konversi.
Fitur konversi yang didukung Gemini membahas cara Anda dapat mengintegrasikan dukungan AI generatif untuk mempercepat proses konversi skema.
Bagian File pemetaan konversi memberikan ringkasan arahan penyesuaian yang dapat Anda gunakan untuk mengganti aturan konversi skema deterministik.
Ruang kerja konversi lama menjelaskan ruang kerja lama yang tidak memberikan dukungan untuk editor SQL interaktif.

Ada jenis data tertentu yang tidak didukung untuk migrasi Oracle. Untuk mengetahui informasi selengkapnya, lihat Batasan umum untuk jenis data.

Opsi inisialisasi skema sumber

Untuk mengonversi skema database, Database Migration Service memerlukan snapshot awal objek database sumber Anda. Anda dapat memberikan snapshot ini dengan dua cara:

Koneksi database langsung: Database Migration Service terhubung langsung ke database sumber yang sedang berjalan melalui profil koneksi dan mengambil skema melalui koneksi jaringan.
File skema di Cloud Storage: Anda dapat mengekstrak metadata skema secara lokal menggunakan skrip ekstraksi yang disediakan Google, mengupload file yang dihasilkan ke bucket Cloud Storage, dan menyiapkan ruang kerja tanpa terhubung ke database sumber.

Untuk mempelajari cara membuat ruang kerja konversi dengan koneksi database langsung atau dengan file skema di Cloud Storage, lihat Membuat ruang kerja konversi.

Ringkasan progres konversi

Informasi ringkasan yang lengkap tentang ruang kerja konversi, tempat Anda dapat memperoleh insight tentang jumlah total masalah konversi yang belum terselesaikan atau sudah diselesaikan, augmentasi yang dibantu Gemini, dan kondisi umum proses konversi Anda.

Layar ruang kerja konversi dengan tab Ringkasan Konversi tempat Anda dapat melihat jumlah objek yang dikonversi, masalah konversi, dan peningkatan konversi yang dibantu Gemini. — **Gambar 1.** Layar ringkasan ruang kerja konversi, tempat Anda dapat memantau progres konversi, melihat masalah, dan memeriksa kode PostgreSQL yang dihasilkan. (klik untuk memperbesar)

Anda dapat menggunakan tampilan ini untuk memfilter objek dalam skema berdasarkan jenis, tingkat keparahan masalah, tindakan yang diperlukan, atau status konversi.

Layar ruang kerja konversi yang menunjukkan cara memfilter objek yang dikonversi berdasarkan jenis atau status. — **Gambar 2.** Pemfilteran objek yang dikonversi menurut status dan jenis objek. (klik untuk memperbesar)

Untuk mengetahui informasi selengkapnya tentang cara menggunakan ringkasan konversi untuk memeriksa hasil konversi, lihat Bekerja dengan ruang kerja konversi.

Konversi kode dan skema deterministik

Saat Anda membuat ruang kerja konversi, Database Migration Service akan segera melakukan konversi skema awal menggunakan serangkaian aturan konversi deterministik, yang memetakan jenis data dan objek Oracle tertentu ke jenis data dan objek PostgreSQL tertentu. Proses ini mendukung subset objek database Oracle yang tersedia dan sangat spesifik.

Konversi kode deterministik memberikan dukungan untuk objek database Oracle berikut:

Elemen skema Oracle yang didukung

Batasan
Indeks (hanya indeks yang dibuat dalam skema yang sama dengan tabelnya)
Tampilan Terwujud
Jenis Objek (dukungan parsial)
Urutan
Sinonim
Tabel
Tampilan

Elemen kode Oracle yang didukung

Pemicu (khusus tingkat tabel)
Paket
Fungsi
Prosedur Tersimpan

Editor SQL interaktif

Editor SQL interaktif memungkinkan Anda mengubah sintaksis PostgreSQL yang dikonversi langsung di Database Migration Service. Anda dapat menggunakannya untuk memperbaiki masalah konversi atau menyesuaikan skema agar lebih sesuai dengan kebutuhan Anda. Beberapa objek tidak dapat diubah di editor bawaan.

Objek Oracle yang dapat diedit

Setelah mengonversi kode dan skema database sumber, Anda dapat menggunakan editor interaktif untuk mengubah SQL yang dihasilkan untuk jenis objek tertentu. Objek Oracle berikut didukung oleh editor:

Pemicu tabel (memerlukan izin)
Tampilan terwujud
Paket
Fungsi, prosedur tersimpan
Sinonim
Tampilan
Batasan
Indeks
Urutan

Selain itu, beberapa objek dikonversi, tetapi tidak tersedia untuk diedit langsung di dalam Database Migration Service. Untuk mengubah objek tersebut, Anda harus melakukan update langsung pada database tujuan setelah menerapkan skema dan kode yang dikonversi.

Objek yang tidak didukung untuk pengeditan:

Jenis objek yang ditentukan pengguna
Tabel
Skema

Mempercepat konversi kode dan skema dengan Gemini

Database Migration Service mengintegrasikan Gemini untuk Google Cloud ke dalam ruang kerja konversi guna membantu Anda mempercepat dan meningkatkan proses konversi di area berikut:

Tingkatkan hasil konversi deterministik dengan konversi otomatis yang didukung Gemini untuk menggunakan kecanggihan AI guna mengurangi jumlah penyesuaian manual yang diperlukan dalam kode PostgreSQL Anda secara signifikan.
Pastikan kualitas dan kesetaraan fungsional kode yang dikonversi dengan penilaian kualitas yang didukung Gemini. Penilaian ini menganalisis kode yang dikonversi, memberikan masukan tentang kebenaran dan fungsinya dibandingkan dengan kode sumber.
Menyediakan fitur keterjelasan kode dengan asisten konversi: serangkaian perintah khusus yang dapat membantu Anda lebih memahami logika konversi, mengusulkan perbaikan untuk masalah konversi, atau mengoptimalkan kode yang dikonversi.
Percepat penerapan perbaikan untuk masalah konversi dengan saran konversi kode Gemini: mekanisme yang memungkinkan model Gemini belajar saat Anda memperbaiki masalah konversi dan menyarankan perubahan pada objek lain yang bermasalah di ruang kerja.

Untuk mengetahui informasi selengkapnya tentang konversi yang didukung Gemini, lihat halaman berikut:

File pemetaan konversi

Anda dapat menyesuaikan logika konversi dengan file pemetaan konversi. File pemetaan konversi adalah file teks yang berisi petunjuk yang tepat (disebut sebagai perintah konversi) tentang cara objek Oracle Anda harus dikonversi menjadi objek PostgreSQL.

Perintah konversi yang didukung

Database Migration Service mendukung perintah konversi berikut untuk file pemetaan konversi:

`EXPORT_SCHEMA`

EXPORT_SCHEMA adalah perintah wajib untuk semua file pemetaan konversi. Database Migration Service memerlukan petunjuk ini untuk memastikan bahwa skema sumber Anda dikonversi ke skema tujuan yang benar. Pastikan file pemetaan konversi Anda menyertakan baris ini:

EXPORT_SCHEMA 1

`SCHEMA`

Database Migration Service harus dapat menentukan skema mana yang berisi objek yang harus diubah dengan perintah konversi Anda. Perintah SCHEMA menyebabkan semua perintah penyesuaian lainnya yang disediakan dalam file Anda diterapkan ke objek dalam skema tertentu ini.

Saat Anda menggunakan perintah ini, skema lain yang ada dalam database Anda juga akan dikonversi, tetapi objeknya tidak akan diubah.
Jika Anda menyertakan perintah ini dalam file pemetaan konversi, semua penyesuaian hanya akan diterapkan ke objek yang terdapat dalam skema khusus ini.
Jika Anda melewati perintah ini, Anda harus memberikan nama objek yang sepenuhnya memenuhi syarat yang menyertakan nama skema untuk objek yang diubah oleh perintah konversi lainnya. Misalnya, alih-alih menggunakan SOURCE_TABLE_NAME untuk perintah REPLACE_TABLES, Anda harus menggunakan "SCHEMA_NAME.SOURCE_TABLE_NAME".
Untuk menyesuaikan objek dalam skema yang berbeda, coba langkah berikut:
- Buat file pemetaan konversi terpisah untuk skema lain, dan upload ke ruang kerja konversi.
- Gunakan nama objek yang sepenuhnya memenuhi syarat yang menyertakan nama skema untuk objek yang berada dalam skema yang berbeda dengan yang Anda berikan ke perintah SCHEMA.

Gunakan format berikut:

SCHEMA SCHEMA_NAME

Dengan SCHEMA_NAME adalah nama skema Anda di database sumber.

`CASE_HANDLING`

Secara default, Database Migration Service mengonversi semua nama objek menjadi huruf kecil. Anda dapat menggunakan perintah CASE_HANDLING untuk mengubah perilaku ini.

Perintah ini tidak terpengaruh oleh perintah SCHEMA. Aturan ini berfungsi secara global, dan memengaruhi semua objek di ruang kerja konversi.
Perintah RENAME_*, MOVE_*, dan REPLACE_* lebih diutamakan daripada perintah CASE_HANDLING dan mengganti nama objek Anda secara persis, terlepas dari properti CASE_HANDLING.
Jika perintah ini ada di beberapa file konfigurasi dengan nilai yang bertentangan, Database Migration Service akan memunculkan error selama impor skema.

Gunakan format berikut:

CASE_HANDLING OPTION

Dengan OPTION dapat berupa salah satu dari hal berikut:

UPPERCASE: Mengonversi semua nama objek menjadi huruf besar.
LOWERCASE: Mengonversi semua nama objek menjadi huruf kecil (perilaku default).
PRESERVE_ORIGINAL: Mempertahankan kapitalisasi asli dari skema sumber. Hal ini berguna jika aplikasi Anda menggunakan ID peka huruf besar/kecil.

Contoh:

CASE_HANDLING PRESERVE_ORIGINAL

`GENERATE_MISSING_PK`

Tabel tanpa kunci utama tidak menjanjikan replikasi yang konsisten. Database Migration Service hanya memigrasikan tabel yang memiliki kunci utama. Secara default, ruang kerja konversi Database Migration Service otomatis membuat kunci utama yang tidak ada di tabel tujuan saat Anda mengonversi kode sumber dan skema.

Anda dapat mengontrol pembuatan kunci utama otomatis dengan perintah GENERATE_MISSING_PK. Untuk menonaktifkan pembuatan kunci otomatis, tetapkan perintah ini ke 0.

Contoh:

GENERATE_MISSING_PK 0

Perintah ini memengaruhi semua objek di ruang kerja konversi tertentu. Pembuatan kunci utama otomatis tidak dapat dinonaktifkan hanya untuk tabel tertentu.

Database Migration Service hanya dapat memigrasikan tabel yang memiliki batasan kunci utama dalam versi PostgreSQL yang dikonversi. Jika Anda menonaktifkan pembuatan kunci utama otomatis, Anda harus membuat kunci utama atau batasan unik secara manual dalam tabel yang dikonversi di database tujuan setelah menerapkan skema yang dikonversi. Luaskan bagian berikut untuk melihat contoh perintah SQL.

Membuat kunci utama menggunakan kolom yang ada

Tabel Anda mungkin sudah memiliki kunci utama logis berdasarkan kolom atau kombinasi kolom. Misalnya, mungkin ada kolom dengan batasan atau indeks unik yang dikonfigurasi. Gunakan kolom ini untuk membuat kunci utama baru untuk tabel di database sumber Anda. Contoh:

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

Membuat kunci utama menggunakan semua kolom

Jika Anda tidak memiliki batasan yang sudah ada yang dapat berfungsi sebagai kunci utama, buat kunci utama menggunakan semua kolom tabel. Pastikan Anda tidak melebihi panjang maksimum kunci utama yang diizinkan oleh cluster PostgreSQL Anda. Contoh:

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);

Saat membuat kunci utama gabungan seperti ini, Anda harus mencantumkan semua nama kolom yang ingin digunakan secara eksplisit. Anda tidak dapat menggunakan pernyataan untuk mengambil semua nama kolom untuk tujuan ini.

Membuat batasan unik dengan kolom semu `ROWID`

Database Oracle menggunakan kolom semu ROWID untuk menyimpan lokasi setiap baris dalam tabel. Untuk memigrasikan tabel Oracle yang tidak memiliki kunci utama, Anda dapat menambahkan kolom ROWID di database PostgreSQL tujuan. Database Migration Service mengisi kolom dengan nilai numerik yang sesuai dari kolom semu ROWID Oracle sumber.

Untuk menambahkan kolom dan menetapkannya sebagai kunci utama, jalankan perintah berikut:

ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;
CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;
ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('TABLE_NAME_rowid_seq');
ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);

Mengganti Nama Objek (`RENAME_*`)

Anda dapat mengganti nama berbagai objek database selama konversi. Database Migration Service otomatis mengupdate semua referensi kode (dalam tampilan, prosedur tersimpan, fungsi, dll.) untuk menggunakan nama baru.

Sintaksis umum

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

Pertimbangan penting

Perintah RENAME_* peka huruf besar/kecil untuk nama objek tujuan dan lebih diutamakan daripada perintah CASE_HANDLING. Misalnya, jika Anda menggunakan kedua perintah:

SCHEMA MySchema
CASE_HANDLING PRESERVE_ORIGINAL
# Destination objects are renamed exactly
# to 'SoMe_tAbLe' and 'RenamedView', respecting the case
# despite the CASE_HANDLING directive
RENAME_TABLES some_table:SoMe_tAbLe
RENAME_VIEWS MyView:RenamedView

Untuk SOURCE_NAME, selalu lihat nama objek asli, meskipun Anda menggunakan perintah lain seperti MOVE_*. Misalnya, jika Anda ingin mengganti nama salah satu objek tampilan dan memindahkannya ke skema baru, lihat nama tampilan asli untuk kedua perintah:
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
Perintah RENAME_TABLES menggantikan perintah REPLACE_TABLES dalam satu file. Jika Anda ingin mengganti nama dan memindahkan tabel, sebaiknya gunakan perintah MOVE_*.
Format lengkap variabel SOURCE_NAME bergantung pada apakah Anda juga menggunakan perintah SCHEMA:
- Dengan perintah SCHEMA: Gunakan nama yang tidak memenuhi syarat, misalnya MyTable.
- Tanpa perintah SCHEMA: Gunakan nama yang sepenuhnya memenuhi syarat, misalnya MySchema.MyTable.

Perintah RENAME_* yang didukung

RENAME_SCHEMA: Mengganti nama skema.
Satu file konfigurasi hanya dapat berisi satu perintah RENAME_SCHEMA. Jika perintah SCHEMA diberikan, RENAME_SCHEMA hanya dapat mengganti nama skema tertentu tersebut.
RENAME_TABLES: Mengganti nama tabel. Mengganti REPLACE_TABLES dalam file yang sama.
RENAME_COLUMNS: Mengganti nama kolom dalam tabel. Mengganti perintah REPLACE_COLS dalam file yang sama. Gunakan format berikut:
```
RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL
```
Jika Anda menggunakan perintah SCHEMA, gunakan nama tabel tanpa penentuan. Jika Anda tidak menggunakan perintah SCHEMA, sertakan nama tabel yang sepenuhnya memenuhi syarat, seperti SCHEMA.TABLE1.
RENAME_VIEWS
RENAME_MATERIALIZED_VIEWS
RENAME_SEQUENCES
RENAME_FUNCTIONS
RENAME_STORED_PROCEDURES
RENAME_TRIGGERS
RENAME_PACKAGES: Database Migration Service mengonversi paket Oracle ke skema PostgreSQL. Jika skema Anda berisi paket yang memiliki nama yang sama, kode PostgreSQL mungkin mengalami konflik nama saat mencoba membuat dua skema dengan nama yang sama. Anda dapat menggunakan perintah ini untuk menghindari konflik tersebut.

Misalnya, jika Anda memiliki paket seperti SALES.REPORTING_PKG dan HR.REPORTING_PKG, Anda dapat mengganti namanya menjadi nama yang berbeda:
```
RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS
```
RENAME_USER_DEFINED_TYPES

Alias yang tersedia: RENAME_UDTS.

Objek Bergerak (`MOVE_*`)

Anda dapat memindahkan objek ke skema yang berbeda di database tujuan. Hal ini berguna untuk mengatur ulang struktur database Anda selama migrasi. Database Migration Service otomatis memperbarui semua referensi kode dalam tampilan, prosedur tersimpan, fungsi, dll.

Sintaksis umum

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

Pertimbangan penting

Untuk SOURCE_NAME, selalu lihat nama objek asli, meskipun Anda menggunakan perintah lain seperti RENAME_*. Misalnya, jika Anda ingin mengganti nama salah satu objek tampilan dan memindahkannya ke skema baru, lihat nama tampilan asli untuk kedua perintah:
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
Perintah ini hanya mengharapkan nama DESTINATION_SCHEMA, bukan nama objek lengkap.
Format lengkap variabel SOURCE_NAME bergantung pada apakah Anda juga menggunakan perintah SCHEMA:
- Dengan perintah SCHEMA: Gunakan nama yang tidak memenuhi syarat, misalnya MyTable.
- Tanpa perintah SCHEMA: Gunakan nama yang sepenuhnya memenuhi syarat, misalnya MySchema.MyTable.

Perintah MOVE_* yang didukung

MOVE_TABLES: Memindahkan tabel ke skema yang berbeda. Lebih diprioritaskan daripada REPLACE_TABLES untuk perubahan skema dalam satu file konfigurasi.
MOVE_VIEWS
MOVE_MATERIALIZED_VIEWS
MOVE_SEQUENCES
MOVE_FUNCTIONS
MOVE_STORED_PROCEDURES
MOVE_USER_DEFINED_TYPES

Alias yang tersedia: MOVE_UDTS.

Contoh: Mengatur ulang skema

SCHEMA LegacyApp

# Moves the 'LegacyApp.Users' and 'LegacyApp.Orders' tables
# to the 'data' schema.
MOVE_TABLES Users:data Orders:data

# Moves the 'LegacyApp.CreateUser' and 'LegacyApp.ProcessOrder'
# stored procedures to the 'api' schema
MOVE_STORED_PROCEDURES CreateUser:api ProcessOrder:api

# Moves the 'LegacyApp.SalesSummary' views to the 'reporting' schema
MOVE_VIEWS SalesSummary:reporting

`DATA_TYPE`

Anda dapat menggunakan perintah ini untuk memetakan secara eksplisit jenis data yang didukung antara sintaksis Oracle dan PostgreSQL. Perintah ini memerlukan daftar pemetaan yang dipisahkan dengan koma. Seluruh definisi harus disediakan dalam satu baris, tetapi Anda menyertakan beberapa perintah DATA_TYPE dalam file konfigurasi. Gunakan format berikut:

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

Dengan ORACLE_DATA_TYPE dan PGSQL_DATA_TYPE adalah jenis data yang didukung oleh versi Oracle dan PostgreSQL masing-masing yang Anda gunakan dalam migrasi. Untuk mengetahui informasi tentang versi yang didukung, lihat Ringkasan skenario.

Contoh:

DATA_TYPE REAL:double precision,SMALLINT:integer

Untuk mengetahui informasi selengkapnya tentang jenis data Oracle dan PostgreSQL, lihat:

Jenis data Oracle dalam dokumentasi Oracle.
Jenis data PostgreSQL dalam dokumentasi PostgreSQL.

`MODIFY_TYPE`

Dengan perintah MODIFY_TYPE, Anda dapat mengontrol jenis data yang digunakan Database Migration Service untuk mengonversi kolom tertentu dalam tabel sumber. Perintah ini memerlukan daftar pemetaan yang dipisahkan dengan koma. Seluruh definisi harus diberikan dalam satu baris, tetapi Anda menyertakan beberapa perintah MODIFY_TYPE dalam file konfigurasi. Gunakan format berikut:

MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE
MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...

Dengan:

SOURCE_TABLE_NAME adalah nama tabel yang berisi kolom tempat Anda ingin mengubah jenis data.
Penting: Jika Anda tidak menggunakan perintah SCHEMA, pastikan Anda menggunakan nama tabel yang sepenuhnya memenuhi syarat: SCHEMA_NAME.SOURCE_TABLE_NAME
COLUMN_NAME adalah nama kolom yang ingin Anda sesuaikan pemetaan konversinya.
EXPECTED_END_RESULT_DATA_TYPE adalah jenis data PostgreSQL yang ingin Anda gunakan untuk kolom yang dikonversi.

Contoh:

MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT

`PG_INTEGER_TYPE`

Secara default,Database Migration Service mengonversi jenis NUMBER(p,s) ke jenis DECIMAL(p,s) PostgreSQL.

Anda dapat mengubah perilaku ini dengan perintah PG_INTEGER_TYPE. Tetapkan nilainya ke 1 dan paksa semua NUMBER Anda dengan jenis presisi dan skala (NUMBER(p,s)) untuk dikonversi menjadi jenis smallint, integer, atau bigint PostgreSQL berdasarkan jumlah digit presisi.

Tips: Anda juga dapat menggunakan perintah ini untuk jenis NUMBER biasa jika Anda menggabungkannya dengan perintah DEFAULT_NUMERIC.

Sertakan setelan berikut dalam file pemetaan konversi Anda:

PG_INTEGER_TYPE 1

`PG_NUMERIC_TYPE`

Tetapkan perintah ini ke 1 jika Anda ingin mengonversi semua jenis NUMBER dengan presisi dan skala (NUMBER(p,s)) menjadi jenis real atau float PostgreSQL (berdasarkan jumlah digit presisinya).

Jika Anda menetapkan perintah ini ke 0, nilai NUMBER(p,s) Anda akan mempertahankan nilai aslinya yang tepat dan menggunakan jenis data PostgreSQL internal.

Sertakan setelan berikut dalam file pemetaan konversi Anda:

PG_NUMERIC_TYPE 1

`DEFAULT_NUMERIC`

Konversi default untuk NUMBER tanpa presisi akan berubah, baik Anda juga menggunakan arahan PG_INTEGER_TYPE atau tidak:

Jika Anda menggunakan perintah PG_INTEGER, NUMBER tanpa presisi akan dikonversi menjadi nilai DECIMAL.
Jika Anda tidak menggunakan perintah PG_INTEGER, NUMBER tanpa presisi akan dikonversi menjadi nilai BIGINT.

Anda dapat mengubah perilaku ini dan menggunakan perintah DEFAULT_NUMERIC untuk menentukan jenis data yang harus digunakan untuk jenis NUMBER tanpa titik presisi yang ditentukan. Gunakan format berikut:

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

Dengan POSTGRESQL_NUMERIC_DATA_TYPE adalah salah satu dari berikut ini: integer, smallint, bigint.

Contoh:

DEFAULT_NUMERIC integer

`REPLACE_COLS`

Anda dapat menggunakan perintah REPLACE_COLS untuk mengganti nama kolom dalam skema yang dikonversi. Perintah ini memerlukan daftar pemetaan yang dipisahkan dengan koma.

Gunakan format berikut:

REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...

Dengan:

SOURCE_TABLE_NAME adalah nama tabel yang berisi kolom yang ingin Anda ubah namanya. Jika Anda tidak menggunakan perintah SCHEMA, pastikan Anda menggunakan nama tabel yang sepenuhnya memenuhi syarat: SCHEMA_NAME.SOURCE_TABLE_NAME
SOURCE_COLUMN_NAME adalah nama kolom di sumber yang ingin Anda ubah namanya.
DESTINATION_COLUMN_NAME adalah nama baru untuk kolom yang ingin Anda gunakan dalam skema yang dikonversi.

Contoh:

REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)

`REPLACE_TABLES`

Anda dapat menggunakan perintah REPLACE_TABLES untuk mengganti nama tabel atau memindahkannya ke skema baru. Perintah ini memerlukan daftar pemetaan yang dipisahkan dengan spasi. Untuk mengetahui informasi selengkapnya tentang sintaksis untuk setiap kasus penggunaan, luaskan bagian berikut.

Jika Anda tidak menggunakan perintah SCHEMA, pastikan Anda menggunakan nama tabel yang sepenuhnya memenuhi syarat dalam tanda kutip untuk variabel sumber dan tujuan:

"SCHEMA_NAME.SOURCE_TABLE_NAME"
"SCHEMA_NAME.DESTINATION_TABLE_NAME"

Mengganti nama tabel

Untuk mengganti nama tabel dalam skema yang dikonversi, gunakan format berikut:

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

Dengan:

SOURCE_TABLE_NAME adalah nama tabel sumber yang ingin Anda ganti namanya dalam skema yang dikonversi.
DESTINATION_TABLE_NAME adalah nama baru untuk tabel yang ingin Anda gunakan dalam skema yang dikonversi.

Contoh:

REPLACE_TABLES "events:login_events" "users:platform_users"

Memindahkan tabel antar-skema

Anda dapat menggunakan perintah ini untuk memindahkan tabel antar-skema dengan menambahkan awalan skema ke nama tabel baru. Mekanisme ini dapat digunakan terlepas dari cara Anda menggunakan perintah SCHEMA untuk seluruh file konversi. Contoh:

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

Alias untuk menyesuaikan jenis data

Saat Anda menggunakan perintah konversi untuk mengubah cara Database Migration Service mengonversi berbagai jenis data (misalnya, dengan perintah DATA_TYPE, MODIFY_TYPE, atau PG_NUMERIC_TYPE), Anda dapat menggunakan alias, bukan jenis data SQL sumber.

Luaskan bagian berikut untuk melihat daftar alias jenis data yang didukung oleh Database Migration Service.

Alias jenis data

Alias	Dikonversi ke jenis PostgreSQL
`bigint`, `int8`	`BIGINT`
`bool`, `boolean`	`BOOLEAN`
`bytea`	`BYTEA`
`char`, `character`	`CHAR`
`character varying`, `varchar`	`VARCHAR`
`date`	`DATE`
`decimal`, `numeric`	`DECIMAL`
`double precision`, `float8`	`DOUBLE PRECISION`
`real`, `float4`	`REAL`
`int`, `integer`, `int4`	`INTEGER`
`int2`	`SMALLINT`
`interval`	`INTERVAL`
`json`	`JSON`
`smallint`	`SMALLINT`
`text`	`TEXT`
`time`	`TIME`
`timestamp`	`TIMESTAMP`
`timestamptz`	`TIMESTAMPTZ`
`timetz`	`TIMETZ`
`uuid`	`UUID`
`XML`	`XML`

Contoh file pemetaan konversi

Lihat contoh file pemetaan konversi berikut yang menggunakan beberapa perintah konversi skema yang didukung:

EXPORT_SCHEMA 1
SCHEMA root

# Preserve original casing for all objects
CASE_HANDLING PRESERVE_ORIGINAL

# Data type conversions
PG_NUMERIC_TYPE 0
PG_INTEGER_TYPE 1
DEFAULT_NUMERIC integer
DATA_TYPE NUMBER(4\,0):integer
MODIFY_TYPE events:dates_and_times:TIMESTAMP

# Renaming objects using the RENAME_* directives
# These allow case-sensitive destination names
RENAME_TABLES events:LoginEvents users:PlatformUsers
RENAME_COLUMNS events.dates_and_times:EventDates users.pseudonym:Nickname
RENAME_VIEWS InternalReport:FinInternalReport

# Moving objects to new schemas using the MOVE_* directives
MOVE_TABLES audit_log:archive
MOVE_VIEWS InternalReport:reporting

Hasil penggunaan file ini adalah sebagai berikut:

EXPORT_SCHEMA 1 adalah perintah yang wajib ada.
SCHEMA root menyebabkan perintah lain diterapkan ke objek dalam skema root, kecuali jika nama yang sepenuhnya memenuhi syarat digunakan.
CASE_HANDLING PRESERVE_ORIGINAL memastikan bahwa semua nama objek dari skema root sumber mempertahankan huruf besar/kecil aslinya di tujuan (kecuali jika diganti oleh perintah RENAME_*).
PG_INTEGER_TYPE 1 membuat Database Migration Service mengonversi semua jenis data numerik Oracle yang ditemukan dalam tabel di skema root menjadi jenis khusus PostgreSQL, bukan jenis numerik portabel ANSI.
DEFAULT_NUMERIC integer menyebabkan Database Migration Service mengonversi nilai NUMBER yang tidak memiliki titik presisi yang ditentukan menjadi jenis INTEGER PostgreSQL.
DATA_TYPE NUMBER(4\,0):integer menyebabkan Database Migration Service mengonversi nilai NUMBER(4,0) tertentu ke INTEGER PostgreSQL.
Perintah MODIFY_TYPE events:dates_and_times:TIMESTAMP menyebabkan Database Migration Service mengonversi data di kolom dates_and_times dalam tabel sumber events secara khusus ke jenis TIMESTAMP PostgreSQL.
RENAME_TABLES events:LoginEvents users:PlatformUsers mengganti nama tabel, dengan mempertahankan huruf yang ditentukan:
- Tabel events diganti namanya menjadi LoginEvents.
- Tabel users diganti namanya menjadi PlatformUsers.
RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname mengganti nama kolom, mempertahankan huruf yang ditentukan di tujuan:
- Dalam tabel LoginEvents (nama asli events), kolom dates_and_times diganti namanya menjadi EventDates.
- Di PlatformUsers (nama asli users), kolom pseudonym diganti namanya menjadi Nickname.
RENAME_VIEWS InternalReport:FinInternalReport mengganti nama tampilan InternalReport menjadi FinInternalReport.
MOVE_TABLES audit_log:archive memindahkan tabel audit_log dari skema root ke skema archive.
MOVE_VIEWS InternalReport:reporting memindahkan tampilan InternalReport ke skema reporting. Tampilan ini juga diganti namanya menjadi FinInternalReport karena perintah RENAME_VIEWS. Database Migration Service menangani dependensi: objek diganti namanya terlebih dahulu, lalu dipindahkan.