View a markdown version of this page

AWS Validasi data DMS - AWS Layanan Migrasi Database
Statistik tugas replikasiStatistik tugas replikasi dengan Amazon CloudWatchMemvalidasi ulang tabel selama pengerjaan tugasMenggunakan editor JSON untuk memodifikasi aturan validasiTugas hanya validasiPemecahan masalahKinerja Validasi Pergeseran MerahValidasi data yang ditingkatkan untuk AWS Database Migration ServiceBatasan

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

AWS Validasi data DMS

Topik

AWS DMS menyediakan dukungan untuk validasi data untuk memastikan bahwa data Anda dimigrasikan secara akurat dari sumber ke target. Jika diaktifkan, validasi dimulai segera setelah beban penuh dilakukan untuk sebuah tabel. Validasi membandingkan perubahan inkremental untuk CDC-enabled tugas saat terjadi.

Selama validasi data, AWS DMS membandingkan setiap baris di sumber dengan baris yang sesuai di target, memverifikasi baris berisi data yang sama, dan melaporkan ketidakcocokan apa pun. Untuk menyelesaikan AWS DMS masalah ini, kueri yang sesuai untuk mengambil data. Perhatikan bahwa kueri ini akan mengonsumsi sumber daya tambahan pada sumber dan target serta sumber daya jaringan tambahan.

Untuk tugas khusus CDC dengan validasi diaktifkan, semua data yang sudah ada sebelumnya dalam tabel divalidasi sebelum memulai validasi data baru.

