Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah tugas migrasi di AWS Database Migration Service

Setelah itu, Anda dapat menemukan topik tentang pemecahan masalah dengan AWS Database Migration Service ()AWS DMS. Topik-topik ini dapat membantu Anda menyelesaikan masalah umum menggunakan database endpoint AWS DMS dan endpoint yang dipilih.

Jika Anda telah membuka kasus AWS Support, teknisi dukungan Anda mungkin mengidentifikasi potensi masalah dengan salah satu konfigurasi database endpoint Anda. Teknisi Anda mungkin juga meminta Anda untuk menjalankan skrip dukungan untuk mengembalikan informasi diagnostik tentang basis data Anda. Untuk detail tentang mengunduh, menjalankan, dan mengunggah informasi diagnostik dari skrip dukungan jenis ini, lihat Bekerja dengan skrip dukungan diagnostik di AWS DMS.

Untuk tujuan pemecahan masalah, AWS DMS kumpulkan file trace dan dump dalam instance replikasi. Anda dapat memberikan file-file ini ke AWS Support jika terjadi masalah yang memerlukan pemecahan masalah. Secara default, DMS membersihkan file trace dan dump yang lebih tua dari tiga puluh hari. Untuk memilih keluar dari koleksi file trace dan dump, buka case dengan AWS Support.

Tugas migrasi berjalan perlahan

Beberapa masalah dapat menyebabkan tugas migrasi berjalan lambat, atau menyebabkan tugas berikutnya berjalan lebih lambat daripada tugas awal.

Alasan paling umum untuk tugas migrasi berjalan lambat adalah bahwa ada sumber daya yang tidak memadai yang dialokasikan ke instance AWS DMS replikasi. Untuk memastikan bahwa instans Anda memiliki sumber daya yang cukup untuk tugas yang Anda jalankan di dalamnya, periksa penggunaan instance replikasi AndaCPU, memori, swap file, danIOPS. Misalnya, beberapa tugas dengan Amazon Redshift sebagai titik akhir bersifat intensif I/O. Anda dapat meningkatkan IOPS instance replikasi atau membagi tugas Anda di beberapa instance replikasi untuk migrasi yang lebih efisien.

Untuk informasi lebih lanjut tentang penentuan ukuran instans replikasi Anda, lihat Memilih ukuran terbaik untuk contoh replikasi.

Anda dapat meningkatkan kecepatan beban migrasi awal dengan cara melakukan hal berikut:

Bilah status tugas tidak bergerak

Bilah status tugas memberikan estimasi tentang kemajuan tugas. Kualitas estimasi ini tergantung pada kualitas statistik tabel basis data sumber; semakin baik statistik tabel, semakin akurat estimasi.

Untuk tugas dengan hanya satu tabel yang tidak memiliki statistik baris perkiraan, tidak AWS DMS dapat memberikan perkiraan lengkap persentase apa pun. Dalam kasus ini, gunakan status tugas dan indikasi baris yang dimuat untuk mengonfirmasi bahwa tugas berjalan dan membuat kemajuan.

Tugas selesai tapi tidak ada yang dimigrasi

Lakukan hal berikut jika tidak ada yang dimigrasi setelah tugas Anda selesai.

Kunci asing dan indeks sekunder hilang

AWS DMS membuat tabel, kunci utama, dan dalam beberapa kasus indeks unik, tetapi tidak membuat objek lain yang tidak diperlukan untuk memigrasikan data secara efisien dari sumber. Misalnya, DMS tidak membuat indeks sekunder, kendala kunci non-primer, atau default data.

Untuk memigrasi objek sekunder dari basis data Anda, gunakan alat asli basis data jika Anda bermigrasi ke mesin basis data yang sama dengan basis data sumber Anda. Gunakan AWS Schema Conversion Tool (AWS SCT) jika Anda bermigrasi ke mesin basis data yang berbeda dari yang digunakan oleh basis data sumber Anda untuk memigrasi objek sekunder.

AWS DMS tidak membuat CloudWatch log

Jika tugas replikasi Anda tidak membuat CloudWatch log, pastikan akun Anda memiliki dms-cloudwatch-logs-role peran tersebut. Jika peran ini tidak ada, lakukan hal berikut untuk membuatnya:

Masalah terjadi dengan menghubungkan ke Amazon RDS

Ada beberapa alasan mengapa Anda tidak dapat terhubung ke instans Amazon RDS DB yang Anda tetapkan sebagai sumber atau target. Berikut beberapa item untuk diperiksa:

Pesan kesalahan: koneksi string thread salah: nilai thread salah 0

Kesalahan ini dapat sering terjadi ketika Anda menguji koneksi ke titik akhir. Kesalahan ini menunjukkan bahwa ada kesalahan dalam string koneksi. Contohnya adalah spasi setelah alamat IP host. Contoh lain adalah karakter buruk yang disalin ke string koneksi.

