Tuhaf HADR_SYNC_COMMIT vakası beklemektedir

HADR_SYNC_COMMITÇevremizdeki beklemeler için ilginç bir model görüyoruz. Üç kopyamız var; bir birincil, bir senkronizasyon ikincil ve bir asenkron ikincil veri merkezinde ve başka bir veri merkezine üç tane daha ASYNC kopyası ekledik (~ 2400 mil arayla).

O zamandan beri, HADR_SYNC_COMMITbeklemelerde büyük bir artış fark etmeye başladık . Aktif oturumlara baktığımızda COMMIT TRANSACTION, SYNC kopyasında bekleyen bir grup sorgu görüyoruz

Ekran görüntüsünde, HADR_SYNC_COMMIT29 Haziran'da beklemede bir sıçrama olduğunu açıkça görebiliriz ve sonunda 1 Temmuz öğleden sonra uzak veri merkezindeki üç eşzamansız kopyadan 'ikisini' düşürdük. Bu bekleme süreleri ile birlikte önemli ölçüde düştü.

Şimdiye kadar kontrol ettiklerimiz - Uzak kopyalarda günlük gönderme kuyruğu, Yinele kuyruğu, son sertleştirme süresi ve son işleme süresi. Çalışma saatlerinde sürekli küçük işlem patlamaları yaşıyoruz ve bu nedenle gönderme kuyrukları belirli bir zaman damgasında (60KB ile 1MB arasında herhangi bir yerde) oldukça küçük.
Uzak kopyalar neredeyse senkronize, kopyalarda herhangi bir bireysel lsn için son kesinleştirme zamanı ve son sertleştirme zamanı arasında çok az fark var.

Ağ borusu 10G'dir ve iletim tamponu boyutunu 256 meg'den 2 konsere değiştirdik, bu, ağın paketleri bırakıp yeniden ilettiği varsayımı altında yapıldı; her iki şekilde de çok yardımcı olmadı.

Peki, ASYNC kopyalarının HADR_SYNC_COMMITbekleme ile ne ilgisi olduğunu merak ediyorum ? SYNC kopyası tek başına bu bekleme türüne bağlı olmamalı mı , burada ne eksik?

Öncelikle sorunuzun ilgili beklediği olayın açıklaması şöyledir:

Günlüğü sertleştirmek için eşitlenmiş ikincil veritabanları için işlem tamamlama işleminin beklenmesi. Bu bekleme ayrıca İşlem Gecikmesi performans sayacı tarafından da yansıtılır. Bu bekleme türü senkronize kullanılabilirlik grupları için beklenir ve ikincil veritabanlarına günlük gönderme, yazma ve onaylama zamanını gösterir.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Bu bekleme mekaniğine kazarken, günlük blokları iletilir ve sertleştirilir, ancak uzak sunucularda kurtarma tamamlanmaz. Bu durumda ve ek kopyalar eklediğiniz göz önüne alındığında, bant genişliği gereksinimlerindeki artış nedeniyle HADR_SYNC_COMMIT'inizin artabileceği anlamına gelir. Bu durumda Aaron Bertrand, soru hakkındaki yorumlarında tam olarak doğrudur.

Kaynak: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Bu beklemenin uygulama yavaşlamaları ile nasıl ilişkili olabileceği konusunda sorunuzun ikinci bölümünü incelemek. Bu bir nedensellik sorunu olduğuna inanıyorum. Bekleme sürelerinize ve son kullanıcı şikayetlerine bakıyorsunuz ve potansiyel olarak yanlış bir şekilde sonuca varıyorsunuz. Tempdb dosyaları eklediğiniz ve uygulamanızın bana daha duyarlı hale geldiği gerçeği, bir veritabanı kullanılabilirlik grubunda olduğunda örtük anlık görüntü yalıtım düzeyi ek yükünün ek yükü tarafından daha da kötüleşmiş olabilecek bazı çekişme sorunlarınız olabileceğini gösterir. Bunun HADR_SYNC_COMMIT beklemelerinizle çok az ilgisi olabilir.

Bunu test etmek isterseniz, birincil çoğaltmanızdaki hadr_db_commit_mgr_update_harden XEvent'e bakan genişletilmiş bir olay izinden faydalanabilir ve temel alabilirsiniz. Taban çizginize sahip olduğunuzda, kopyalarınızı teker teker geri ekleyebilir ve izlemenin nasıl değiştiğini görebilirsiniz. Herhangi bir veritabanı içermeyen bir birimde bulunan ve bir rollover ve maksimum boyut ayarlayan bir dosyayı kullanmanızı şiddetle tavsiye ederim. Bekleme sürenizle eşleşen etkinlikleri toplamak için lütfen süre filtresini gerektiği şekilde ayarlayın, böylece bu sorunu daha ayrıntılı bir şekilde giderebilir ve dahil edilmesi gereken diğer ekiplerle ilişkilendirebilirsiniz.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO