SQL Server performans ani bozulması


13

Geç tahmin edilemeyen bir SQL Server 2005 var ve neden olarak başımı kaşıyorum. Saniyeler içinde yürütülen sorgular planları değiştirir ve dakikalar alır (tam tablo taraması veya dizin biriktirmesinde zaman alır). Şimdi ilk ve en belirgin şey, istatistiklerin optimize edicinin kafasını karıştırmasına neden olduğu, ancak bunun böyle olmadığına ikna oldum - öncelikle altta yatan veriler önemli ölçüde değişmediği için (örn. Bir yıllık verilerin üstüne bir günlük veri eklemek) zaten bir tabloda) ve ikincisi de Otomatik İstatistik Oluştur ve Otomatik Güncelleme İstatistikleri doğru olduğundan. Ancak iyileştirici olduğu bocalama; Tuning Advisor içinde SQL çalıştırmak bana CREATE STATISTICSdüzeltmek gibi görünüyor çok SQL deyimleri bir sürü verir (SQL sonraki yanlış bit kadar).

Kök yaratan buna yaklaşmak için kullanabileceğim bir strateji fikri var mı? "Normal" istatistikler neden yeterli değil?

Yanıtlar:


8

En fazla beklemeniz SOS_SCHEDULER_YIELD ise, CPU üzerinde biraz baskı yaptığınız anlaşılıyor. Ancak bu, tasarımınızın sorgularınız için artık yeterli olmaması gibi başka bir şeyin sonucu olabilir. Sadece bir günlük veri eklediğinizi söylediğinizi biliyorum, ama bir devrilme noktasına çarpmış olabilirsiniz.

Sorgularınız nasıl yayınlanıyor? Dinamik SQL mi? Saklı yordamlar mı kullanıyorsunuz? Sp_executesql kullanıyor musunuz? Parametre koklama vakası olması mümkün mü? Db tasarımınız nasıl görünüyor? PK ve FK ilişkileri nelerdir?

İyi bir planın örneği var mı? İyi bir plan belirleyebiliyorsanız, sorguyu belirli bir şekilde yürütmeye zorlamak için plan kılavuzlarını kullanabilirsiniz.

Kötü giden iyi bir plana örnek verebilir misiniz?

Son olarak, Adam Machanic'ten sp_whoIsActive ( http://whoisactive.com/ ) ' in bir kopyasını alın ve çalışan sorgular hakkında daha fazla şey belirlemek için bunu kullanın. Ve sp_whoIsActive çıktısını yakalamak istiyorsanız, buraya gidin http://www.littlekendra.com/2011/02/01/whoisactive/


Ben oldukça korkunç onun şema veya SQL, parametreli sorgular (örneğin bir sürü üzerinde hiçbir kontrole sahip üçüncü parti uygulama var where col=(cast @var...)) ve @varolabilir '%'. Bir iki hafta önce miras aldım ve yerine geçene kadar temelde çalışmaya devam etmeliyim. Bağlantı için teşekkürler, bir koşuşturma vereceğim.
Gaius

Sonraki en büyük bekleme SOS_SCHEDULER_YIELDoldu CXPACKETve sp_configure "max degree of parallelism", 1- şimdilik - her iki sorunu kafasına çaldı gibi görünüyor. Teşekkürler!
Gaius

Sp_whoIsActive bağlantısı için +1
Jeff

8

Gönderen MSDN :

" Anahtar Sütunların Artan veya Azalan Şekillerinde Ekleme İşlemleri Oluşuyor Kimlik veya gerçek zamanlı zaman damgası sütunları gibi artan veya azalan anahtar sütunlarla ilgili istatistikler, sorgu optimize edicinin gerçekleştirdiğinden daha sık istatistik güncellemeleri gerektirebilir. Ekleme işlemleri, artan veya azalan sütunlara yeni değerler ekler Eklenen satır sayısı bir istatistik güncellemesini tetikleyemeyecek kadar az olabilir.İstatistikler güncel değilse ve sorgular en son eklenen satırlardan birini seçerse, mevcut istatistiklerin bu yeni değerler için önemlilik tahminleri olmayacaktır. yanlış kardinalite tahminleri ve yavaş sorgu performansı ile sonuçlanır.