Masalah jaringan terjadi

Masalah jaringan yang paling umum melibatkan kelompok VPC keamanan yang digunakan oleh contoh AWS DMS replikasi. Secara default, grup keamanan ini memiliki aturan yang mengizinkan keluar ke 0.0.0.0/0 pada semua port. Dalam banyak kasus, Anda mengubah grup keamanan ini atau menggunakan grup keamanan Anda sendiri. Jika demikian, minimal, pastikan untuk memberikan jalan keluar ke titik akhir sumber dan target pada port basis data masing-masing.

Masalah terkait konfigurasi lainnya dapat mencakup hal berikut:

Untuk informasi tentang menggunakan server nama on premise Anda sendiri, lihat Menggunakan server nama on-premise Anda sendiri.

CDCmacet setelah beban penuh

Perubahan replikasi yang lambat atau tertahan dapat terjadi setelah migrasi beban penuh ketika beberapa pengaturan AWS DMS bertentangan satu sama lain.

Sebagai contoh, anggaplah bahwa parameter Mode persiapan tabel target diatur ke Tidak melakukan apa pun atau Memotong. Dalam hal ini, Anda telah menginstruksikan AWS DMS untuk tidak melakukan pengaturan pada tabel target, termasuk membuat indeks primer dan unik. Jika Anda belum membuat kunci primer atau unik pada tabel target, AWS DMS lakukan pemindaian tabel lengkap untuk setiap pembaruan. Pendekatan ini dapat memengaruhi performa secara signifikan.

Kesalahan pelanggaran kunci primer terjadi saat Anda memulai ulang tugas

Kesalahan ini dapat terjadi ketika data tetap berada dalam basis data target dari tugas migrasi sebelumnya. Jika opsi mode persiapan tabel Target diatur ke Tidak melakukan apa-apa, AWS DMS tidak melakukan persiapan apa pun pada tabel target, termasuk membersihkan data yang dimasukkan dari tugas sebelumnya.

Untuk memulai ulang tugas Anda dan menghindari kesalahan ini, hapus baris yang dimasukkan ke dalam tabel target dari tugas yang dijalankan sebelumnya.

Beban awal skema gagal

Dalam beberapa kasus, beban awal skema Anda mungkin gagal dengan kesalahan Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

Dalam kasus seperti itu, akun pengguna yang digunakan oleh AWS DMS untuk terhubung ke titik akhir sumber tidak memiliki izin yang diperlukan.

Tugas gagal dengan kesalahan yang tidak diketahui

Penyebab jenis kesalahan yang tidak diketahui dapat bervariasi. Namun, seringkali kami menemukan bahwa masalah tersebut melibatkan sumber daya yang tidak memadai yang dialokasikan ke instance AWS DMS replikasi.

Untuk memastikan bahwa instance replikasi Anda memiliki sumber daya yang cukup untuk melakukan migrasi, periksa penggunaan instans AndaCPU, memori, swap file, danIOPS. Untuk informasi lebih lanjut tentang pemantauan, lihat AWS Database Migration Service metrik.

Pemulaian ulang tugas memuat tabel dari awal

AWS DMS memulai ulang pemuatan tabel dari awal ketika belum menyelesaikan pemuatan awal tabel. Saat tugas dimulai ulang, AWS DMS muat ulang tabel dari awal saat pemuatan awal tidak selesai.

Jumlah tabel per tugas menyebabkan masalah

Tidak ada batas yang ditetapkan pada jumlah tabel per tugas replikasi. Namun, kami sarankan untuk membatasi jumlah tabel dalam tugas menjadi kurang dari 60.000, sebagai aturan praktis. Penggunaan sumber daya sering dapat menjadi hambatan ketika satu tugas menggunakan lebih dari 60.000 tabel.

Tugas gagal ketika kunci utama dibuat pada LOB kolom

Dalam LIMITED LOB mode FULL LOB atau, AWS DMS tidak mendukung replikasi kunci utama yang merupakan tipe LOB data.

DMSawalnya memigrasikan baris dengan LOB kolom sebagai null, kemudian memperbarui kolom. LOB Jadi, ketika kunci primer dibuat pada LOB kolom, penyisipan awal gagal karena kunci utama tidak bisa null. Sebagai solusinya, tambahkan kolom lain sebagai kunci utama dan hapus kunci utama dari kolom. LOB

Catatan duplikat terjadi pada tabel target tanpa kunci primer

Menjalankan beban penuh dan CDC tugas dapat membuat catatan duplikat pada tabel target yang tidak memiliki kunci utama atau indeks unik. Untuk menghindari duplikasi catatan pada tabel target selama beban penuh dan CDC tugas, pastikan bahwa tabel target memiliki kunci utama atau indeks unik.

Titik akhir sumber termasuk dalam rentang IP yang dicadangkan

