Saya punya setup AG 4 simpul sebagai berikut:
Konfigurasi Perangkat Keras VM untuk semua node:
- Microsoft SQL Server 2017 Enterprise Edition (RTM-CU14) (KB4484710)
- 16 vCPU
- RAM 356 GB (panjang untuk yang ini ...)
- tingkat paralelisme maks: 1 (seperti yang dipersyaratkan oleh vendor aplikasi)
- ambang biaya untuk paralelisme: 50
- memori server maks (MB): 338944 (331 GB)
Konfigurasi AG:
- Node 1: Komit Primer atau Sinkron sekunder yang tidak dapat dibaca, Dikonfigurasi untuk Kegagalan Otomatis
- Node 2: Komit Primer atau Sinkron sekunder yang tidak dapat dibaca, Dikonfigurasi untuk Kegagalan Otomatis
- Node 3: Set Sekunder yang Dapat Dibaca dengan Komit Asinkron, Dikonfigurasi untuk Failover Manual
- Node 4: Set Sekunder yang Dapat Dibaca dengan Komit Asinkron, Dikonfigurasi untuk Failover Manual
Pertanyaan dalam Pertanyaan:
Tidak ada yang terlalu gila dengan kueri ini, ia menyediakan ringkasan item pekerjaan luar biasa dalam berbagai antrian dalam aplikasi. Anda dapat melihat kode dari salah satu tautan rencana eksekusi di bawah ini.
Perilaku Eksekusi pada Simpul Primer:
Ketika dieksekusi pada node Primer, waktu eksekusi umumnya sekitar 1 detik. Berikut adalah rencana eksekusi , dan di bawah ini adalah statistik yang diambil dari STATISTIK IO dan STATISTIK TIME dari simpul utama:
(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 500 ms, elapsed time = 656 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.Perilaku Eksekusi pada simpul Sekunder Read-Only:
Saat mengeksekusi pada simpul sekunder hanya baca (yaitu simpul 3 atau simpul 4), kueri ini menggunakan rencana eksekusi yang sama (ini adalah tautan rencana yang berbeda) dan secara kasar ditampilkan statistik eksekusi yang sama (misalnya mungkin ada beberapa halaman lagi memindai karena hasil ini selalu berubah), tetapi dengan pengecualian waktu CPU, mereka terlihat sangat mirip. Berikut adalah statistik yang diambil dari STATISTIK IO dan STATISTIK TIME dari simpul sekunder read-only:
(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 55719 ms, elapsed time = 56335 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.Detail lainnya:
Saya juga menjalankan keduanya sp_WhoIsActivedan skrip Paul Randal padaWaitingTasks.sql skrip kedua saat kueri ini dieksekusi, tetapi saya tidak melihat ada menunggu apa pun yang terjadi, yang terus terang membuat frustrasi:
Ini juga tidak terlihat sebagai kasus latensi AG karena status Sinkronisasi sebenarnya cukup baik:
--https://sqlperformance.com/2015/08/monitoring/availability-group-replica-sync
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS ag_name,
drs.is_local,
drs.synchronization_state_desc,
drs.synchronization_health_desc,
--drs.last_hardened_lsn,
--drs.last_hardened_time,
drs.last_redone_time,
drs.redo_queue_size,
drs.redo_rate,
(drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
drs.last_commit_lsn,
drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc
ON drs.group_id = adc.group_id AND
drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar
ON drs.group_id = ar.group_id AND
drs.replica_id = ar.replica_id
ORDER BY
ag.name,
ar.replica_server_name,
adc.database_name;
Permintaan ini tampaknya merupakan pelaku terburuk. Kueri lain yang juga mengambil sub-detik kali pada Node Primer mungkin memakan waktu 1 - 5 detik pada simpul Sekunder, dan sementara perilaku tidak separah itu, itu tampaknya menyebabkan masalah.
Akhirnya, saya juga melihat server dan memeriksa proses eksternal seperti Pemindaian A / V, pekerjaan eksternal yang menghasilkan I / O yang tidak terduga, dll. Dan muncul dengan tangan kosong. Saya tidak berpikir ini disebabkan oleh apa pun di luar proses SQL Server.
Pertanyaan:
Hanya siang hari di mana saya berada dan sudah hari yang panjang, jadi saya curiga saya kehilangan sesuatu yang jelas di sini. Entah itu atau kita punya sesuatu yang tidak terkonfigurasi, yang mungkin terjadi karena kami telah melakukan sejumlah panggilan ke Vendor dan MS terkait dengan lingkungan ini.
Untuk semua penyelidikan saya, saya sepertinya tidak dapat menemukan apa yang menyebabkan perbedaan kinerja ini. Saya akan berharap untuk melihat semacam menunggu yang terjadi pada node sekunder, tetapi tidak ada. Bagaimana saya bisa lebih lanjut memecahkan masalah ini untuk mengidentifikasi penyebab root? Adakah yang pernah melihat perilaku ini sebelumnya dan menemukan cara untuk menyelesaikannya?
PEMBARUAN # 1
Setelah menukar status simpul ketiga (salah satu replika Hanya Baca) menjadi tidak dapat dibaca dan kemudian kembali agar dapat dibaca sebagai tes, replika itu masih ditahan oleh transaksi terbuka, dengan pertanyaan klien yang menampilkan HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONINGTunggu.
Menjalankan DBCC OPENTRANperintah menghasilkan hasil berikut:
Oldest active transaction:
SPID (server process ID): 420s
UID (user ID) : -1
Name : QDS nested transaction
LSN : (941189:33148:8)
Start time : May 7 2019 12:54:06:753PM
SID : 0x0
DBCC execution completed. If DBCC printed error messages, contact your system administrator.Saat mencari SPID ini sp_who2, itu menunjukkan itu sebagai BACKGROUNDproses dengan QUERY STORE BACKterdaftar sebagai perintah.
Sementara kita yang mampu mengambil TLog backup, saya menduga kita berjalan ke fungsi serupa dari bug diselesaikan ini , jadi saya berencana untuk membuka tiket dengan MS tentang isu ini hari ini.
Tergantung pada hasil dari tiket itu, saya akan mencoba untuk menangkap jejak tumpukan panggilan sesuai saran Joe dan melihat ke mana kita pergi.
Pembaruan Akhir (Masalah Diselesaikan Sendiri)
Setelah melampaui tanda 52 jam dari transaksi Toko Kueri menjadi terbuka (seperti yang diidentifikasi di atas), AG memutuskan untuk secara otomatis gagal. Sebelum ini terjadi, saya melakukan beberapa metrik tambahan. Per tautan ini , yang disediakan oleh Sean, basis data yang dimaksud memiliki toko versi sangat besar yang didedikasikan untuk basis data ini, khususnya pada satu titik saya telah mencatat 1651360 halaman di reserved_page_countlapangan dan 13210880 untuk reserved_space_kbnilainya.
Per ERRORLOGs, failover terjadi setelah 5 menit banjir dari kegagalan pengerasan transaksi terkait QDS base transactiondan QDS nested transactiontransaksi.
Kegagalan itu memang menyebabkan pemadaman sekitar 10 menit dalam kasus saya. Basis data ~ 6TB dalam ukuran dan sangat aktif, jadi itu sebenarnya cukup bagus menurut saya. Sementara simpul utama baru sedang online selama waktu ini, tidak ada permintaan klien dapat menyelesaikan karena mereka semua menunggu pada QDS_LOADDBjenis tunggu.
Setelah failover, nomor versi toko dikurangi menjadi 176 untuk reserved_page_countdan 1408 untuk reserved_space_kb. Pertanyaan terhadap Replika Hanya-Baca Sekunder juga mulai mengeksekusi secepat jika dijalankan dari primary, sehingga kelihatannya perilaku tersebut sepenuhnya hilang, sebagai akibat dari failover.
QDS_LOADDB- jika Anda ingin menghindarinya di masa mendatang, tetapi tetap tetap menggunakan Query Store, Anda dapat menggunakan tanda jejak ini yang direkomendasikan oleh Microsoft. Secara khusus 7752 akan memungkinkan kueri mengeksekusi sebelum Query Store telah diinisialisasi (sehingga Anda mungkin melewatkan beberapa kueri, tetapi basis data Anda akan naik).
7752terlihat sangat berguna. Terima kasih atas tipnya!