Validasi data bekerja dengan database sumber berikut di mana pun men AWS DMS dukungnya sebagai titik akhir sumber:

  • Oracle

  • PostgreSQL-compatible database (PostgreSQL, Aurora PostgreSQL, atau Aurora Serverless untuk PostgreSQL)

  • MySQL-compatible database (MySQL, MariaDB, Aurora MySQL, atau Aurora Serverless untuk MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

Validasi data bekerja dengan database target berikut di mana pun men AWS DMS dukungnya sebagai titik akhir target:

  • Oracle

  • PostgreSQL-compatible database (PostgreSQL, Aurora PostgreSQL, atau Aurora Serverless untuk PostgreSQL)

  • MySQL-compatible database (MySQL, MariaDB, Aurora MySQL, atau Aurora Serverless untuk MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

  • Amazon Redshift

  • Amazon S3. Untuk informasi tentang memvalidasi data target Amazon S3, lihatValidasi data target Amazon S3.

Untuk informasi lebih lanjut tentang titik akhir yang didukung, lihat Bekerja dengan AWS Titik akhir DMS.

Validasi data memerlukan waktu tambahan, melampaui jumlah yang diperlukan untuk migrasi itu sendiri. Waktu tambahan yang diperlukan tergantung pada berapa banyak data yang dimigrasi.

Untuk informasi selengkapnya tentang pengaturan ini, lihat Pengaturan tugas validasi data.

Untuk contoh pengaturan ValidationSettings tugas dalam file JSON, lihatContoh pengaturan tugas.

Statistik tugas replikasi

Ketika validasi data diaktifkan, AWS DMS menyediakan statistik berikut di tingkat tabel:

  • ValidationState—Status validasi tabel. Parameter dapat memiliki nilai berikut:

    • Not enabled—Validasi tidak diaktifkan untuk tabel dalam tugas migrasi.

    • Pending records—Beberapa catatan dalam tabel menunggu validasi.

    • Mismatched records—Beberapa catatan dalam tabel tidak cocok antara sumber dan target. Ketidakcocokan mungkin terjadi karena sejumlah alasan; Untuk informasi lebih lanjut, periksa tabel awsdms_control.awsdms_validation_failures_v1 pada titik akhir target.

    • Suspended records—Beberapa catatan dalam tabel tidak dapat divalidasi.

    • No primary key—Tabel tidak dapat divalidasi karena tidak memiliki kunci primer.

    • Table error—Tabel tidak divalidasi karena berada dalam status kesalahan dan beberapa data tidak dimigrasi.

    • Validated—Semua baris dalam tabel divalidasi. Jika tabel diperbarui, status dapat berubah dari Validated.

    • Error—Tabel tidak dapat divalidasi karena ada kesalahan tidak terduga.

    • Pending validation—Tabel menunggu validasi.

    • Mempersiapkan tabel—Mempersiapkan tabel diaktifkan dalam tugas migrasi untuk validasi.

    • Pending revalidation—Validasi semua baris dalam tabel tertunda setelah tabel diperbarui.

  • ValidationPending—Jumlah catatan yang telah dimigrasikan ke target, tetapi belum divalidasi.

  • ValidationSuspended—Jumlah catatan yang tidak AWS DMS bisa dibandingkan. Misalnya, jika catatan di sumber terus diperbarui, tidak AWS DMS dapat membandingkan sumber dan target.

  • ValidationFailed—Jumlah catatan yang tidak melewati fase validasi data.

Untuk contoh pengaturan ValidationSettings tugas dalam file JSON, lihatContoh pengaturan tugas.

Anda dapat melihat informasi validasi data menggunakan konsol, AWS CLI, atau AWS DMS API.

  • Di konsol, Anda dapat memilih untuk memvalidasi tugas saat Anda membuat atau memodifikasi tugas. Untuk melihat laporan validasi data menggunakan konsol, pilih tugas di halaman Tugas dan pilih tab Statistik tabel di bagian detail.

  • Menggunakan CLI, atur EnableValidation parameter ke true saat membuat atau memodifikasi tugas untuk memulai validasi data. Contoh berikut membuat tugas dan mengaktifkan validasi data.

    create-replication-task  
  --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' 
  --replication-instance-arn arn:aws:dms:us-east-1:111122223333:
     rep:36KWVMB7Q  
  --source-endpoint-arn arn:aws:dms:us-east-1:111122223333:
     endpoint:CSZAEFQURFYMM  
  --target-endpoint-arn arn:aws:dms:us-east-1:111122223333:
     endpoint:CGPP7MF6WT4JQ 
  --migration-type full-load-and-cdc 
  --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", 
     "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, 
     "rule-action": "include"}]}'

    Gunakan perintah describe-table-statistics untuk menerima laporan validasi data dalam format JSON. Perintah berikut menunjukkan laporan validasi data.

    aws dms  describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:111122223333:task:36KWVMB7Q

    Laporan tersebut akan serupa dengan berikut ini.

    {
    "ReplicationTaskArn": "arn:aws:dms:us-west-2:111122223333:task:VFPFTYKK2RYSI", 
    "TableStatistics": [
        {
            "ValidationPendingRecords": 2, 
            "Inserts": 25, 
            "ValidationState": "Pending records", 
            "ValidationSuspendedRecords": 0, 
            "LastUpdateTime": 1510181065.349, 
            "FullLoadErrorRows": 0, 
            "FullLoadCondtnlChkFailedRows": 0, 
            "Ddls": 0, 
            "TableName": "t_binary", 
            "ValidationFailedRecords": 0, 
            "Updates": 0, 
            "FullLoadRows": 10, 
            "TableState": "Table completed", 
            "SchemaName": "d_types_s_sqlserver", 
            "Deletes": 0
        }
}

  • Menggunakan AWS DMS API, buat tugas menggunakan CreateReplicationTask tindakan dan atur EnableValidation parameter ke true untuk memvalidasi data yang dimigrasi oleh tugas. Gunakan DescribeTableStatistics tindakan untuk menerima laporan validasi data dalam format JSON.

Statistik tugas replikasi dengan Amazon CloudWatch

Saat Amazon CloudWatch diaktifkan, AWS DMS menyediakan statistik tugas replikasi berikut:

  • ValidationSucceededRecordCount— Jumlah baris yang di AWS DMS validasi, per menit.

  • ValidationAttemptedRecordCount— Jumlah baris yang dicoba validasi, per menit.

  • ValidationFailedOverallCount— Jumlah baris di mana validasi gagal.

  • ValidationSuspendedOverallCount— Jumlah baris di mana validasi ditangguhkan.

  • ValidationPendingOverallCount— Jumlah baris di mana validasi masih tertunda.

  • ValidationBulkQuerySourceLatency- AWS DMS dapat melakukan validasi data secara massal, terutama dalam skenario tertentu selama replikasi beban penuh atau sedang berlangsung ketika ada banyak perubahan. Metrik ini menunjukkan latensi yang diperlukan untuk membaca kumpulan data massal dari titik akhir sumber.

  • ValidationBulkQueryTargetLatency- AWS DMS dapat melakukan validasi data secara massal, terutama dalam skenario tertentu selama replikasi beban penuh atau sedang berlangsung ketika ada banyak perubahan. Metrik ini menunjukkan latensi yang diperlukan untuk membaca kumpulan data massal dari titik akhir target.

  • ValidationItemQuerySourceLatencySelama replikasi yang sedang berlangsung, validasi data dapat mengidentifikasi perubahan yang sedang berlangsung dan memvalidasi perubahan tersebut. Metrik ini menunjukkan latensi dalam membaca perubahan tersebut dari sumber. Validasi dapat menjalankan lebih banyak kueri dari yang diperlukan, berdasarkan jumlah perubahan, jika ada kesalahan selama validasi.

  • ValidationItemQueryTargetLatency- Selama replikasi yang sedang berlangsung, validasi data dapat mengidentifikasi perubahan yang sedang berlangsung dan memvalidasi perubahan baris demi baris. Metrik ini memberi kita latensi dalam membaca perubahan tersebut dari target. Validasi dapat menjalankan lebih banyak kueri dari yang diperlukan, berdasarkan jumlah perubahan, jika ada kesalahan selama validasi.

Untuk mengumpulkan informasi validasi data dari statistik yang CloudWatch diaktifkan, pilih Akti CloudWatch f kan log saat Anda membuat atau memodifikasi tugas menggunakan konsol. Kemudian, untuk melihat informasi validasi data dan memastikan bahwa data Anda dimigrasi secara akurat dari sumber ke target, lakukan hal berikut.

  1. Pilih tugas di halaman Tugas migrasi basis data.

  2. Pilih tab CloudWatch metrik.

  3. Pilih Validasi dari menu tarik turun.

Memvalidasi ulang tabel selama pengerjaan tugas

Saat tugas sedang berjalan, Anda dapat meminta AWS DMS untuk melakukan validasi data.

Konsol Manajemen AWS

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

    Jika Anda masuk sebagai pengguna AWS Identity and Access Management (IAM), pastikan Anda memiliki izin yang sesuai untuk mengakses AWS DMS. izin yang diperlukan, lihatIzin IAM diperlukan untuk menggunakan AWS DMS.

  2. Pilih Tugas dari panel navigasi.

  3. Pilih tugas berjalan yang memiliki tabel yang ingin Anda validasi ulang.

  4. Pilih tab Statistik Tabel.

  5. Pilih tabel yang ingin Anda validasi ulang (Anda dapat memilih hingga 10 tabel sekaligus). Jika tugas tidak lagi berjalan, Anda tidak dapat memvalidasi ulang tabel.

  6. Pilih Validasi Ulang.

Menggunakan editor JSON untuk memodifikasi aturan validasi

Untuk menambahkan aturan validasi ke tugas menggunakan editor JSON dari Kon AWS DMS sol, lakukan hal berikut:

  1. Pilih Tugas migrasi basis data.

  2. Pilih tugas Anda dari daftar tugas migrasi.

  3. Jika tugas Anda sedang berjalan, pilih Berhenti dari menu tarik turun Tindakan.

  4. Setelah tugas telah berhenti, untuk memodifikasi tugas Anda, pilih Modifikasi dari menu tarik turun Tindakan.

  5. Di bagian Pemetaan tabel, pilih Editor JSON dan tambahkan aturan validasi Anda ke pemetaan tabel Anda.

Misalnya, Anda dapat menambahkan aturan validasi berikut untuk menjalankan fungsi ganti pada sumber. Dalam kasus ini, jika aturan validasi bertemu null byte, byte tersebut akan divalidasi sebagai spasi.

{
	"rule-type": "validation",
	"rule-id": "1",
	"rule-name": "1",
	"rule-target": "column",
	"object-locator": {
		"schema-name": "Test-Schema",
		"table-name": "Test-Table",
		"column-name": "Test-Column"
	},
	"rule-action": "override-validation-function",
	"source-function": "REPLACE(${column-name}, chr(0), chr(32))",
	"target-function": "${column-name}"
}
catatan

override-validation-functiontidak berlaku jika kolom adalah bagian dari kunci utama.

Tugas hanya validasi

Anda dapat membuat tugas hanya validasi untuk melihat pratinjau dan memvalidasi data tanpa melakukan migrasi atau replikasi data apa pun. Untuk membuat tugas validasi saja, atur ValidationOnly pengaturan EnableValidation dan ketrue. Saat mengaktifkanValidationOnly, persyaratan tambahan berlaku. Untuk informasi selengkapnya, lihat Pengaturan tugas validasi data.

Untuk jenis migrasi hanya beban penuh, tugas hanya validasi selesai jauh lebih cepat daripada yang setara dengan CDC ketika banyak kegagalan dilaporkan. Tetapi perubahan pada titik akhir sumber atau target dilaporkan sebagai kegagalan untuk mode beban penuh, kemungkinan kerugian.

Tugas validasi CDC hanya menunda validasi berdasarkan latensi rata-rata, dan mencoba kembali kegagalan beberapa kali sebelum melaporkannya. Jika sebagian besar perbandingan data mengakibatkan kegagalan, tugas validasi saja untuk mode CDC sangat lambat, potensi kelemahan.

Tugas validasi saja harus diatur ke arah yang sama dengan tugas replikasi, terutama untuk CDC. Ini karena tugas Hanya Validasi CDC mendeteksi baris mana yang telah berubah dan perlu divalidasi ulang berdasarkan log perubahan pada sumber. Jika target ditentukan sebagai sumber, maka ia hanya tahu tentang perubahan yang dikirim ke target oleh DMS dan tidak dijamin untuk menangkap kesalahan replikasi.

Hanya validasi beban penuh

Dimulai dengan AWS DMS versi 3.4.6 dan yang lebih tinggi, tugas validasi beban penuh dengan cepat membandingkan semua baris dari tabel sumber dan target dalam satu lintasan, segera melaporkan kegagalan, dan kemudian dimatikan. Validasi tidak pernah ditangguhkan karena kegagalan dalam mode ini, itu dioptimalkan untuk kecepatan. Tetapi perubahan pada titik akhir sumber atau target dilaporkan sebagai kegagalan.

catatan

Dimulai dengan AWS DMS versi 3.4.6 dan yang lebih tinggi, perilaku validasi ini juga berlaku untuk tugas migrasi beban penuh dengan validasi diaktifkan.

Hanya validasi CDC

Tugas validasi CDC saja memvalidasi semua baris yang ada antara tabel sumber dan target pada awal yang baru. Selain itu, tugas validasi CDC hanya berjalan terus menerus, memvalidasi ulang perubahan replikasi yang sedang berlangsung, membatasi jumlah kegagalan yang dilaporkan setiap pass, dan mencoba ulang baris yang tidak cocok sebelum gagal. Ini dioptimalkan untuk mencegah positif palsu.

Validasi untuk tabel (atau seluruh tugas) ditangguhkan jika TableFailureMaxCount ambang batas FailureMaxCount atau dilanggar. Ini juga berlaku untuk tugas migrasi CDC atau Full Load+CDC dengan validasi diaktifkan. Dan tugas CDC dengan validasi memungkinkan penundaan validasi ulang untuk setiap baris yang diubah berdasarkan latensi sumber dan target rata-rata.

Tetapi tugas validasi CDC saja tidak memigrasikan data dan tidak memiliki latensi. Ini diatur ValidationQueryCdcDelaySeconds ke 180 secara default. Dan Anda dapat meningkatkan jumlah untuk memperhitungkan lingkungan latensi tinggi dan membantu mencegah positif palsu.

Validasi hanya menggunakan kasus

Kasus penggunaan untuk memisahkan bagian validasi data dari tugas migrasi atau replikasi menjadi tugas validasi terpisah mencakup, namun tidak terbatas pada, hal-hal berikut:

  • Kontrol tepat kapan validasi terjadi — Kueri validasi menambahkan beban tambahan ke titik akhir sumber dan target. Jadi, memigrasikan atau mereplikasi data dalam satu tugas terlebih dahulu, kemudian memvalidasi hasil di tugas lain dapat bermanfaat.

  • Mengurangi beban pada instance replikasi — Memisahkan validasi data untuk dijalankan pada instansnya sendiri dapat menguntungkan.

  • Dapatkan dengan cepat berapa banyak baris yang tidak cocok pada saat tertentu — Misalnya, tepat sebelum atau selama pemotongan produksi jendela pemeliharaan — ke titik akhir target, Anda dapat membuat tugas validasi Beban Penuh saja untuk mendapatkan jawaban atas pertanyaan Anda.

  • Ketika kegagalan validasi diharapkan untuk tugas migrasi dengan komponen CDC — Misalnya, jika memigrasikan Oracle varchar2 ke PostgreSQLjsonb, validasi CDC terus mencoba lagi baris yang gagal ini dan membatasi jumlah kegagalan yang dilaporkan setiap kali. Namun, Anda dapat membuat tugas validasi Beban Penuh saja dan mendapatkan jawaban yang lebih cepat.

  • Anda telah mengembangkan perbaikan data script/utility yang membaca tabel kegagalan validasi - (Lihat juga,Pemecahan masalah). Tugas hanya validasi Beban Penuh dengan cepat melaporkan kegagalan skrip perbaikan data untuk ditindaklanjuti.

Untuk contoh pengaturan ValidationSettings tugas dalam file JSON, lihatContoh pengaturan tugas).