Jika database AWS DMS sumber menggunakan alamat IP dalam kisaran IP yang dicadangkan 192.168.0.0/24, uji koneksi titik akhir sumber gagal. Langkah-langkah berikut memberikan kemungkinan solusi:

Gunakan alamat IP EC2 instans Amazon dan port database yang diberikan sebelumnya untuk titik akhir. AWS DMS Pastikan bahwa endpoint memiliki grup keamanan yang memungkinkan AWS DMS untuk mengakses port database. Perhatikan bahwa proxy harus berjalan selama durasi eksekusi DMS tugas Anda. Tergantung pada kasus penggunaan, Anda mungkin perlu mengotomatiskan pengaturan proxy.

Stempel waktu kacau dalam pertanyaan Amazon Athena

Jika stempel waktu kacau dalam kueri Athena, gunakan AWS Management Console atau ModifyEndpointtindakan untuk menetapkan nilai titik akhir Amazon S3 parquetTimestampInMillisecond Anda. true Untuk informasi selengkapnya, lihat S3Settings.

Pemecahan masalah dengan Oracle

Berikut ini, Anda dapat mempelajari tentang masalah pemecahan masalah khusus untuk menggunakan AWS DMS dengan database Oracle.

Menarik data dari tampilan

Anda dapat menarik data satu kali dari tampilan; Anda tidak dapat menggunakannya untuk replikasi yang sedang berlangsung. Untuk dapat mengekstrak data dari tampilan, Anda harus menambahkan kode berikut ke bagian pengaturan Endpoint dari halaman endpoint sumber Oracle. Ketika Anda mengekstraksi data dari tampilan, tampilan ditampilkan sebagai tabel pada skema target.

"ExposeViews": true

Migrasi LOBs dari Oracle 12c

AWS DMS dapat menggunakan dua metode untuk menangkap perubahan pada database Oracle, Binary Reader dan LogMiner Oracle. Secara default, AWS DMS menggunakan Oracle LogMiner untuk menangkap perubahan. Namun, pada Oracle 12c, Oracle LogMiner tidak mendukung kolom. LOB Untuk menangkap perubahan pada LOB kolom di Oracle 12c, gunakan Binary Reader.

Beralih antara Oracle LogMiner dan Binary Reader

AWS DMS dapat menggunakan dua metode untuk menangkap perubahan ke database Oracle sumber, Binary Reader dan LogMiner Oracle. Oracle LogMiner adalah default. Untuk beralih menggunakan Binary Reader untuk menangkap perubahan, lakukan hal berikut:

Kesalahan: Oracle CDC menghentikan 122301 penghitung coba ulang maksimum oracle terlampauiCDC.

Kesalahan ini terjadi ketika log arsip Oracle yang diperlukan telah dihapus dari server Anda sebelum AWS DMS dapat menggunakannya untuk menangkap perubahan. Tingkatkan kebijakan retensi log Anda di server basis data Anda. Untuk RDS database Amazon, jalankan prosedur berikut untuk meningkatkan retensi log. Misalnya, kode berikut meningkatkan retensi log pada instans Amazon RDS DB menjadi 24 jam.

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
            

Secara otomatis menambahkan supplemental logging untuk titik akhir sumber Oracle

Secara default, AWS DMS logging tambahan dimatikan. Untuk secara otomatis mengaktifkan supplemental logging untuk titik akhir sumber Oracle, lakukan hal berikut:

LOBperubahan tidak ditangkap

Saat ini, tabel harus memiliki kunci utama AWS DMS untuk menangkap LOB perubahan. Jika tabel yang berisi LOBs tidak memiliki kunci utama, ada beberapa tindakan yang dapat Anda lakukan untuk menangkap LOB perubahan:

Kesalahan: ORA -12899: Nilai terlalu besar untuk kolom column-name

Kesalahan "ORA-12899: nilai terlalu besar untuk kolom column-name“Ini sering disebabkan oleh beberapa masalah.

Dalam salah satu masalah ini, ada ketidakcocokan dalam set karakter yang digunakan oleh basis data sumber dan target.

Dalam masalah lain ini, pengaturan dukungan bahasa nasional (NLS) berbeda antara kedua basis data. Penyebab umum dari kesalahan ini adalah ketika database sumber NLS _ LENGTH _ SEMANTICS parameter disetel ke CHAR dan SEMANTICS parameter database target NLS _ LENGTH _ disetel keBYTE.

NUMBERtipe data yang disalahartikan

Tipe NUMBER data Oracle diubah menjadi berbagai tipe AWS DMS data, tergantung pada presisi dan skala. NUMBER Konversi ini didokumentasikan di sini Jenis data sumber untuk Oracle. Cara NUMBER jenis dikonversi juga dapat dipengaruhi dengan menggunakan pengaturan endpoint untuk sumber Oracle endpoint. Pengaturan titik akhir ini didokumentasikan dalamPengaturan titik akhir saat menggunakan Oracle sebagai sumber AWS DMS.

Catatan hilang selama beban penuh

