Ruang kerja konversi

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

Ringkasan konversi memberikan penampang progres konversi skema Anda.
Objek yang didukung oleh konversi skema dan kode 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 tentang petunjuk 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.

Ringkasan progres konversi

Informasi ringkasan yang kuat di ruang kerja konversi, tempat Anda dapat memperoleh insight tentang jumlah total masalah konversi yang belum diselesaikan atau telah diselesaikan, augmentasi yang dibantu Gemini, dan performa 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 menurut jenis, tingkat keparahan masalah, tindakan yang diperlukan, atau status konversi.

Layar ruang kerja konversi yang menunjukkan cara memfilter objek yang dikonversi menurut jenis atau status. — **Gambar 2.** Objek yang dikonversi difilter 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 langsung melakukan konversi skema awal menggunakan serangkaian aturan konversi deterministik yang memetakan jenis dan objek data Oracle tertentu ke jenis dan objek data PostgreSQL tertentu. Proses ini mendukung subkumpulan objek database Oracle yang 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 sebagian)
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 secara 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 secara langsung di dalam Database Migration Service. Untuk mengubah objek tersebut, Anda harus melakukan update langsung di database tujuan setelah Anda 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 untuk membantu Anda mempercepat dan meningkatkan proses konversi di area berikut:

Tingkatkan hasil konversi deterministik dengan konversi otomatis yang didukung Gemini untuk memanfaatkan kecanggihan AI dalam mengurangi secara signifikan jumlah penyesuaian manual yang diperlukan dalam kode PostgreSQL Anda.

Menyediakan fitur penjelasan kode dengan asisten konversi: serangkaian perintah khusus yang dapat membantu Anda lebih memahami logika konversi, menyarankan perbaikan untuk masalah konversi, atau mengoptimalkan kode yang dikonversi.
Mempercepat 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 salah lainnya di ruang kerja.

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

Mengonversi kode dan skema Oracle dengan bantuan Gemini

Contoh alur kerja untuk memperbaiki objek kode yang mengalami masalah konversi

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 petunjuk konversi) tentang cara mengonversi objek Oracle Anda menjadi objek PostgreSQL.

Petunjuk konversi yang didukung

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

`EXPORT_SCHEMA`

EXPORT_SCHEMA adalah direktif 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 arahan konversi Anda. Direktif SCHEMA menyebabkan semua direktif penyesuaian lainnya yang diberikan dalam file Anda berlaku untuk objek dalam skema khusus ini.

Saat Anda menggunakan direktif ini, skema lain yang ada dalam database Anda juga akan dikonversi, tetapi objeknya tidak akan mengalami modifikasi apa pun.
Jika Anda menyertakan direktif ini dalam file pemetaan konversi, semua penyesuaian hanya diterapkan ke objek yang ada dalam skema tertentu ini.
Jika Anda melewati petunjuk ini, Anda harus memberikan nama objek yang sepenuhnya memenuhi syarat yang menyertakan nama skema untuk objek yang diubah oleh petunjuk konversi lainnya. Misalnya, daripada menggunakan SOURCE_TABLE_NAME untuk REPLACE_TABLES, Anda harus menggunakan "SCHEMA_NAME.SOURCE_TABLE_NAME".
Untuk menyesuaikan objek dalam skema yang berbeda, coba langkah-langkah berikut:
- Buat file pemetaan konversi terpisah untuk skema lainnya, lalu 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 direktif SCHEMA.

Gunakan format berikut:

SCHEMA SCHEMA_NAME

Dengan SCHEMA_NAME adalah nama skema Anda dalam database sumber.

`CASE_HANDLING`

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

Perintah ini tidak terpengaruh oleh perintah SCHEMA. Fitur 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 direktif 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 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 yang 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 direktif GENERATE_MISSING_PK. Untuk menonaktifkan pembuatan kunci otomatis, tetapkan direktif ini ke 0.

Contoh:

GENERATE_MISSING_PK 0

Petunjuk ini memengaruhi semua objek di ruang kerja konversi tertentu. Pembuatan kunci utama otomatis hanya dapat dinonaktifkan untuk semua tabel, bukan 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 Anda 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 bagi 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 primer gabungan seperti ini, Anda harus mencantumkan semua nama kolom yang ingin digunakan secara eksplisit. Pernyataan tidak dapat digunakan untuk mengambil semua nama kolom untuk tujuan ini.

Membuat batasan unik dengan pseudokolom `ROWID`

