SQL Server Error Log veya Windows Event Viewer üzerinde sıkça karşınıza çıkan “Buffer Pool scan took X seconds: database ID X, command ‘DB STARTUP’, operation ‘FlushCache’…” uyarısı, teknik olarak bir “hata” değil, bir bilgilendirme (information) mesajıdır. Ancak bu mesajların sıklaşması, sistemde performans darboğazlarına işaret edebilir.
Buffer Pool scan took 13 seconds: database ID 140, command ‘DB STARTUP’, operation ‘FlushCache’, scanned buffers 11586451, total iterated buffers 232646231, wait time 1927 ms. See ‘https://go.microsoft.com/fwlink/?linkid=2132602’ for more information.
SQL Server; veritabanı yedeği alma, veritabanını startup, dosya silme veya CHECKPOINT gibi işlemler sırasında Buffer Pool’daki (RAM üzerindeki veri önbelleği) ilgili sayfaları taramak veya temizlemek (FlushCache) zorundadır.
Eğer sunucunuzda RAM miktarı çok yüksekse (örneğin 256 GB+) ve Buffer Pool çok büyükse, SQL Server’ın bu devasa bellek alanını taraması bazen 1 saniyeden uzun sürer. SQL Server 2016 SP2 ve sonraki sürümlerde, bu tarama işlemi 1 saniyeyi geçtiği anda bunu bir log mesajı olarak kaydeder.
total iterated buffers 232646231 ifadesi, yaklaşık 1.7 TB civarında devasa bir Buffer Pool alanının tarandığını gösteriyor. Bu kadar büyük bir alanı taramak doğal olarak zaman alıyor.
Aşağıdaki senaryolar veritabanını kapatıp açarak bu logları tetikler:
- Veritabanı Yedekleme Yazılımları (Veeam, Commvault vb.): Bazı yedekleme araçları, “Snapshot” alırken veritabanını kısa süreliğine dondurur veya tutarlılık kontrolü için FLUSHCACHE tetikler.
- Always On / Mirroring Geçişleri: Eğer bir “Failover” durumu veya senkronizasyon kesintisi oluyorsa veritabanı sürekli “Startup” moduna girer.
- Memory Pressure (Bellek Baskısı): Eğer sunucuda SQL Server dışında çalışan (IIS, Antivirüs, Monitoring) bir uygulama anlık olarak çok yüksek RAM tüketirse, SQL Server Buffer Pool’u daraltmaya çalışır (Shrink). Bu da tarama işlemlerini tetikleyebilir.
- Ayrıcalıklı Komutlar: Bir kullanıcı veya script ALTER DATABASE … SET ONLINE/OFFLINE komutu çalıştırıyorsa bu mesaj kaçınılmazdır.
Bu Mesajların Loglara Düşmesini Engellemek İçin Ne Yapmalı?
Bu mesajlar bir semptomdur. Onları durdurmak için aşağıdaki adımları izleyebilirsiniz:
1. “Auto Close” Özelliğini Kapatın (En Önemli Adım)
Eğer bu mesajları veritabanı bazlı (“DB STARTUP”) görüyorsanız, ilgili veritabanlarının “Auto Close” özelliği True olabilir. Bu özellik, son kullanıcı bağlantısı kesildiğinde veritabanını kapatır; yeni biri bağlandığında ise tekrar açar. Her açılışta da loglara bu mesaj düşer.
- Tüm veritabanları için bu özelliği False yapın.
ALTER DATABASE [VeritabaniAdiniz] SET AUTO_CLOSE OFF;2. Trace Flag 815 Kullanın
Microsoft, bu bilgilendirme mesajlarının logları kirletmesini engellemek için bir “Trace Flag” (izleme bayrağı) sunmuştur.
- SQL Server başlangıç parametrelerine -T815 parametresini ekleyerek bu mesajların yazılmasını devre dışı bırakabilirsiniz. (Not: Bu sadece mesajın yazılmasını engeller, tarama işlemini hızlandırmaz.)
Bu kadar büyük bir bellekte tarama süresini (11-19 saniye) kısaltmanın yolu logu kapatmak değil, taramayı hızlandırmaktır. Görünmesi istenmiyorsa kullanılır.
3. SQL Server Versiyonunu Güncelleyin
Eski SQL Server 2017 veya 2019 sürümlerinde bu tarama işlemi tek izlekli (single-threaded) yapılıyordu. Microsoft, SQL Server 2022 ve bazı toplu güncellemelerde (CU) bu tarama işlemini paralel (multi-threaded) hale getirerek süreyi kısalttı.
- Mevcut SQL Server sürümünüz için en son Cumulative Update (CU) paketini yükleyin.
Microsoft, SQL Server 2022 ile birlikte bu sorunu kökten çözen “Parallel Buffer Pool Scan” özelliğini getirdi.
- SQL 2017 ve 2019’da: Bu tarama tek bir CPU çekirdeği ile yapılır (Seri). 1.7 TB RAM’i tek çekirdekle taramak 15 saniye sürer.
- SQL 2022’de: Bu tarama tüm çekirdeklerle paralel yapılır. 15 saniyelik işlem 1 saniyenin altına iner ve log oluşmaz.
4. “Indirect Checkpoint” Ayarını Kontrol Edin
Mesajlarda operation ‘FlushCache’ ve command ‘CHECKPOINT’ ifadelerini görüyorsanız, sistem checkpoint işlemleri sırasında zorlanıyor demektir.
- Veritabanı seviyesinde TARGET_RECOVERY_TIME ayarını 60 saniye olarak ayarlamak, bu yükü daha zamana yayarak hafifletebilir.
Bu mesajlar sunucunuzun çökmesine neden olmaz, ancak 11-19 saniye gibi süreler (sizin loglarınız’da görünen) o esnada veritabanı işlemlerinin kısa süreliğine duraklamasına (freeze) neden olabilir. Öncelikle Auto Close ayarını kontrol etmenizi, ardından Trace Flag 815‘i değerlendire bilirsiniz.
Başka makalede görüşmek dileğiyle..
“…Sakın Dünya Hayatı Sizi Aldatmasın” Fatır-5