Saat melakukan beban penuh AWS DMS , cari transaksi terbuka di tingkat database dan tunggu transaksi dilakukan. Misalnya, berdasarkan pengaturan tugasTransactionConsistencyTimeout=600, AWS DMS menunggu selama 10 menit bahkan jika transaksi terbuka ada di atas meja yang tidak termasuk dalam pemetaan tabel. Tetapi jika transaksi terbuka ada di tabel yang disertakan dalam pemetaan tabel, dan transaksi tidak dilakukan tepat waktu, catatan yang hilang dalam hasil tabel target.

Anda dapat mengubah pengaturan tugas TransactionConsistencyTimeout dan meningkatkan waktu tunggu jika Anda tahu bahwa transaksi terbuka akan memakan waktu lebih lama untuk dilakukan.

Selain itu, perhatikan bahwa nilai default pengaturan tugas FailOnTransactionConsistencyBreached adalah false. Ini berarti AWS DMS terus menerapkan transaksi lain tetapi transaksi terbuka terlewatkan. Jika Anda ingin tugas menjadi gagal ketika transaksi terbuka tidak ditutup tepat waktu, Anda dapat mengatur FailOnTransactionConsistencyBreached ke true.

Kesalahan Tabel

Table Errormuncul dalam statistik tabel selama replikasi jika WHERE klausa tidak mereferensikan kolom kunci utama, dan logging tambahan tidak digunakan untuk semua kolom.

Untuk memperbaiki masalah ini, aktifkan pencatatan tambahan untuk semua kolom tabel yang direferensikan. Untuk informasi selengkapnya, lihat Mengatur supplemental logging.

Kesalahan: Tidak dapat mengambil id tujuan log Redo yang diarsipkan Oracle

Kesalahan ini terjadi ketika sumber Oracle Anda tidak memiliki log arsip yang dihasilkan atau V$ ARCHIVED _ kosongLOG. Anda dapat mengatasi kesalahan dengan mengganti log secara manual.

Untuk RDS database Amazon, jalankan prosedur berikut untuk mengganti file log. switch_logfileProsedur ini tidak memiliki parameter.

exec rdsadmin.rdsadmin_util.switch_logfile;

Untuk database sumber Oracle yang dikelola sendiri, gunakan perintah berikut untuk memaksa sakelar log.

ALTER SYSTEM SWITCH LOGFILE ;

Mengevaluasi kinerja baca Oracle redo atau arsip log

Jika Anda mengalami masalah kinerja dengan sumber Oracle Anda, Anda dapat mengevaluasi kinerja baca redo Oracle atau log arsip Anda untuk menemukan cara untuk meningkatkan kinerja. Untuk menguji kinerja pembacaan log ulang atau arsip, gunakan image mesin Amazon AWS DMS diagnostik (AMI).

Anda dapat menggunakan AWS DMS diagnostik AMI untuk melakukan hal berikut:

Kemudian Anda dapat mengambil langkah-langkah perbaikan berdasarkan hasil.

Memecahkan masalah dengan My SQL

Setelah itu, Anda dapat mempelajari tentang pemecahan masalah khusus untuk digunakan AWS DMS dengan database SayaSQL.

CDCtugas gagal untuk titik akhir instans Amazon RDS DB karena logging biner dinonaktifkan

Masalah ini terjadi dengan instans Amazon RDS DB karena pencadangan otomatis dinonaktifkan. Aktifkan pencadangan otomatis dengan mengatur periode retensi cadangan ke nilai selain nol.

Koneksi ke target SQL Instans saya terputus selama tugas

Jika Anda memiliki tugas LOBs yang terputus dari SQL target Saya, Anda mungkin melihat jenis kesalahan berikut di log tugas.

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.

 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

Dalam hal ini, Anda mungkin perlu menyesuaikan beberapa pengaturan tugas Anda.

Untuk mengatasi masalah saat tugas terputus dari SQL target Saya, lakukan hal berikut:

Untuk informasi tentang pengaturan variabel SQL sistem saya, lihat Variabel Sistem Server dalam SQLdokumentasi Saya.

Menambahkan komit otomatis ke titik akhir yang kompatibel dengan Saya SQL

Nonaktifkan kunci asing pada target Titik akhir yang SQL kompatibel dengan saya

Anda dapat menonaktifkan pemeriksaan kunci asing di My SQL dengan menambahkan berikut ini ke Atribut Koneksi Ekstra di bagian Advanced target MySQL, Amazon Aurora My SQL -Compatible Edition, atau MariaDB endpoint.

Karakter diganti dengan tanda tanya

Situasi paling umum yang menyebabkan masalah ini adalah ketika karakter titik akhir sumber telah dikodekan oleh kumpulan karakter yang AWS DMS tidak mendukung.

Entri log "Peristiwa buruk"