Pemecahan masalah

Selama validasi AWS DMS , membuat tabel baru di titik akhir target:awsdms_control.awsdms_validation_failures_v1. Jika ada catatan memasuki ValidationSuspended atau ValidationFailed status, AWS DMS tulis informasi diagnostik keawsdms_control.awsdms_validation_failures_v1. Anda dapat mengkueri tabel ini untuk membantu memecahkan kesalahan validasi.

Untuk informasi tentang mengubah skema default tabel dibuat pada target, lihat Pengaturan tugas tabel kontrol.

Berikut ini adalah deskripsi dari tabel awsdms_control.awsdms_validation_failures_v1:

Nama kolom Jenis data Deskripsi

TASK_NAME

VARCHAR(128) NOT NULL

AWS DMS pengidentifikasi tugas.
TABLE_OWNER VARCHAR(128) NOT NULL

Skema (pemilik) dari tabel.

TABLE_NAME

 VARCHAR(128) NOT NULL

Nama tabel.
FAILURE_TIME DATETIME(3) NOT NULL

Waktu ketika kegagalan terjadi.
KEY_TYPE VARCHAR(128) NOT NULL

Dicadangkan untuk penggunaan di masa mendatang (nilai selalu 'Row')
KEY TEXT NOT NULL

Ini adalah kunci primer untuk jenis catatan baris.
FAILURE_TYPE VARCHAR(128) NOT NULL

