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.

Topik

• Tugas migrasi berjalan perlahan

• Bilah status tugas tidak bergerak

• Tugas selesai tapi tidak ada yang dimigrasi

• Kunci asing dan indeks sekunder hilang

• AWS DMS tidak membuat CloudWatch log

• Masalah terjadi saat terhubung ke Amazon RDS

• Masalah jaringan terjadi

• CDC tertahan setelah beban penuh

• Kesalahan pelanggaran kunci primer terjadi saat Anda memulai ulang tugas

• Beban awal skema gagal

• Tugas gagal dengan kesalahan yang tidak diketahui

• Pemulaian ulang tugas memuat tabel dari awal

• Jumlah tabel per tugas menyebabkan masalah

• Tugas gagal ketika kunci primer dibuat pada kolom LOB

• Catatan duplikat terjadi pada tabel target tanpa kunci primer

• Titik akhir sumber termasuk dalam rentang IP yang dicadangkan

• Stempel waktu kacau dalam pertanyaan Amazon Athena

• Pemecahan masalah dengan Oracle

• Pemecahan masalah dengan MySQL

• Pemecahan masalah dengan PostgreSQL

• Pemecahan masalah Microsoft SQL Server

• Pemecahan masalah dengan Amazon Redshift

• Pemecahan masalah dengan Amazon Aurora MySQL

• Memecahkan masalah dengan SAP ASE

• Memecahkan masalah dengan IBM Db2

• Memecahkan masalah latensi di AWS Database Migration Service

• Bekerja dengan skrip dukungan diagnostik di AWS DMS

• Bekerja dengan dukungan AWS DMS diagnostik AMI

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, periksa penggunaan CPU, memori, swap file, dan IOPS instans replikasi Anda. Misalnya, beberapa tugas dengan Amazon Redshift sebagai titik akhir bersifat intensif I/O. Anda dapat meningkatkan IOPS untuk instans replikasi Anda atau membagi tugas Anda di beberapa instans 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:

• Jika target Anda adalah instans DB Amazon RDS, pastikan bahwa Multi-AZ tidak diaktifkan untuk instans DB target.

• Matikan pencadangan otomatis atau pencatatan di basis data target selama pemuatan, dan aktifkan kembali fitur tersebut setelah migrasi selesai.

• Jika fitur tersedia pada target Anda, gunakan provisioned IOPS.

• Jika data migrasi Anda berisi LOBs, pastikan tugas dioptimalkan untuk migrasi LOB. Untuk informasi lebih lanjut tentang mengoptimalkan LOBs, lihatMenargetkan pengaturan tugas metadata.

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.

• Periksa apakah pengguna yang membuat titik akhir telah membaca akses ke tabel yang ingin Anda migrasi.

• Periksa apakah objek yang ingin Anda migrasi adalah tabel. Jika objek tersebut adalah tampilan, perbarui pemetaan tabel dan tentukan pencari objek sebagai “tampilan” atau “semua”. Untuk informasi selengkapnya, lihat Menentukan pemilihan tabel dan transformasi aturan dari konsol.

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:

1. Masuk ke AWS Management Console dan buka konsol IAM di https://console.aws.amazon.com/iam/.

2. Pilih tab Peran. Pilih Buat peran.

3. Di bagian Pilih jenis entitas tepercaya, pilih Layanan AWS.

4. Di bagian Pilih kasus penggunaan, pilih DMS.

5. Pilih Berikutnya: Izin.

6. Masukkan AmazonDMSCloudWatchLogsRole di bidang pencarian, dan centang kotak di sebelah Amazon DMSCloud WatchLogsRole. Ini memberikan AWS DMS izin untuk mengakses. CloudWatch

7. Pilih Selanjutnya: Tag.

8. Pilih Berikutnya: Tinjau.

9. Masukkan dms-cloudwatch-logs-role nama Peran. Nama ini peka huruf besar/kecil.

10. Pilih Buat peran.

Masalah terjadi saat terhubung ke Amazon RDS

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

• Periksa apakah kombinasi nama pengguna dan kata sandi sudah benar.