Database Oracle menggunakan pseudokolom 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 diprioritaskan 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 merujuk ke nama objek asli, meskipun Anda menggunakan direktif lain seperti MOVE_*. Misalnya, jika Anda ingin mengganti nama salah satu objek tampilan dan memindahkannya ke skema baru, lihat nama tampilan asli untuk kedua direktif:
```
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 direktif SCHEMA:
- Dengan direktif SCHEMA: Gunakan nama yang tidak memenuhi syarat, misalnya MyTable.
- Tanpa direktif SCHEMA: Gunakan nama yang sepenuhnya memenuhi syarat, misalnya MySchema.MyTable.

Direktif RENAME_* yang didukung

RENAME_SCHEMA: Mengganti nama skema.
Satu file konfigurasi hanya dapat berisi satu direktif RENAME_SCHEMA. Jika perintah SCHEMA diberikan, RENAME_SCHEMA hanya dapat mengganti nama skema tertentu tersebut.
RENAME_TABLES: Mengganti nama tabel. Menggantikan REPLACE_TABLES dalam file yang sama.
RENAME_COLUMNS: Mengganti nama kolom dalam tabel. Menggantikan 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 direktif SCHEMA, gunakan nama tabel tanpa penentuan. Jika Anda tidak menggunakan direktif 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 direktif 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.

Memindahkan Objek (`MOVE_*`)

Anda dapat memindahkan objek ke skema yang berbeda dalam database tujuan. Hal ini berguna untuk mengatur ulang struktur database Anda selama migrasi. Database Migration Service otomatis mengupdate 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 merujuk ke nama objek asli, meskipun Anda menggunakan direktif lain seperti RENAME_*. Misalnya, jika Anda ingin mengganti nama salah satu objek tampilan dan memindahkannya ke skema baru, lihat nama tampilan asli untuk kedua direktif:
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
Direktif hanya mengharapkan nama DESTINATION_SCHEMA, bukan nama objek lengkap.
Format lengkap variabel SOURCE_NAME bergantung pada apakah Anda juga menggunakan direktif SCHEMA:
- Dengan direktif SCHEMA: Gunakan nama yang tidak memenuhi syarat, misalnya MyTable.
- Tanpa direktif SCHEMA: Gunakan nama yang sepenuhnya memenuhi syarat, misalnya MySchema.MyTable.

Direktif MOVE_* yang didukung

MOVE_TABLES: Memindahkan tabel ke skema lain. 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 direktif ini untuk memetakan secara eksplisit jenis data yang didukung antara sintaksis Oracle dan PostgreSQL. Petunjuk ini mengharapkan daftar pemetaan yang dipisahkan dengan koma. Seluruh definisi harus disediakan dalam satu baris, tetapi Anda menyertakan beberapa direktif 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 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 direktif MODIFY_TYPE, Anda dapat mengontrol jenis data yang dikonversi oleh Database Migration Service untuk kolom tertentu dalam tabel sumber. Direktif ini mengharapkan daftar pemetaan yang dipisahkan dengan koma. Seluruh definisi harus diberikan dalam satu baris, tetapi Anda menyertakan beberapa direktif 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 direktif SCHEMA, pastikan Anda menggunakan nama tabel yang sepenuhnya memenuhi syarat: SCHEMA_NAME.SOURCE_TABLE_NAME
COLUMN_NAME adalah nama kolom yang pemetaan konversinya ingin Anda sesuaikan.
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 direktif PG_INTEGER_TYPE. Tetapkan nilainya ke 1 dan paksa semua jenis NUMBER dengan 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 direktif ini ke 1 jika Anda ingin mengonversi semua jenis NUMBER dengan presisi dan skala (NUMBER(p,s)) ke jenis real atau float PostgreSQL (berdasarkan jumlah digit presisinya).

Jika Anda menetapkan direktif ini ke 0, nilai NUMBER(p,s) akan mempertahankan nilai aslinya yang persis sama 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 mengubah apakah Anda juga menggunakan PG_INTEGER_TYPE direktif:

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

Anda dapat mengubah perilaku ini dan menggunakan direktif 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: integer, smallint, bigint.

Contoh:

DEFAULT_NUMERIC integer

`REPLACE_COLS`

Anda dapat menggunakan perintah REPLACE_COLS untuk mengganti nama kolom dalam skema yang dikonversi. Direktif ini mengharapkan 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 namanya ingin Anda ubah. Jika Anda tidak menggunakan direktif 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 direktif REPLACE_TABLES untuk mengganti nama tabel atau memindahkannya ke skema baru. Direktif ini mengharapkan daftar pemetaan yang dipisahkan dengan spasi. Untuk mengetahui informasi selengkapnya tentang sintaksis untuk setiap kasus penggunaan, luaskan bagian berikut.

Jika Anda tidak menggunakan SCHEMA directive, 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 direktif ini untuk memindahkan tabel antar-skema dengan menambahkan awalan skema ke nama tabel baru. Mekanisme ini dapat digunakan terlepas dari cara Anda menggunakan direktif SCHEMA untuk seluruh file konversi. Contoh:

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

Alias untuk menyesuaikan jenis data

Saat menggunakan direktif konversi untuk mengubah cara Database Migration Service mengonversi berbagai jenis data (misalnya, dengan direktif 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 file pemetaan konversi contoh berikut yang menggunakan beberapa direktif 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 direktif 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 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 yang kompatibel dengan 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.
Direktif 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, dengan mempertahankan huruf yang ditentukan di tujuan:
- Di tabel LoginEvents (nama asli events), nama kolom dates_and_times diganti 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 pertama-tama diganti namanya, lalu dipindahkan.