Entri “Peristiwa buruk” di log migrasi biasanya menunjukkan bahwa operasi bahasa definisi data (DDL) yang tidak didukung telah dicoba pada titik akhir basis data sumber. DDLOperasi yang tidak didukung menyebabkan peristiwa yang tidak dapat dilewati oleh instance replikasi, sehingga peristiwa buruk dicatat.

Untuk mengatasi masalah ini, mulai ulang tugas dari awal. Melakukan hal ini memuat ulang tabel dan mulai menangkap perubahan pada suatu titik setelah DDL operasi yang tidak didukung dikeluarkan.

Ubah pengambilan data dengan My SQL 5.5

AWS DMS ubah pengambilan data (CDC) untuk Amazon Database SQL yang kompatibel dengan RDS saya memerlukan pencatatan biner berbasis baris gambar penuh, yang tidak didukung di SQL versi Saya 5.5 atau lebih rendah. Untuk menggunakannya AWS DMS CDC, Anda harus meningkatkan instans Amazon RDS DB Anda ke SQL versi Saya 5.6.

Meningkatkan retensi log biner untuk instans Amazon RDS DB

AWS DMS membutuhkan retensi file log biner untuk pengambilan data perubahan. Untuk meningkatkan retensi log pada instans Amazon RDS DB, gunakan prosedur berikut. Contoh berikut meningkatkan retensi log biner hingga 24 jam.

call mysql.rds_set_configuration('binlog retention hours', 24);
            

Pesan log: Beberapa perubahan dari basis data sumber tidak memiliki dampak ketika diterapkan ke basis data target.

Saat AWS DMS memperbarui nilai kolom SQL database Saya ke nilai yang ada, pesan zero rows affected dikembalikan dari MySQL. Perilaku ini tidak seperti mesin database lain seperti Oracle dan SQL Server. Mesin ini memperbarui satu baris, bahkan ketika nilai yang menggantikan sama dengan yang sekarang.

Kesalahan: Pengidentifikasi terlalu panjang

Kesalahan berikut terjadi saat pengidentifikasi terlalu panjang:

TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)
            

Dalam beberapa kasus, Anda mengatur AWS DMS untuk membuat tabel dan kunci utama dalam database target. Dalam kasus ini, DMS saat ini tidak menggunakan nama yang sama untuk kunci utama yang digunakan dalam database sumber. Sebagai gantinya, DMS membuat nama kunci primer berdasarkan nama tabel. Ketika nama tabel panjang, pengidentifikasi yang dibuat secara otomatis dapat lebih panjang dari batas yang diizinkan untuk My. SQL

Untuk mengatasi masalah ini, pendekatan saat ini adalah pertama-tama membuat tabel dan kunci primer dalam basis data target terlebih dahulu. Kemudian gunakan tugas dengan pengaturan tugas Mode persiapan tabel target diatur ke Tidak melakukan apa pun atau Memotong untuk mengisi tabel target.

Kesalahan: Set karakter yang tidak didukung menyebabkan konversi data bidang gagal

Kesalahan berikut terjadi ketika set karakter yang tidak didukung menyebabkan konversi data bidang gagal:

"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)
            

Periksa parameter database Anda yang terkait dengan koneksi. Perintah berikut dapat digunakan untuk mengatur parameter ini.

SHOW VARIABLES LIKE '%char%';
            

Kesalahan: Halaman kode 1252 ke UTF8 [120112] konversi data bidang gagal

Kesalahan berikut dapat terjadi selama migrasi jika Anda memiliki karakter non codepage-1252 di sumber Database saya. SQL

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)
                

Sebagai solusinya, Anda dapat menggunakan atribut koneksi CharsetMapping tambahan dengan sumber SQL Titik akhir saya untuk menentukan pemetaan set karakter. Anda mungkin perlu memulai ulang tugas AWS DMS migrasi dari awal jika Anda menambahkan pengaturan titik akhir ini.

Misalnya, pengaturan titik akhir berikut dapat digunakan untuk titik akhir SQL Sumber saya di mana kumpulan karakter sumber adalah Utf8 ataulatin1. 65001 adalah pengenal halaman kode. UTF8

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001
                

Indeks, Kunci Asing, atau Pembaruan atau Penghapusan Cascade Tidak Dimigrasi

AWS DMS tidak mendukung migrasi objek sekunder seperti indeks dan kunci asing. Untuk mereplikasi perubahan yang dibuat pada tabel turunan dari operasi pembaruan atau penghapusan kaskade, Anda harus mengaktifkan batasan kunci asing pemicu pada tabel target. Untuk mengatasi batasan ini, buat kunci asing secara manual pada tabel target. Kemudian, buat satu tugas untuk beban penuh danCDC, atau dua tugas terpisah untuk beban penuh danCDC, seperti yang dijelaskan berikut:

Buat satu tugas yang mendukung beban penuh dan CDC

Prosedur ini menjelaskan cara memigrasikan kunci dan indeks asing menggunakan satu tugas untuk beban penuh dan. CDC