• Periksa apakah nilai titik akhir yang ditampilkan di konsol Amazon RDS untuk instans tersebut sama dengan pengidentifikasi titik akhir yang Anda gunakan untuk membuat titik akhir AWS DMS .

• Periksa apakah nilai port yang ditampilkan di konsol Amazon RDS untuk instans tersebut sama dengan port yang ditetapkan untuk titik akhir AWS DMS .

• Periksa apakah grup keamanan yang ditetapkan ke instans DB Amazon RDS mengizinkan koneksi dari instans replikasi AWS DMS .

• Jika instans AWS DMS replikasi dan instans Amazon RDS DB tidak berada di cloud pribadi virtual (VPC) yang sama, periksa apakah instans DB dapat diakses publik.

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 grup keamanan VPC yang digunakan oleh instans replikasi AWS DMS . 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:

• Instans replikasi serta titik akhir sumber dan target di VPC yang sama – Grup keamanan yang digunakan oleh titik akhir harus mengizinkan ingress pada port basis data dari instans replikasi. Pastikan bahwa grup keamanan yang digunakan oleh instans replikasi memiliki ingress ke titik akhir. Atau Anda dapat membuat aturan dalam grup keamanan yang digunakan oleh titik akhir yang mengizinkan alamat IP privat dari akses instans replikasi.

• Titik akhir sumber berada di luar VPC yang digunakan oleh instans replikasi (menggunakan gateway internet) – Grup keamanan VPC harus menyertakan aturan perutean yang mengirim lalu lintas yang bukan ditujukan untuk VPC ke gateway internet. Dalam konfigurasi ini, koneksi ke titik akhir tampaknya datang dari alamat IP publik pada instans replikasi.

