SQL Errorlog Sabit FlushCache Mesajları

Sep 04 2020

SQL 2017 Always on availability grubunun (BAG) parçası olan bir sunucu Bu mesajlarda artış olduğunu fark ettim. Bunların 2012'den beri standart olarak günlükte görünen mesajlar olduğunu anlıyorum (2012'den önceki izleme bayrağı) ancak son 2 günde birkaç dakikada bir görüntüleniyorlar, bu zamanlarda çalışan yedekleme veya bakım işleri yok

Sunucu, ikincil okunamayan yük devretme ortağı gibi davranıyor ve birincil sunucu aynı davranışı sergilemiyor.

09/04/2020 10: 52: 24, spid82s, Bilinmeyen, FlushCache: db 7: 0 09/04/2020 10:52:07 için 81090 ms'de 1881 yazma ile 2303 bufs temizlendi (11 yeni kirli bufs önlendi), spid52s, Bilinmeyen, bekleyen son hedef: 2 avgWriteLatency 86 09/04/2020 10: 52: 07, spid52s, Bilinmeyen, saniyede ortalama yazma: 17,70 yazma / sn ortalama verim: 0,19 MB / sn G / Ç doygunluğu: 13073 bağlam anahtarları 15434

Sistem hata günlüğünde disk sorunuyla ilgili bir uyarı da vardır, bundan saniyeler sonra FlushCache mesajları arttığından beri kullanılabilirlik grubu devre dışı kalır.

Herhangi biri benzer bir şey deneyimlediğinde veya herhangi bir tavsiyede bulunduğunda, benim sistem yöneticim SAN ve VMware mülküne de bakıyor.

Ani bir düşünce, bunların otomatik büyüme faaliyetlerinden kaynaklanabileceğini düşünmüş müydü?

Yanıtlar

4 AaronBertrand Sep 04 2020 at 10:05

Dolaylı denetim noktalarına geçin (genellikle, kurtarma aralığı süresini en azından kullanıcı veritabanları için 60 saniyeye ayarlayın).

Bu konu hakkında burada ve burada yazdım ve değişikliği yapmadan önce bu yayınları tam olarak okumalısınız, ancak bu hemen hemen hiç akıllıca olmayan bir IMHO.

Çevremizdeki etki şiddetli ve ani oldu ve değişikliğin sorumlu olduğunu kanıtlamak basitti. Semptom içeren her veritabanı 30-60 saniyelik kontrol noktalarından ve bu mesajlarla dolu hata günlüklerinden saniyenin altındaki kontrol noktalarına gitti ve daha fazla hata günlüğü girişi yoktu.

Muhtemelen iş yükünüz için de hafifletme teknikleri vardır, örneğin Itzik Ben-Gan'ın bu yazısına bakın, ancak kontrol noktalarını daha verimli hale getirmek daha hızlı ve daha kolay bir yoldur. Ancak depolama alanınız ve sanal makine çalışanlarınız çengelden uzak değil; kesinlikle ele almaları gereken bir disk sorunu var (ancak bu FlushCache mesajlarının herhangi bir yük devretmenin temel nedeni olduğuna katılmıyorum ; daha büyük olasılıkla sadece farklı bir kurban / belirti).

3 DanCo Sep 04 2020 at 10:22

Yakın zamanda herhangi bir sabit yazılım güncellemesi olup olmadığını veya depolama altsisteminizin daha yeni bir ürün yazılımı güncellemesine ihtiyaç duyup duymadığını depolama yöneticinize danışın. Bu mesajları birçok kez SQL ortamında gördüm ve bakabileceğiniz bir şey de depolama katmanı yapılandırmasıdır (ortak neden budur). Ayrıca, perfmon kullanarak disk performansınızı izlemek için bir şey. Disk sayaçları odaklanmak gerekir: avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.

Aşağıdaki linke bakabilirsiniz:

  1. Nasıl Çalışır: FlushCache mesajı SQL Server Hata Günlüğüne ne zaman eklenir?
  2. https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038

Depolama katmanı dediğimde, şunları kontrol edin: HBA / CNA, Fiber Kablo, FC Anahtarı, Bağlantı Noktaları, Depolama denetleyicisi, Yazılım (MPIO sürücüleri) - tüm yapılandırması

Son olarak, olay günlüklerinizdeki uyarıları / hata mesajlarını her zaman kontrol etmenizi ve araştırmanızı şiddetle tavsiye ederim. Geçmesine izin VERMEYİN çünkü bu tür mesajların uzun vadeli sonuçları vardır.