Buat beban penuh dan CDC tugas secara terpisah

Prosedur ini menjelaskan cara memigrasikan kunci dan indeks asing menggunakan tugas terpisah untuk beban penuh dan. CDC

Memecahkan masalah dengan Postgre SQL

Setelah itu, Anda dapat mempelajari tentang masalah pemecahan masalah khusus untuk digunakan AWS DMS dengan database SQL Postgre.

JSONtipe data yang terpotong

AWS DMS memperlakukan tipe JSON data di Postgre SQL sebagai kolom tipe LOB data. Ini berarti bahwa batasan LOB ukuran saat Anda menggunakan LOB mode terbatas berlaku untuk JSON data.

Misalnya, misalkan LOB mode terbatas diatur ke 4.096 KB. Dalam hal ini, setiap JSON data yang lebih besar dari 4.096 KB terpotong pada batas 4.096 KB dan gagal dalam uji validasi di Postgre. SQL

Informasi log berikut menunjukkan JSON bahwa terpotong karena pengaturan LOB mode terbatas dan validasi gagal.

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

Kolom dari tipe data yang ditetapkan pengguna tidak dimigrasi dengan benar

Saat mereplikasi dari SQL sumber Postgre, AWS DMS buat tabel target dengan tipe data yang sama untuk semua kolom, selain kolom dengan tipe data yang ditentukan pengguna. Dalam kasus tersebut, jenis data dibuat sebagai "karakter bervariasi" dalam target.

Kesalahan: Tidak ada skema yang dipilih untuk dibuat di dalamnya

Dalam beberapa kasus, Anda mungkin melihat kesalahan "SQL_ ERROR SqlState: 3F000 NativeError: 7 Pesan:ERROR: tidak ada skema yang dipilih untuk dibuat”.

Kesalahan ini dapat terjadi ketika pemetaan JSON tabel Anda berisi nilai wildcard untuk skema tetapi database sumber tidak mendukung nilai tersebut.

Menghapus dan memperbarui tabel tidak direplikasi menggunakan CDC

Hapus dan perbarui operasi selama change data capture (CDC) diabaikan jika tabel sumber tidak memiliki kunci utama. AWS DMS mendukung perubahan data capture (CDC) untuk SQL tabel Postgre dengan kunci utama.

Jika tabel tidak memiliki kunci utama, log write-ahead (WAL) tidak menyertakan gambar sebelumnya dari baris database. Dalam hal ini, tidak AWS DMS dapat memperbarui tabel. Untuk operasi penghapusan yang akan direplikasi, buat kunci primer pada tabel sumber.

Pernyataan memotong tidak disebarkan

Saat menggunakan change data capture (CDC), TRUNCATE operasi tidak didukung oleh AWS DMS.

Mencegah Postgre menangkap SQL DDL

Anda dapat mencegah titik akhir SQL target Postgre menangkap DDL pernyataan dengan menambahkan pernyataan pengaturan Endpoint berikut.

"CaptureDDLs": "N"
            

Memilih skema tempat objek database untuk menangkap dibuat DDL

Anda dapat mengontrol skema apa objek database yang terkait dengan penangkapan DDL dibuat. Tambahkan pernyataan pengaturan Endpoint berikut. Parameter pengaturan Endpoint tersedia di tab titik akhir sumber.

"DdlArtifactsSchema: "xyzddlschema"                
            

Tabel Oracle hilang setelah bermigrasi ke Postgre SQL

Dalam kasus ini, tabel dan data Anda pada umumnya masih dapat diakses.

Oracle default ke nama tabel huruf besar, dan SQL Postgre default ke nama tabel huruf kecil. Saat Anda melakukan migrasi dari Oracle ke PostgreSQL, kami sarankan Anda menyediakan aturan transformasi tertentu di bawah bagian pemetaan tabel tugas Anda. Ini adalah aturan transformasi untuk mengonversi kasus nama tabel Anda.

Jika Anda memigrasi tabel Anda tanpa menggunakan aturan transformasi untuk mengonversi kasus nama tabel Anda, lampirkan nama tabel Anda dalam tanda petik ketika mereferensikan nama tersebut.

ReplicationSlotDiskUsage meningkat dan restart_lsn berhenti bergerak maju selama transaksi panjang, seperti beban kerja ETL

Ketika replikasi logis diaktifkan, jumlah maksimum perubahan yang disimpan dalam memori per transaksi adalah 4MB. Setelah itu, perubahan ditumpahkan ke disk. Sebagai hasilnya ReplicationSlotDiskUsage meningkat, dan restart_lsn tidak berlanjut sampai transaksi selesai/dibatalkan dan rollback selesai. Karena itu adalah transaksi yang panjang, dapat memakan waktu yang lama untuk rollback.

Jadi, hindari transaksi yang berjalan lama ketika replikasi logis diaktifkan. Sebaliknya, cobalah untuk membagi transaksi menjadi beberapa transaksi yang lebih kecil.