• Titik akhir sumber berada di luar VPC yang digunakan oleh instans replikasi (menggunakan gateway NAT) – Anda dapat mengonfigurasi gateway penerjemahan alamat jaringan (NAT) menggunakan alamat IP elastis tunggal yang terikat pada antarmuka jaringan elastis tunggal. Gateway NAT ini menerima pengidentifikasi NAT (nat-#####).

  Dalam beberapa kasus, VPC mencakup rute default untuk gateway NAT alih-alih gateway internet. Dalam kasus seperti itu, instans replikasi muncul untuk menghubungi titik akhir basis data menggunakan alamat IP publik gateway NAT. Di sini, ingress ke titik akhir basis data di luar VPC perlu mengizinkan ingress dari alamat NAT alih-alih alamat IP publik instans replikasi.

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

CDC tertahan 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 masalahnya melibatkan sumber daya yang tidak memadai yang dialokasikan ke instance AWS DMS replikasi.

Untuk memastikan bahwa instans replikasi Anda memiliki cukup sumber daya untuk melakukan migrasi, periksa penggunakan CPU, memori, swap file, dan IOPS instans Anda. 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 primer dibuat pada kolom LOB

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

DMS awalnya memigrasi baris dengan kolom LOB sebagai nol, kemudian memperbarui kolom LOB. Jadi, ketika kunci primer dibuat pada kolom LOB, penyisipan awal gagal karena kunci primer tidak boleh nol. Sebagai solusi, tambahkan kolom lain sebagai kunci primer dan hapus kunci primer dari kolom LOB.

Catatan duplikat terjadi pada tabel target tanpa kunci primer

Menjalankan tugas beban penuh dan CDC dapat membuat catatan duplikat pada tabel target yang tidak memiliki kunci primer atau indeks unik. Untuk menghindari duplikasi catatan pada tabel target selama tugas beban penuh dan CDC, pastikan bahwa tabel target memiliki kunci primer 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:

1. Temukan satu EC2 instance Amazon yang tidak berada dalam rentang cadangan yang dapat berkomunikasi ke database sumber di 192.168.0.0/24.

2. Instal proksi socat dan jalankan. Bagian berikut menunjukkan satu contoh.

   yum install socat
                   
   socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
   &

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 tugas DMS 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 kolom LOB pada 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:

Untuk menggunakan binary reader untuk menangkap perubahan

1. Masuk ke AWS Management Console dan buka AWS DMS konsol di https://console.aws.amazon.com/dms/v2/.

2. Pilih Titik akhir.

3. Pilih titik akhir sumber Oracle di mana Anda ingin menggunakan Binary Reader.

4. Pilih Modifikasi.

5. Pilih Lanjutan, dan kemudian tambahkan kode berikut untuk Atribut koneksi tambahan.

   
   useLogminerReader=N
                   

6. Gunakan alat pengembang Oracle seperti SQL-Plus untuk memberikan hak istimewa tambahan berikut ke akun AWS DMS pengguna yang digunakan untuk terhubung ke titik akhir Oracle.

   
   SELECT ON V_$TRANSPORTABLE_PLATFORM
                   

Kesalahan: Oracle CDC berhenti 122301 penghitung coba kembali oracle CDC terlampaui.

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 basis data Amazon RDS, jalankan prosedur berikut untuk meningkatkan retensi log. Sebagai contoh, kode berikut meningkatkan retensi log pada instans DB Amazon RDS hingga 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:

Untuk menambahkan supplemental logging untuk titik akhir sumber Oracle

1. Masuk ke AWS Management Console dan buka AWS DMS konsol di https://console.aws.amazon.com/dms/v2/.

2. Pilih Titik akhir.

3. Pilih titik akhir sumber Oracle yang ingin Anda tambahkan supplemental logging.

4. Pilih Modifikasi.

5. Pilih Lanjutan, dan kemudian tambahkan kode berikut ke kotak teks Atribut koneksi tambahan:

   
   addSupplementalLogging=Y
                   

6. Pilih Modifikasi.

Perubahan LOB tidak sedang ditangkap

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

• Tambahkan kunci primer ke tabel. Hal ini bisa sesederhana menambahkan kolom ID dan mengisinya dengan urutan menggunakan pemicu.

• Buat tampilan terwujud dari tabel yang mencakup ID yang dihasilkan sistem sebagai kunci primer dan migrasi tampilan terwujud alih-alih tabel.

• Buat siaga logis, tambahkan kunci primer ke tabel, dan bermigrasi dari siaga logis.

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

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

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

Di masalah yang lain, pengaturan national language support (NLS) berbeda antara dua basis data. Penyebab umum dari kesalahan ini adalah ketika parameter NLS_LENGT_SEMANTICS basis data sumber diatur ke CHAR dan parameter NLS_LENGT_SEMANTICS basis data target diatur ke BYTE.

Tipe data ANGKA yang disalahartikan

Tipe data Oracle NUMBER diubah menjadi berbagai tipe AWS DMS data, tergantung pada presisi dan skala NUMBER. Konversi ini didokumentasikan di sini Jenis data sumber untuk Oracle. Cara jenis NUMBER 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_LOG kosong. Anda dapat mengatasi kesalahan dengan mengganti log secara manual.

Untuk database Amazon RDS, jalankan prosedur berikut untuk mengganti file log. switch_logfileProsedur 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 AMI AWS DMS diagnostik untuk melakukan hal berikut:

• Gunakan metode BFile untuk mengevaluasi kinerja file redo log.

• Gunakan LogMiner metode ini untuk mengevaluasi kinerja file redo log.

• Gunakan metode PL/SQL (dbms_lob.read) untuk mengevaluasi kinerja file redo log.

• Gunakan Single-thread untuk mengevaluasi kinerja baca pada ASMFile.

• Gunakan Multi-utas untuk mengevaluasi kinerja baca pada ASMFile.

• Gunakan Direct OS Readfile () fungsi Windows atau Pread64 Linux untuk mengevaluasi file redo log.

Kemudian Anda dapat mengambil langkah-langkah perbaikan berdasarkan hasil.

Untuk menguji kinerja baca pada file log oracle redo atau arsip

1. Buat EC2 instans AMI Amazon AWS DMS diagnostik dan sambungkan ke sana.

   Untuk informasi lebih lanjut lihat, Bekerja dengan AMI AWS DMS diagnostik.

2. Jalankan perintah awsreplperf.

   $ awsreplperf

   Perintah menampilkan opsi AWS DMS Oracle Read Performance Utility.

   0.	Quit
   1.	Read using Bfile
   2.	Read using LogMiner
   3.	Read file PL/SQL (dms_lob.read)
   4.	Read ASMFile Single Thread
   5.	Read ASMFile Multi Thread
   6.	Readfile() function
   

3. Pilih opsi dari daftar.

4. Masukkan koneksi database berikut dan informasi log arsip.

   Oracle user name [system]:
   Oracle password:
   
   Oracle connection name [orcllx]:
   Connection format hostname:port/instance
   
   Oracle event trace? [N]: 
   Default N = No or Y = Yes
   
   Path to redo or archive log file []:
   

5. Periksa output yang ditampilkan untuk informasi kinerja baca yang relevan. Misalnya, berikut ini menunjukkan output yang dapat dihasilkan dari memilih opsi nomor 2, Baca menggunakan LogMiner.

   

6. Untuk keluar dari utilitas, masukkan 0 (nol).

Langkah selanjutnya

• Ketika hasil menunjukkan bahwa kecepatan baca di bawah ambang batas yang dapat diterima, jalankan skrip dukungan diagnostik Oracle pada titik akhir, tinjau bagian Waktu Tunggu, Profil Muat, dan Profil IO. Kemudian sesuaikan konfigurasi abnormal apa pun yang mungkin meningkatkan kinerja baca. Misalnya, jika file log redo Anda hingga 2 GB, coba tingkatkan LOG_BUFFER menjadi 200 MB untuk membantu meningkatkan kinerja.

• Tinjau Praktik AWS DMS Terbaik untuk memastikan instance replikasi DMS, tugas, dan titik akhir dikonfigurasi secara optimal.

Pemecahan masalah dengan MySQL

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

Topik

• Tugas CDC gagal untuk titik akhir instans DB Amazon RDS karena log biner dinonaktifkan

• Koneksi ke instans MySQL target terputus selama pengerjaan tugas

• Menambahkan autocommit ke titik akhir yang kompatibel dengan MySQL

• Menonaktifkan kunci asing pada titik akhir yang kompatibel dengan MySQL target

• Karakter diganti dengan tanda tanya

• Entri log "Peristiwa buruk"

• Mengubah tangkapan data dengan MySQL 5.5

• Meningkatkan retensi log biner untuk instans DB Amazon RDS

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

• Kesalahan: Pengidentifikasi terlalu panjang

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

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

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

Tugas CDC gagal untuk titik akhir instans DB Amazon RDS karena log biner dinonaktifkan

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

Koneksi ke instans MySQL target terputus selama pengerjaan tugas

Jika Anda memiliki tugas LOBs yang terputus dari target MySQL, 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 di mana tugas terputus dari target MySQL, lakukan hal berikut:

• Periksa apakah Anda memiliki serangkaian variabel basis data max_allowed_packet yang cukup besar untuk menahan LOB terbesar Anda.

• Periksa apakah Anda memiliki serangkaian variabel berikut agar bisa memiliki nilai waktu habis yang besar. Kami sarankan agar Anda menggunakan nilai minimal 5 menit untuk masing-masing variabel ini.

  • net_read_timeout

  • net_write_timeout

  • wait_timeout

Untuk informasi tentang pengaturan variabel sistem MySQL, lihat Variabel Sistem Server dalam dokumentasi MySQL.

Menambahkan autocommit ke titik akhir yang kompatibel dengan MySQL

Untuk menambahkan autocommit ke titik akhir yang kompatibel dengan MySQL

1. Masuk ke AWS Management Console dan buka AWS DMS konsol di https://console.aws.amazon.com/dms/v2/.

2. Pilih Titik akhir.

3. Pilih titik akhir target yang kompatibel dengan MySQL yang ingin Anda tambahkan autocommit.

4. Pilih Modifikasi.

5. Pilih Lanjutan, dan kemudian tambahkan kode berikut ke kotak teks Atribut koneksi tambahan:

   
   Initstmt= SET AUTOCOMMIT=1
                   

6. Pilih Modifikasi.

Menonaktifkan kunci asing pada titik akhir yang kompatibel dengan MySQL target

Anda dapat menonaktifkan pemeriksaan kunci asing di MySQL dengan menambahkan hal berikut ke Atribut Koneksi Tambahan dalam bagian Lanjutan dari titik akhir MySQL, Amazon Aurora Edisi Kompatibel MySQL, atau MariaDB target.

Untuk menonaktifkan kunci asing pada titik akhir yang kompatibel dengan MySQL target

1. Masuk ke AWS Management Console dan buka AWS DMS konsol di https://console.aws.amazon.com/dms/v2/.

2. Pilih Titik akhir.

3. Pilih titik akhir MySQL, Aurora MySQL, atau MariaDB target yang kunci asingnya ingin Anda nonaktifkan.

4. Pilih Modifikasi.

5. Pilih Lanjutan, dan kemudian tambahkan kode berikut ke kotak teks Atribut koneksi tambahan:

   
   Initstmt=SET FOREIGN_KEY_CHECKS=0
                   

6. Pilih Modifikasi.

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 dicoba pada titik akhir basis data sumber. Operasi DDL yang tidak didukung menyebabkan peristiwa yang tidak dapat dilewati instans 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 titik setelah operasi DDL yang tidak didukung dikeluarkan.

Mengubah tangkapan data dengan MySQL 5.5

AWS DMS change data capture (CDC) untuk database Amazon RDS MySQL yang kompatibel memerlukan pencatatan biner berbasis baris gambar penuh, yang tidak didukung di MySQL versi 5.5 atau lebih rendah. Untuk menggunakan AWS DMS CDC, Anda harus meningkatkan instans Amazon RDS DB Anda ke MySQL versi 5.6.

Meningkatkan retensi log biner untuk instans DB Amazon RDS

AWS DMS membutuhkan retensi file log biner untuk pengambilan data perubahan. Untuk meningkatkan retensi log pada instans DB Amazon RDS, jalankan 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 database MySQL ke nilai yang ada, pesan dikembalikan zero rows affected dari MySQL. Perilaku ini tidak seperti mesin basis data 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 primer yang digunakan dalam basis data sumber. Sebagai gantinya, DMS menciptakan nama kunci primer berdasarkan nama tabel. Ketika nama tabel panjang, pengidentifikasi yang dibuat secara otomatis dapat lebih panjang dari batas yang diizinkan untuk MySQL.

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 basis data MySQL sumber.

  
[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 solusi, Anda dapat menggunakan atribut koneksi tambahan CharsetMapping dengan titik akhir MySQL sumber Anda 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 sumber MySQL di mana kumpulan karakter sumber Utf8 adalah latin1 atau. 65001 adalah pengidentifikasi 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 dan CDC, atau dua tugas terpisah untuk beban penuh dan CDC, 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 tugas CDC

1. Buat tabel secara manual dengan kunci asing dan indeks pada target agar sesuai dengan tabel sumber.

2. Tambahkan ECA berikut ke titik AWS DMS akhir target:

   Initstmt=SET FOREIGN_KEY_CHECKS=0;

3. Buat AWS DMS tugas dengan TargetTablePrepMode set keDO_NOTHING.

4. Atur pengaturan Stop task after full load completes ke StopTaskCachedChangesApplied.

5. Mulai tugas. AWS DMS menghentikan tugas secara otomatis setelah menyelesaikan beban penuh dan menerapkan perubahan yang di-cache.

6. Hapus SET FOREIGN_KEY_CHECKS ECA yang Anda tambahkan sebelumnya.

7. Lanjutkan tugas. Tugas memasuki fase CDC dan menerapkan perubahan berkelanjutan dari database sumber ke target.

Buat tugas beban penuh dan CDC secara terpisah

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

Buat tugas beban penuh

1. Buat tabel secara manual dengan kunci asing dan indeks pada target agar sesuai dengan tabel sumber.

2. Tambahkan ECA berikut ke titik AWS DMS akhir target:

   Initstmt=SET FOREIGN_KEY_CHECKS=0;

3. Buat AWS DMS tugas dengan TargetTablePrepMode parameter yang disetel ke DO_NOTHING dan EnableValidation atur keFALSE.

4. Mulai tugas. AWS DMS menghentikan tugas secara otomatis setelah menyelesaikan beban penuh dan menerapkan perubahan yang di-cache.

5. Setelah tugas selesai, perhatikan waktu mulai tugas pemuatan penuh di UTC, atau nama dan posisi file log biner, untuk memulai tugas CDC saja. Lihat log untuk mendapatkan stempel waktu di UTC dari waktu mulai pemuatan penuh awal.

Buat tugas khusus CDC

1. Hapus SET FOREIGN_KEY_CHECKS ECA yang Anda atur sebelumnya.

2. Buat tugas khusus CDC dengan posisi awal yang disetel ke waktu mulai beban penuh yang dicatat pada langkah sebelumnya. Atau, Anda dapat menggunakan posisi log biner yang direkam pada langkah sebelumnya. Atur pengaturan TargetTablePrepMode ke DO_NOTHING. Aktifkan validasi data dengan EnableValidation menyetel pengaturan TRUE jika diperlukan.

3. Mulai tugas khusus CDC, dan pantau log untuk kesalahan.

catatan

Solusi ini hanya berlaku untuk migrasi MySQL ke MySQL. Anda tidak dapat menggunakan metode ini dengan fitur Batch Apply, karena Batch Apply mengharuskan tabel target tidak memiliki kunci asing aktif.

Pemecahan masalah dengan PostgreSQL

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

Topik

• Jenis data JSON dipotong

• Kolom dari tipe data yang ditetapkan pengguna tidak dimigrasi dengan benar

• Kesalahan: Tidak ada skema yang dipilih untuk dibuat di dalamnya

• Penghapusan dan pembaruan ke tabel tidak direplikasi menggunakan CDC

• Pernyataan memotong tidak disebarkan

• Mencegah PostgreSQL dari menangkap DDL

• Memilih skema di mana objek basis data untuk menangkap DDL dibuat

• Tabel Oracle hilang setelah bermigrasi ke PostgreSQL

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

• Tugas yang menggunakan tampilan sebagai sumber tidak memiliki baris yang disalin

Jenis data JSON dipotong

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

Sebagai contoh, misalkan mode LOB terbatas diatur ke 4.096 KB. Dalam kasus ini, data JSON yang lebih besar dari 4.096 KB dipotong pada batas 4.096 KB dan gagal dalam tes validasi di PostgreSQL.

Informasi log berikut menunjukkan JSON yang terpotong karena pengaturan mode LOB terbatas dan validasi yang 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 sumber PostgreSQL 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:7 Message NativeError: ERROR: no schema has selected to create in”.

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

Penghapusan dan pembaruan ke tabel tidak direplikasi menggunakan CDC

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

Jika tabel tidak memiliki kunci primer, write-ahead log (WAL) tidak mencakup citra sebelumnya dari baris basis data. 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), operasi TRUNCATE tidak didukung oleh. AWS DMS

Mencegah PostgreSQL dari menangkap DDL

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

"CaptureDDLs": "N"
            

Memilih skema di mana objek basis data untuk menangkap DDL dibuat

Anda dapat mengontrol skema di mana objek basis data yang terkait dengan menangkap DDL dibuat. Tambahkan pernyataan pengaturan Endpoint berikut. Parameter pengaturan Endpoint tersedia di tab titik akhir sumber.

"DdlArtifactsSchema: "xyzddlschema"                
            

Tabel Oracle hilang setelah bermigrasi ke PostgreSQL

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

Oracle default ke nama tabel dalam huruf besar, dan PostgreSQL default ke nama tabel dalam huruf kecil. Ketika Anda melakukan migrasi dari Oracle ke PostgreSQL, kami menyarankan bahwa 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.

• Oracle

• Microsoft SQL Server

• MySQL

• PostgreSQL

• IBM Db2 LUW

• SAP Adaptive Server Enterprise (ASE)

Pemecahan masalah Microsoft SQL Server

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

Topik

• Replikasi yang sedang berlangsung gagal setelah RDS untuk SQL Server gagal ke sekunder

• Kesalahan menangkap perubahan untuk basis data SQL server

• Kolom identitas hilang

• Kesalahan: SQL Server tidak mendukung publikasi

• Perubahan tidak muncul di target Anda

• Tabel yang tidak seragam dipetakan di seluruh partisi

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

Jika instance SQL Server sumber gagal ke sekunder, replikasi yang AWS DMS sedang berlangsung terus mencoba untuk terhubung, dan terus mereplikasi setelah sumber kembali online. Namun, untuk RDS untuk SQL Server MAZ instance, dalam keadaan tertentu pemilik database sekunder dapat diatur ke. NT AUTHORITY\SYSTEM Setelah failover, ini menyebabkan tugas DMS 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 DMS Anda.

Kesalahan 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 ketika 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 'FULL' atau 'BULK LOGGED' untuk secara konsisten menangkap perubahan. Model 'SIMPLE' tidak didukung.

Model pemulihan SIMPLE mencatat informasi minimal yang diperlukan untuk mengizinkan pengguna memulihkan basis data 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 ini adalah mengapa AWS DMS tidak mendukung model pemulihan data SIMPLE. 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 pengambilan data perubahan (CDC), migrasi tabel dengan struktur khusus ditangguhkan ketika tidak AWS DMS dapat melakukan CDC dengan benar di atas meja. 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 menjalankan CDC pada tabel SQL Server, AWS DMS mengurai 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 SQL Server. 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 penguraian yang salah dan memberikan target dengan data yang salah. Solusi mencakup hal berikut:

• Jika tabel memiliki indeks berklaster, lakukan pembuatan ulang indeks.

• Jika tabel tidak memiliki indeks berklaster, tambahkan indeks berklaster ke tabel (Anda dapat menghapusnya nanti jika Anda ingin).

Pemecahan masalah dengan Amazon Redshift

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

Topik

• Memuat ke sebuah klaster Amazon Redshift di Wilayah AWS yang berbeda

• Kesalahan: Relasi "awsdms_apply_exceptions" sudah ada

• Kesalahan dengan tabel yang namanya dimulai dengan "awsdms_changes"

• Melihat tabel dalam klaster dengan nama seperti dms.awsdms_changes000000000XXXX

• Izin yang diperlukan untuk bekerja dengan Amazon Redshift

Memuat ke sebuah klaster Amazon Redshift di Wilayah AWS yang berbeda

Anda tidak dapat memuat ke cluster Amazon Redshift di AWS Wilayah yang berbeda dari instance AWS DMS replikasi Anda. DMS mengharuskan instans replikasi dan klaster Amazon Redshift 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 ditetapkan sebagai titik akhir PostgreSQL. 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 klaster dengan nama seperti dms.awsdms_changes000000000XXXX

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:

• CRUD (Pilih, Sisipkan, Perbarui, Hapus)

• Beban massal

• Membuat, mengubah, membatalkan (jika diperlukan oleh definisi tugas)

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

Pemecahan masalah dengan Amazon Aurora MySQL

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

Topik

• Kesalahan: UTF8 Bidang SET KARAKTER diakhiri oleh baris ',' tertutup oleh '"' yang diakhiri oleh '\n'

Kesalahan: UTF8 Bidang SET KARAKTER diakhiri oleh baris ',' tertutup oleh '"' yang diakhiri oleh '\n'

Jika Anda menggunakan Amazon Aurora MySQL sebagai target, Anda mungkin melihat kesalahan seperti berikut ini di log. Jenis kesalahan ini biasanya menunjukkan bahwa Anda memiliki ANSI_QUOTES sebagai bagian dari parameter SQL_MODE. Memiliki ANSI_QUOTES sebagai bagian dari parameter SQL_MODE menyebabkan tanda kutip ganda untuk ditangani seperti tanda kutip dan dapat membuat masalah ketika Anda menjalankan tugas.

Untuk memperbaiki kesalahan ini, hapus ANSI_QUOTES dari parameter SQL_MODE.

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

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

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

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

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

Memecahkan masalah dengan IBM Db2

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 StartFromContext koneksi ke stempel waktu yang diperlukan. Untuk informasi selengkapnya, lihat Pengaturan titik akhir saat menggunakan Db2 LUW. 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.