Örneğin, istatistiklerin en son müşteri siparişi tarihleri ​​için kardinalite tahminlerini içerecek şekilde güncellenmemesi durumunda, en son müşteri siparişi tarihlerinden seçilen bir sorguda yanlış kardinalite tahminleri bulunur.

Bakım Sonrası İşlemler Bir tabloyu kısaltmak veya satırların büyük bir yüzdesini toplu olarak eklemek gibi veri dağıtımını değiştiren bakım prosedürlerini gerçekleştirdikten sonra istatistikleri güncellemeyi düşünün. Bu, sorgular otomatik istatistik güncellemelerini beklerken sorgu işlemede gelecekteki gecikmeleri önleyebilir. "

Sisteminizde zaman zaman "EXEC sp_updatestats" (bir süre programlanmış) kullanabilir veya tüm nesnelerde STATS_DATE işlevini kullanabilir ve istatistiklerinin son kez ne zaman güncellendiğini ve o zamandan beri çok fazla zaman olup olmadığını görebilirsiniz. İSTATİSTİK o nesne için. Deneyimlerime göre, Otomatik istatistikler etkinleştirilmiş olsa bile, otomatik güncellemeyi tetiklemeyen ekleme işlemleri nedeniyle istatistikleri zaman zaman güncellemeye zorlanıyoruz.

Kişisel kodumu eklemek için (istatistik güncellemesi için dinamik ifadeler oluşturan haftalık bir işte kullanılır):

select distinct
        'update statistics [' + stats.SchemaName + '].[' + stats.TableName + ']'
            + case when stats.RowCnt > 50000 then ' with sample 30 percent;'
            else 
                ';' end
        as UpdateStatement
    from (
        select
            ss.name SchemaName,
            so.name TableName,
            so.id ObjectId,
            st.name AS StatsName, 
            STATS_DATE(st.object_id, st.stats_id) AS LastStatisticsUpdateDate
            , si.RowModCtr
            , (select case si2.RowCnt when 0 then 1 else si2.RowCnt end from sysindexes si2 where si2.id = si.id and si2.indid in (0,1)) RowCnt
        from sys.stats st
            join sysindexes si on st.object_id = si.id and st.stats_id = si.indid
            join sysobjects so on so.id = si.id and so.xtype = 'U' --user table
            join sys.schemas ss on ss.schema_id = so.uid
    ) stats
    where cast(stats.RowModCtr as float)/cast(stats.RowCnt as FLOAT)*100 >= 10 --more than 10% of the rows have changed
    or ( --update statistics that were not updated for more than 3 months (and rows no > 0)
        datediff(month, stats.LastStatisticsUpdateDate, getdate()) >= 3
        and stats.RowCnt > 0
    )

Burada, istatistiklerin 3 aydan daha uzun süre güncellenmediği veya son istatistik güncellemesinden bu yana satırların% 10'undan fazlasının değiştiği tüm nesneleri alıyorum.


Hmm, benim en iyi bekleme olayım, SOS_SCHEDULER_YIELDancak şu anda kötü planlardan mı kaynaklandığını veya bu (6 yaşındaki, 2 işlemcili, 4G RAM) kutusunun şimdi aşırı yüklendiğini söyleyemem ve şimdi bir devrilme noktasının üzerine çıktı.
Gaius

UPDATE deyimlerini yapmak ve bunları manuel olarak çalıştırmak için bu sorguyu çalıştırmak yerine, sp_executesql çağrılarını kullanarak onları çalıştıran sonuçları döngüye sokmak için bu select deyimini temel alan bir imleç kullanabilirsiniz - bu şekilde otomatik olarak çalıştırabilirsiniz (örneğin bir parça olarak) bir gece (veya başka bir sessiz dönem) bakım planı).
David Spillett