Tingkat kepelikan kesalahan validasi. Bisa berupaRECORD_DIFF,MISSING_SOURCE,MISSING_TARGET, atauTABLE_WARNING.
DETAILS VARCHAR(8000) NOT NULL

String berformat JSON dari semua nilai source/target kolom yang tidak cocok untuk kunci yang diberikan.

Berikut ini adalah contoh kueri untuk target MySQL yang akan menunjukkan kepada Anda semua kegagalan untuk tugas dengan menanyakan awsdms_control.awsdms_validation_failures_v1 tabel. Perhatikan bahwa nama skema dan sintaks kueri akan bervariasi di seluruh versi mesin target. Nama tugas harus ID sumber daya eksternal tugas tersebut. ID sumber daya eksternal dari tugas adalah nilai terakhir dalam ARN tugas. Misalnya, untuk tugas dengan nilai ARN arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI, ID sumber daya eksternal tugas tersebut adalah VFPFKH4FJR3FTYKK2RYSI.


select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI'

TASK_NAME       VFPFKH4FJR3FTYKK2RYSI
TABLE_OWNER     DB2PERF
TABLE_NAME      PERFTEST
FAILURE_TIME    2020-06-11 21:58:44
KEY_TYPE        Row
KEY             {"key":  ["3451491"]}
FAILURE_TYPE    RECORD_DIFF
DETAILS         [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],]

