Masalah verifikasi data - Data Transmission Service - Alibaba Cloud Documentation Center

T: Apa penyebab ketidakkonsistenan data dalam tugas verifikasi data?
Penyebab umumnya adalah sebagai berikut:
1. Tugas migrasi atau sinkronisasi data mengalami latensi.
2. Database sumber melakukan operasi ADD COLUMN dengan nilai default saat tugas mengalami latensi.
3. Database tujuan menerima penulisan data dari sumber selain DTS.
4. Database sumber pada tugas yang telah mengaktifkan fitur penggabungan multi-tabel melakukan operasi DDL.
5. Tugas migrasi atau sinkronisasi data menggunakan fitur pemetaan nama database, tabel, atau kolom.
T: Mengapa tugas verifikasi skema mendeteksi perbedaan pada isRelHasoids?
Database PostgreSQL versi sebelum 12 mendukung pembuatan tabel dengan WITH OIDS untuk menambahkan kolom object identifier (OID) yang unik secara global. Jika sumber tugas verifikasi skema menentukan WITH OIDS saat membuat tabel dan tujuannya adalah versi PostgreSQL yang lebih baru yang tidak mendukung WITH OIDS, tugas tersebut akan melaporkan perbedaan isRelHasoids.
T: Apakah perbedaan isRelHasoids yang dilaporkan oleh tugas verifikasi skema perlu diperhatikan?
No.
T: Apakah DTS menyinkronkan atau memigrasikan kolom object identifier (OID)?
Kolom object identifier (OID) dibuat secara otomatis saat WITH OIDS ditentukan. DTS tidak menyinkronkan atau memigrasikan data ini, terlepas dari apakah tujuan mendukung kolom tersebut atau tidak.
T: Bagaimana cara memeriksa apakah suatu tabel memiliki kolom object identifier (OID)?
Catatan
Ganti <table_name> dalam perintah dengan nama tabel yang ingin Anda kueri.
- Perintah SQL: SELECT relname AS table_name, relhasoids AS has_oids FROM pg_class WHERE relname = '<table_name>' AND relkind = 'r';
- Perintah klien: \d+ <table_name>
T: Bagaimana cara mengatasi ketidakkonsistenan data yang dilaporkan dalam laporan verifikasi data penuh?
Anda dapat mengatasi masalah tersebut dengan langkah-langkah berikut:
1. Tinjau laporan verifikasi untuk mengidentifikasi nilai sumber dan tujuan untuk setiap kolom, lalu konfirmasi kolom dan nilai mana yang tidak konsisten.
2. Berdasarkan laporan verifikasi, login secara manual ke database sumber dan tujuan, lalu bandingkan nilai yang berbeda untuk menentukan apakah perbedaan tersebut diharapkan.
3. Pastikan tidak ada data yang ditulis ke sumber atau tujuan selama verifikasi. Jika hal ini tidak dapat dipastikan, kami menyarankan agar Anda menghentikan sementara penulisan ke database sumber selama jam sepi, lalu mulai ulang verifikasi tersebut.
4. Jika perbedaan tetap ada, Anda dapat mengaktifkan sementara SQL Explorer (pay-as-you-go) pada kedua sisi—sumber dan tujuan—lalu gunakan log audit untuk memeriksa apakah kolom tersebut dimodifikasi.
5. Perbedaan pada beberapa atribut (seperti SECURITY_TYPE) merupakan perilaku yang diharapkan dan dapat diabaikan.
6. Verifikasi data penuh yang berhasil mengonfirmasi konsistensi data setelah modifikasi backend non-standar.
7. Ketidakkonsistenan verifikasi data penuh biasanya tidak terkait dengan perbedaan skema. Kami menyarankan agar Anda menjalankan count(*) secara manual untuk membandingkan jumlah baris antara database sumber dan tujuan guna verifikasi lebih lanjut.
T: Mengapa DTS menampilkan progres tugas sebagai belum lengkap (misalnya, 41%) meskipun transmisi data telah selesai?
Persentase progres tugas DTS mencakup dua tahap: transmisi data (migrasi data penuh) dan verifikasi data. Setelah migrasi data penuh selesai, sisa progres mencerminkan verifikasi data yang sedang berlangsung. Verifikasi data merupakan pemeriksaan konsistensi independen yang dijalankan setelah transmisi data penuh selesai. Tugas secara keseluruhan dianggap selesai hanya ketika progres verifikasi mencapai 100%.
Jika Anda perlu mengonfirmasi data segera setelah transmisi selesai, Anda dapat menghubungkan secara manual ke database tujuan untuk memeriksa data tanpa menunggu verifikasi selesai.
T: Penyebab dan solusi kueri SQL yang lambat selama tahap verifikasi data penuh
Penyebab: Selama tahap verifikasi data penuh, DTS membaca tabel besar dalam shard berdasarkan ID primary key. Saat volume data besar, kueri shard membutuhkan waktu lebih lama dan dapat menyebabkan kueri SQL lambat pada database sumber.
Solusi:
1. Pertama, verifikasi apakah tugas verifikasi data penuh telah dihentikan. Jika ya, kueri semacam itu seharusnya tidak dihasilkan.
2. Jika tugas verifikasi masih berjalan dan memengaruhi bisnis Anda, kami menyarankan agar Anda menjalankan verifikasi data penuh selama jam sepi, atau menangguhkan tugas verifikasi tersebut dan memulai ulang pada jam sepi.