Tugas yang menggunakan tampilan sebagai sumber tidak memiliki baris yang disalin

Untuk memigrasi tampilan, atur table-type ke all atau view. Untuk informasi selengkapnya, lihat Menentukan pemilihan tabel dan transformasi aturan dari konsol.

Sumber yang mendukung tampilan mencakup hal berikut.

Memecahkan masalah dengan Microsoft Server SQL

Setelah itu, Anda dapat mempelajari tentang masalah pemecahan masalah khusus untuk digunakan dengan database AWS DMS Microsoft SQL Server.

Replikasi yang sedang berlangsung gagal setelah RDS for SQL Server gagal ke sekunder

Jika instance SQL Server sumber gagal ke sekunder, replikasi AWS DMS yang sedang berlangsung terus mencoba terhubung, dan terus mereplikasi setelah sumber kembali online. Namun, RDS untuk MAZ contoh SQL Server, dalam keadaan tertentu pemilik database sekunder dapat diatur keNT AUTHORITY\SYSTEM. Setelah failover, ini menyebabkan DMS tugas gagal dengan kesalahan berikut:

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

Untuk memperbaikinya, ikuti langkah-langkah dalam Mengubah db_owner ke akun rdsa untuk database Anda, lalu lanjutkan tugas Anda. DMS

Kesalahan saat menangkap perubahan untuk basis data SQL server

Kesalahan selama change data capture (CDC) sering dapat menunjukkan bahwa salah satu prasyarat tidak terpenuhi. Sebagai contoh, prasyarat yang paling sering diabaikan adalah backup basis data yang lengkap. Log tugas menunjukkan kelalaian ini dengan kesalahan berikut:

SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)                
            

Tinjau prasyarat yang tercantum untuk menggunakan SQL Server sebagai sumber di. Menggunakan database Microsoft SQL Server sebagai sumber AWS DMS

Kolom identitas hilang

AWS DMS tidak mendukung kolom identitas saat Anda membuat skema target. Anda harus menambahkannya setelah beban awal selesai.

Kesalahan: SQL Server tidak mendukung publikasi

Kesalahan berikut dihasilkan saat Anda menggunakan SQL Server Express sebagai titik akhir sumber:

RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.                
            

AWS DMS saat ini tidak mendukung SQL Server Express sebagai sumber atau target.

Perubahan tidak muncul di target Anda

AWS DMS mengharuskan database SQL Server sumber berada dalam model pemulihan data 'BULKLOGGED' atau '' untuk menangkap perubahan secara konsisten. FULL Model SIMPLE '' tidak didukung.

Model SIMPLE pemulihan mencatat informasi minimal yang diperlukan untuk memungkinkan pengguna memulihkan database mereka. Semua entri log yang tidak aktif secara otomatis terpotong ketika titik pemeriksaan terjadi.

Semua operasi masih dicatat. Namun, segera setelah titik pemeriksaan terjadi log secara otomatis terpotong. Pemotongan ini berarti bahwa log menjadi tersedia untuk digunakan kembali dan entri log yang lebih tua dapat ditimpa. Ketika entri log ditimpa, perubahan tidak dapat ditangkap. Masalah inilah mengapa AWS DMS tidak mendukung model pemulihan SIMPLE data. Untuk informasi tentang prasyarat lain yang diperlukan untuk menggunakan SQL Server sebagai sumber, lihat. Menggunakan database Microsoft SQL Server sebagai sumber AWS DMS

Tabel yang tidak seragam dipetakan di seluruh partisi

Selama change data capture (CDC), migrasi tabel dengan struktur khusus ditangguhkan ketika tidak AWS DMS dapat dilakukan dengan benar CDC di atas tabel. Pesan seperti ini dikeluarkan:

[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)
            

Saat berjalan CDC di tabel SQL Server, AWS DMS mem-parsing tlog SQL Server. Pada setiap catatan tlog, AWS DMS mengurai nilai heksadesimal yang berisi data untuk kolom yang disisipkan, diperbarui, atau dihapus selama perubahan.

Untuk mengurai catatan heksadesimal, AWS DMS baca metadata tabel dari tabel sistem Server. SQL Tabel sistem tersebut mengidentifikasi kolom tabel terstruktur khusus tersebut dan mengungkapkan beberapa properti internal mereka, seperti "xoffset" dan "null bit position".

AWS DMS mengharapkan bahwa metadata menjadi sama untuk semua partisi mentah tabel. Namun dalam beberapa kasus, tabel terstruktur khusus tidak memiliki metadata yang sama pada semua partisi mereka. Dalam kasus ini, AWS DMS dapat menangguhkan CDC pada tabel itu untuk menghindari perubahan parsing yang salah dan memberikan target dengan data yang salah. Solusi mencakup hal berikut:

Pemecahan masalah dengan Amazon Redshift