Anda dapat melihat bidang DETAILS untuk menentukan kolom yang tidak cocok. Karena Anda memiliki kunci primer dari catatan yang gagal, Anda dapat mengkueri titik akhir sumber dan target untuk melihat bagian dari catatan yang tidak cocok.

tabel kontrol awsdms _validation_failures_v2

Selama validasi, dalam AWS DMS versi 3.6.1 dan yang lebih tinggi, DMS membuat tabel baru di titik akhir target PostgreSQL:. awsdms_validation_failures_v2 Tabel ini terdiri dari kegagalan untuk semua tugas DMS yang memiliki validasi data diaktifkan. Saat awsdms_validation_failures_v2 tabel dibuat, Anda tidak boleh melepas atau memotong tabel karena dapat menyebabkan kesalahan untuk tugas apa pun dengan validasi dan sinkronisasi ulang diaktifkan. awsdms_validation_failures_v2tabel memiliki fitur kunci utama penambahan otomatis. Tabel ini terdiri dari kolom baru untuk mendukung fitur sinkronisasi ulang Data. File tersebut adalah:

RESYNC_RESULT

Nilai: SUCCESS atauFAILURE.

RESYNC_TIME

Stempel waktu dengan presisi milidetik. Nilai default adalah NULL jika sinkronisasi ulang Data tidak dicoba untuk kegagalan ini.

