Her gün SQL Server yeniden oluşturma planları

Üretim ortamımızda bu sorun var.

Windows NT 6.1 üzerinde Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64 bit) (Derleme 7601: Service Pack 1).

SQL Server, eski yürütme planlarının tümünü (neredeyse% 100'ü) bırakıyor ve her gün (11: 00-8: 00 arası) her gün yeniden yaratıyor. Bu, 'otomatik güncelleme istatistikleri' devre dışı durumdayken bile oluyordu. Son 2-3 hafta boyunca 'otomatik güncelleme istatistikleri'ni açtık. Ama hala oluyor.

Bu yeniden oluşturma planlarını neyin tetiklediğini gerçekten bilmiyoruz, ancak manuel olarak yapmadığımızdan eminiz.

Rejenere edilen planların zamanlamasına gerçekten denk gelen tek şey, sahip olduğumuz bir DB bakım işidir: günlük indeks yeniden yapılanıyor (parçalanma% 5-30 olduğunda) ve günlük indeks yeniden inşası (parçalanma% 30'dan fazla olduğunda) ) iş. Genellikle bu günlük bakım işi sadece yeniden düzenlenir (endeks parçalanması asla günlük bazda% 30'dan fazla olmadığından).

Etki:

Bu yeni oluşturulan planlar bazı UDF çağrıları / sorgu çağrılarının (UI / web sayfalarından çağrılır) daha uzun sürmesini (1 saniyeden daha az dakikalar) sürmesini sağlar ve böylece oturumlar CPU'yu% 90'a yaklaştırarak birikir .

UDF'ler değiştirildiğinde (işlevler için) ilgili tüm yürütme planları manuel olarak (sorgular için) veya 2) temizlendiğinde, sıkışmış oturumlar (DB tarafında) zorla silindiğinde sorun ortadan kalkar. O andan itibaren SQL sunucusu tarafından oluşturulan yeni planlar, ertesi sabah aynı sorunu yaşayana kadar gün boyunca mükemmel çalışır. Ayrıca, bu davranış% 100 tutarlı değil, her sabah gerçekten görmüyoruz. Ancak arka arkaya 4-5 gün boyunca sürekli olarak gördüğümüz zamanlar oldu.

Sorun iş sabahlarında olur, o zaman UI / web sayfalarına daha yoğun erişilir, öyle görünüyor.

Buna neden olan ve bu sorunu nasıl çözecekleri hakkında bir fikri olan var mı? Herhangi bir yardım çok takdir edilecektir.

— peter.petrov
kaynak

plancache, makine bellek basıncı altındayken veya ayarlar ob db seviyesini değiştirdiğinizde serbest bırakılabilir. (db'yi değiştir). Onları "el ile" silmediğinizi söylediğinizden, bellek basıncı olabileceğini varsayıyorum. Makinede ne kadar bellek var? maksimum bellek ayarlarınız nedir? sanal bir ortamınız ve belki de aşırı konumlandırılmış RAM'iniz

— RayofCommand

Neden SP1'desiniz? Herhangi bir şey yapmadan önce SP3'ü uygulayın. SQL Server, bellek baskısı bulursa ve özellikle büyük tablolarınız varsa, özellikle dizin yeniden oluşturma sayfalarını barındırmak için daha fazla bellek gerekiyorsa planları zorlayabilir. Dizin yeniden oluşturma mümkün olduğunca fazla sayfa getirmeye çalışır. Yapabileceğiniz şey MP kullanmayı bırakmak ve Ola Hallengren çözümünü kullanmak ve bunun işe yarayıp yaramadığını görmek. Maksimum sunucu belleği nedir?

— Shanky

Çocuklar, ben bir DBA değilim, sadece bir SQL geliştiricisi. Tüm bunları soruyorum çünkü oldukça uzun süredir devam ediyor. Yorumlarınız için teşekkürler, şimdilik takip etmeyi zor bulsam da hepsine cevap vermeye çalışacağım (ve hepsi sizin için oldukça açık görünüyor). MP nedir?

— peter.petrov

@ peter.petrov ortamınızı tanıyarak size yardımcı olmaya çalışıyoruz. MP = Bakım Planları.

— Kin Shah

Asıl sorun, sorgu planlarınızın çok kırılgan olmasıdır. Yeniden derlemeler herhangi bir zamanda, gün içinde bile olabilir. Garanti yok. Planlarınızı kararlı hale getirmek için sorgularınızı düzeltin. SEÇENEK TAVSİYE veya BİLİNMEYEN İÇİN OPTİMİZE, uygun ve hızlı bir düzeltme olabilecek balyoz yaklaşımlarıdır.

— usr

Bu davranışa neden olabilecek bazı fikirlerim var.

Bellek basıncınızı izliyor musunuz? Sorgularınız, plan önbelleğinin temizlenmesine neden olacak belirli bir sınırı artırır. Uygulamanızı bilmiyorum, ancak bu ön uç sunucularınızdaki günlüklerinizle uyumlu mu? Bu süre zarfında da baskı var mı?
Özel bir SQL Server'ınız var mı veya sunucu donanımını diğer işlemler / hizmetlerle paylaşıyor mu? Değilse, SQL Server'ınızı özel bir makineye dış kaynak kullanmayı düşünün. Bu, diğer hizmetlerin yan etkilerini azaltacaktır.
Kullanmak isteyebilirsiniz optimize for ad hoc workloads, bu sadece bir plan saplamasını kaydeder ve gerekirse derler. Bu, plancache'inizin yükünü azaltacak ve plancache yıkama olasılığını azaltacaktır. Düğmesini kullanarak etkinleştirebilirsiniz sp_configure 'optimize for ad hoc workloads',1; reconfigure. advanced optionsKullanmayı etkinleştirdiyseniz bu yapılabilir sp_configure 'show advanced options',1; reconfigure.
Başka bir fikir de yedekleme olabilir. Sadece basit yedeklemeler. Agresif bir şekilde çalışırlarsa, makineniz de baskı altında kalabilir. Bahsettiğiniz zaman, bir yedekleme planlamak için iyi bir zaman aralığı gibi görünür.
Belki de bakım betiğinizde oldukça basit bir hata. Komut dosyanızın yalnızca ölçütlerle eşleşenler yerine tüm dizinleri yeniden oluşturmasına neden olan mantıklı bir sorun olup olmadığını kontrol ettiniz mi? Bu belki de buna neden olabilir.

Sadece bu olasılıkların hepsini yanında, bazı seçeneklere değişiklikler için günlük dosyalarını kontrol etmek faydalı olabilir affinity mask, affinity I/O maskve bunların x64 ortakları. Başka bir şey, MAXDOPörneğinizin seçeneğinin değiştirilmesi olabilir . Lütfen günlükleri de kontrol edin. Plancache'i de temizlemeleri gerekecek.

Son fakat aynı derecede önemli olarak, yine de bir serveride izlemesi çalıştırabilirsiniz (sadece profiler kullanarak kurmak, başlatmak, durdurmak ve sql komutunu kullanarak tekrar serveride başlatmak için). Bunun yanında perfmonsenin arkadaşın. Bir süre için performans değerlerinizi izleyebilir ve izleyebilir. Belki de sunucunuzda bu yıkıma neden olabilecek bazı eylemlerle basınçta paralellikler görebilirsiniz.

Umarım bu cevap biraz sonra gelse bile size yardımcı olacaktır.

— İyonik
kaynak