Setelah itu, Anda dapat mempelajari tentang pemecahan masalah khusus untuk digunakan AWS DMS dengan database Amazon Redshift.

Memuat ke sebuah klaster Amazon Redshift di Wilayah AWS yang berbeda

Anda tidak dapat memuat ke dalam klaster Amazon Redshift di AWS Wilayah yang berbeda dari instance AWS DMS replikasi Anda. DMSmengharuskan instans replikasi dan cluster Amazon Redshift Anda berada di Wilayah yang sama.

Kesalahan: Relasi "awsdms_apply_exceptions" sudah ada

Kesalahan “Relasi 'awsdms_apply_exceptions' sudah ada” sering terjadi ketika titik akhir Redshift ditentukan sebagai titik akhir Postgre. SQL Untuk mengatasi masalah ini, modifikasi titik akhir dan ubah Mesin target ke "redshift."

Kesalahan dengan tabel yang namanya dimulai dengan "awsdms_changes"

Pesan kesalahan tabel dengan nama yang dimulai dengan "awsdms_changes" dapat terjadi ketika dua tugas mencoba untuk memuat data ke dalam klaster Amazon Redshift yang sama yang berjalan secara bersamaan. Karena cara tabel sementara diberi nama, tugas yang dilakukan bersamaan dapat bertentangan ketika memperbarui tabel yang sama.

Melihat tabel dalam cluster dengan nama seperti dms.awsdms_changes000000000 XXXX

AWS DMS membuat tabel sementara saat data dimuat dari file yang disimpan di Amazon S3. Nama tabel sementara ini masing-masing memiliki prefiks dms.awsdms_changes. Tabel ini diperlukan sehingga AWS DMS dapat menyimpan data ketika pertama kali dimuat dan sebelum ditempatkan di tabel target akhir.

Izin yang diperlukan untuk bekerja dengan Amazon Redshift

Untuk digunakan AWS DMS dengan Amazon Redshift, akun pengguna yang Anda gunakan untuk mengakses Amazon Redshift harus memiliki izin berikut:

Untuk melihat prasyarat yang diperlukan untuk menggunakan Amazon Redshift sebagai target, lihat Menggunakan basis data Amazon Redshift sebagai target untuk AWS Database Migration Service.

Memecahkan masalah dengan Amazon Aurora My SQL

Setelah itu, Anda dapat mempelajari tentang pemecahan masalah khusus untuk digunakan AWS DMS dengan basis data Amazon SQL Aurora My.

Kesalahan: CHARACTER SET UTF8 bidang diakhiri oleh ',' tertutup oleh '"' baris diakhiri oleh '\n'

Jika Anda menggunakan Amazon Aurora My SQL sebagai target, Anda mungkin melihat kesalahan seperti berikut di log. Jenis kesalahan ini biasanya menunjukkan bahwa Anda memiliki ANSI _ QUOTES sebagai bagian dari MODE parameter SQL _. Memiliki ANSI _ QUOTES sebagai bagian dari MODE parameter SQL _ menyebabkan tanda kutip ganda ditangani seperti tanda kutip dan dapat membuat masalah saat Anda menjalankan tugas.

Untuk memperbaiki kesalahan ini, hapus ANSI _ QUOTES dari MODE parameter SQL _.

2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561) 
            

Memecahkan masalah dengan SAP ASE

Setelah itu, Anda dapat mempelajari tentang pemecahan masalah khusus untuk digunakan AWS DMS dengan SAP ASE database.

Kesalahan: LOB kolom memiliki NULL nilai ketika sumber memiliki indeks unik komposit dengan NULL nilai

Saat menggunakan SAP ASE sebagai sumber dengan tabel yang dikonfigurasi dengan indeks unik komposit yang memungkinkan NULL nilai, LOB nilai mungkin tidak bermigrasi selama replikasi yang sedang berlangsung. Perilaku ini biasanya merupakan hasil dari ANSI _ NULL disetel ke 1 secara default pada klien instance DMS replikasi.

Untuk memastikan bahwa LOB bidang bermigrasi dengan benar, sertakan pengaturan Endpoint 'AnsiNull=0' ke titik akhir AWS DMS sumber untuk tugas tersebut.

Memecahkan masalah dengan Db2 IBM

Berikut ini, Anda dapat mempelajari tentang pemecahan masalah khusus untuk menggunakan AWS DMS dengan database IBM Db2.

Kesalahan: Lanjutkan dari stempel waktu tidak didukung Tugas

Untuk replikasi berkelanjutan (CDC), jika Anda berencana untuk memulai replikasi dari stempel waktu tertentu, setel atribut koneksi StartFromContext ke stempel waktu yang diperlukan. Untuk informasi selengkapnya, lihat Pengaturan titik akhir saat menggunakan LUW Db2. Pengaturan StartFromContext ke stempel waktu yang diperlukan mencegah masalah berikut:

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.