RESYNC_ACTION

Nilai: UPSERT atauDELETE.

RESYNC_ID

Kolom kunci utama dengan penambahan otomatis diaktifkan.

Dalam awsdms_validation_failures_v2 tabel, indeks ditambahkan ke FAILURE_TIME kolomTASK_NAME,,, TABLE_OWNER TABLE_NAMEFAILURE_TYPE, dan untuk membaca kegagalan secara efisien untuk setiap tabel tertentu dalam database target Anda. Di bawah ini adalah contoh membuat pernyataan untuk membuat awsdms_validation_failures_v2 tabel:

CREATE TABLE public.awsdms_validation_failures_v2 (
    "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
    "TASK_NAME" varchar(128) NOT NULL,
    "TABLE_OWNER" varchar(128) NOT NULL,
    "TABLE_NAME" varchar(128) NOT NULL,
    "FAILURE_TIME" timestamp NOT NULL,
    "KEY_TYPE" varchar(128) NOT NULL,
    "KEY" varchar(7800) NOT NULL,
    "FAILURE_TYPE" varchar(128) NOT NULL,
    "DETAILS" varchar(7000) NOT NULL,
    "RESYNC_RESULT" varchar(128) NULL,
    "RESYNC_TIME" timestamp NULL,
    "RESYNC_ACTION" varchar(128) NULL,
    CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID")
);

Kinerja Validasi Pergeseran Merah

Amazon Redshift berbeda dari database relasional dalam beberapa hal, termasuk penyimpanan kolumnar, MPP, kompresi data, dan faktor lainnya. Perbedaan ini memberi Redshift profil kinerja yang berbeda dari database relasional.

Selama fase replikasi beban penuh, validasi menggunakan kueri rentang, dengan ukuran data diatur oleh PartitionSize pengaturan. Kueri berbasis rentang ini memilih semua catatan dari tabel sumber.