@David: Haftalık işte yaptığım şey bu :). Gaius'un kullandığım çıktıyı görmesi için farklı biçimlendirdim. İlk senaryo çok çirkin ve uzundu. Biçimlendirme konusunda yardım için teşekkürler! Beni bir biçimlendirme öğretici gönderebilir misin ... çünkü burada kod güzel görünmesini nasıl gerçekten bilmiyorum. Teşekkürler!
Marian

"yanıtı düzenle" ekranında bir "biçimlendirme yardımı" bağlantısı vardır ve ana soru sayfasındaki ilk yanıt kutusunun sağında, bu siteler tarafından desteklenen işaretleme sözdizimini listeleyen bir simge olarak bulunur.
David Spillett

3
Otomatik güncelleme istatistikleri aslında% 10 değil,% 20 + 500 satırda tetiklenir.
mrdenny

3

Tahminimce, bir veya daha fazla tablonuz, Otomatik Güncelleme İstatistikleri devreye girecek ve yine de yeterli güncelleme (veya eklemeler olacak şekilde) mevcut istatistikleri eski olarak işaretlemeye yardımcı olmak için gereken değişikliklerin% 20'sini vurmayacak kadar büyüyor. ) güncellenmiş istatistiklere sahip olmanın çok yardımcı olacağını unutmayın. Aynı şeyi son zamanlarda belirli bir ortamda SQL 2000'den SQL 2008'e yükselttikten sonra buldum.

Yukarıdaki yanıtlarda belirtilen diğer sitelere ek olarak, aşağıdaki çevrimiçi kaynaklara göz atmanızı öneririm.

1) Red-Gate, aşağıdaki alıntıyı bulabileceğiniz Holger Schmeling'in "SQL Server İstatistikleri" dahil olmak üzere indirebileceğiniz bir dizi ücretsiz e-kitaba sahiptir:

http://www.red-gate.com/our-company/about/book-store/

"500'den fazla satırı olan tablolar, bağlantılı istatistikleri geçersiz kılmak için bir sütunun verilerinin en az% 20'sinin değiştirilmesi gerekti"

2) SQL Sentry, bir sorgudaki belirli bir tablo için gerçek satır sayısına kıyasla çok fazla veya çok az satır tahmini gibi bir SQL planındaki sorunları izlemeye yardımcı olan ücretsiz bir Plan Explorer aracına sahiptir. Gerçek yürütme planını SSMS'den kaydedin ve Plan Gezgini'ni kullanarak planın farklı bölümlerini gözden geçirin. Bilgi, grafik yürütme planını kullanarak SSMS'de mevcut değildir, ancak SQL Sentry'deki araç görmeyi çok kolaylaştırır.

http://www.sqlsentry.com/plan-explorer/sql-server-query-view.asp

3) STATS_DATE () kullanarak en çok ilgilendiğiniz sorgulardaki tablolar için istatistik güncelleme tarihini kendiniz kontrol edin, aşağıdaki tartışmada bulunan bir sorguyu kullanarak en eski istatistikleri almak için hızlı bir sorgu bulabilirsiniz.

http://blog.sqlauthority.com/2010/01/25/sql-server-find-statistics-update-date-update-statistics/

Umarım bu yardımcı olur!

Sanırım özellikle Kırmızı Kapı'dan kitabın tadını çıkaracaksınız!

-Jeff


Teşekkürler, bunlardan geçeceğim. Ben esas olarak bu sistemi devralmış bir Oracle DBA'yım (SQL Server'a karşı hiç önyargılı değilim, 2005'ten beri gördüğüm kadarıyla çok yetenekli bir platform, sadece Oracle'ı bildiğim kadar iyi bilmiyorum) .
Gaius
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.