Untuk replikasi yang sedang berlangsung, kueri beralih antara pengambilan rekaman berbasis rentang dan individual. Jenis kueri ditentukan secara dinamis berdasarkan beberapa faktor, seperti berikut ini:

  • Volume kueri

  • Jenis kueri DML pada tabel sumber

  • Latensi tugas

  • Jumlah total catatan

  • Pengaturan validasi seperti PartitionSize

Anda mungkin melihat beban tambahan pada cluster Amazon Redshift Anda karena kueri validasi. Karena faktor-faktor di atas bervariasi di seluruh kasus penggunaan, Anda harus meninjau kinerja kueri validasi dan menyesuaikan cluster dan tabel sesuai dengan itu. Beberapa opsi untuk mengurangi isses kinerja termasuk yang berikut:

  • Kurangi ThreadCount pengaturan PartitionSize dan untuk membantu mengurangi beban kerja selama validasi beban penuh. Perhatikan bahwa ini akan memperlambat validasi data.

  • Meskipun Redshift tidak menerapkan kunci utama, AWS DMS bergantung pada kunci utama untuk mengidentifikasi catatan secara unik pada target untuk validasi data. Jika memungkinkan, atur kunci utama untuk mencerminkan kunci pengurutan sehingga kueri validasi beban penuh dijalankan lebih cepat.

Validasi data yang ditingkatkan untuk AWS Database Migration Service

AWS Database Migration Service telah meningkatkan kinerja validasi data untuk migrasi database, memungkinkan pelanggan memvalidasi kumpulan data besar dengan waktu pemrosesan yang jauh lebih cepat. Validasi data yang disempurnakan ini sekarang tersedia di versi 3.5.4 dari mesin replikasi untuk beban penuh dan beban penuh dengan tugas migrasi CDC. Saat ini, peningkatan ini mendukung jalur migrasi dari Oracle ke PostgreSQL, SQL Server ke PostgreSQL, Oracle ke Oracle, dan SQL Server ke SQL Server, dengan jalur migrasi tambahan yang direncanakan untuk rilis mendatang.

Prasyarat

  • Oracle: berikan EXECUTE izin SYS.DBMS_CRYPTO ke akun pengguna yang mengakses titik akhir Oracle:

    GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user;

  • Instal pgcrypto ekstensi pada database PostgreSQL:

    Untuk instans PostgreSQL yang dikelola sendiri, Anda perlu menginstal pustaka contrib modul dan membuat ekstensi:

    • Instal pust contrib aka modul. Misalnya, pada instans Amazon EC2 dengan Amazon Linux dan PostgreSQL 15:

      sudo dnf install postgresql15-contrib

    • Buat pgcrypto ekstensi:

      CREATE EXTENSION IF NOT EXISTS pgcrypto;

  • Untuk instans Amazon RDS untuk PostgreSQL, konfigurasikan mode SSL untuk titik akhir: AWS DMS

    • Secara default, Amazon RDS memaksa koneksi SSL. Saat Anda membuat AWS DMS titik akhir untuk instans Amazon RDS untuk PostgreSQL, gunakan opsi “mode SSL” = “required”.

    • Jika Anda ingin menggunakan opsi “mode SSL” = “none”, atur rds.force_ssl parameter ke 0 di Grup Parameter RDS.

  • Untuk PostgreSQL 12 dan 13, buat agregat: BIT_XOR

    CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit);

Batasan validasi data yang ditingkatkan

Fitur validasi data yang disempurnakan ini memiliki batasan sebagai berikut:

  • Persyaratan titik akhir database: Peningkatan ini diaktifkan hanya untuk titik akhir database yang memenuhi kriteria berikut:

    • Gunakan AWS Secrets Manager untuk menyimpan kredenSIAL.

    • Untuk Microsoft SQL Server, otentikasi Kerberos juga didukung.

  • Dukungan versi database:

    • PostgreSQL 12 dan lebih tinggi

    • Oracle 12.1 dan yang lebih tinggi

    • Untuk versi Microsoft SQL Server yang lebih rendah dari 2019, validasi tipe data NCHAR dan NVARCHAR tidak didukung.

Batasan

  • Validasi data mengharuskan tabel memiliki kunci primer atau indeks unik.

    • Kolom kunci utama tidak boleh berupa tipeCLOB,BLOB,BINARY, atauBYTE.

    • Untuk kolom kunci primer jenis VARCHAR atau CHAR, panjangnya harus kurang dari 1024. Anda harus menentukan panjang dalam tipe data. Anda tidak dapat menggunakan tipe data tak terbatas sebagai kunci utama untuk validasi data.

    • Kunci Oracle yang dibuat dengan NOVALIDATE klausa tidak dianggap sebagai kunci utama atau indeks unik.

    • Untuk tabel Oracle tanpa kunci primer dan hanya kunci unik, kolom dengan batasan unik juga harus memiliki batasanNOT NULL.

  • Validasi PK/UK nilai NULL tidak didukung.

  • Jika kolasi kolom kunci primer dalam instans PostgreSQL target tidak diatur ke "C", urutan kunci primer berbeda dibandingkan dengan urutan di Oracle. Jika urutan berbeda antara PostgreSQL dan Oracle, validasi data gagal untuk memvalidasi catatan.

  • Validasi data menghasilkan kueri tambahan terhadap basis data sumber dan target. Anda harus memastikan bahwa kedua basis data memiliki cukup sumber daya untuk menangani beban tambahan ini. Ini terutama berlaku untuk target Redshift. Untuk informasi lebih lanjut, lihat Kinerja Validasi Pergeseran Merah berikut ini.

  • Validasi data tidak didukung saat menggabungkan beberapa database menjadi satu.

  • Untuk titik akhir Oracle sumber atau target, AWS DMS gunakanDBMS_CRYPTO. Jika Anda menggunakan validasi data pada titik akhir Oracle, Anda harus memberikan izin eksekusi pada dbms_crypto akun pengguna yang digunakan untuk mengakses titik akhir Oracle. Anda dapat melakukan ini dengan menjalankan pernyataan berikut

    grant execute on sys.dbms_crypto to dms_endpoint_user;

  • Jika database target dimodifikasi di luar AWS DMS selama validasi, maka perbedaan mungkin tidak dilaporkan secara akurat. Hasil ini dapat terjadi jika salah satu aplikasi Anda menulis data ke tabel target, saat AWS DMS melakukan validasi pada tabel yang sama.

  • Jika satu atau lebih baris terus dimodifikasi selama validasi, maka tidak AWS DMS dapat memvalidasi baris tersebut.

  • Jika AWS DMS mendeteksi lebih dari 10.000 catatan gagal atau ditangguhkan, validasi akan dihentikan. Sebelum Anda melanjutkan lebih jauh, selesaikan masalah yang mendasari dengan data tersebut.

  • AWS DMS tidak mendukung validasi data tampilan.

  • AWS DMS tidak mendukung validasi data saat pengaturan tugas substitusi karakter digunakan.

  • AWS DMS tidak mendukung memvalidasi tipe Oracle LONG.

  • AWS DMS tidak mendukung validasi tipe Oracle Spatial selama migrasi heterogen.

  • Validasi data mengabaikan kolom dalam tabel yang transformasi penyembunyian datanya ada dalam pemetaan tabel.

  • Validasi data melewatkan seluruh tabel jika ada aturan transformasi penyembunyian data untuk kolomnya PK/UK . Status validasi akan ditampilkan sebagai Tidak ada kunci utama untuk tabel tersebut.

  • Validasi data tidak berfungsi dengan Amazon Aurora PostgreSQL Limitless. Saat mencoba memvalidasi tabel dalam Database Tanpa Batas, status validasi menampilkan “Tidak ada kunci primer” untuk tabel ini.

Untuk keterbatasan saat menggunakan validasi target S3, lihatBatasan untuk menggunakan validasi target S3.