SET ARITHABORT ON neden bir sorguyu önemli ölçüde hızlandırıyor?

Sorgu, çok fazla gruplama düzeyi ve toplama işlemi içeren tek bir seçimdir. SET ARITHABORT ON ile bir saniyeden daha az sürer, aksi takdirde birkaç dakika sürer. Bu davranışı SQL Server 2000 ve 2008'de gördük.

Biraz tarihli, ama benzer bir problemle buraya gelen herkes için ...

Ben de aynı problemi yaşadım. Benim için ilk başta umursamayacak kadar anlamadığım parametre koklama oldu. Sorunu çözen bir 'set arithabort' ekledim ama sonra geri geldi. Sonra okudum:

http://www.sommarskog.se/query-plan-mysteries.html

Her şeyi temizledi. Linq'i SQL'e kullandığımdan ve sorunu çözmek için sınırlı seçeneklere sahip olduğum için istediğim sorgu planını zorlamak için bir sorgu planı kılavuzu (bağlantının sonuna bakın) kullandım.

.NET uygulamaları varsayılan olarak devre dışı bırakılmış seçeneğiyle bağlanır, ancak Management Studio'da varsayılan olarak etkindir. Sonuç olarak, sunucu aslında / çoğu prosedür için 2 ayrı yürütme planını önbelleğe alır. Bu, sunucunun sayısal hesaplamaları nasıl yaptığını etkiler ve bu sayede işleme bağlı olarak çılgınca farklı sonuçlar alabilirsiniz. Bu gerçekten, bir proc'un korkunç bir yürütme planından beslenmesinin genel yollarından sadece biri, diğeri parametre koklama oluyor.

Bir göz atın https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance. Bunun üzerine biraz daha tartışma için aspx .

Bunun neredeyse kesinlikle parametre koklama olduğunu iddia ediyorum.

SET OPTIONSPerformansı bu şekilde etkileyebileceği sıklıkla belirtilir, ancak indekslenmiş Görünümler / kalıcı hesaplanmış sütunlar kullandığınız durumlar dışında, bu talep için henüz tek bir yetkili kaynak görmedim.

Bu durumda (SQL2005 + için ve veritabanınız SQL2000 uyumluluk modunda değilse ). Eğer her ikisi de varsa ARITHABORTve ANSI_WARNINGS OFFo zaman bu kadar aramaya istenen ziyade muayene edecektir kullanılmayan endeksi bulacaksınız (ve kalıcı hesaplama sonucunda bazı yükü kullanılamaz). ADO.NET ANSI_WARNINGS ONaz önce yaptığım hızlı bir testten geçiyor gibi görünüyor .

Ben'in cevabındaki iddiası , "sunucunun nümerik hesaplamaları yapma şekli" nin sonucuna dakikalar ekleyebileceği iddiası , aksi halde bir saniyeden daha kısa sürecek, benim için güvenilir gözükmüyor. Bence olan, performans performans sorununu araştırırken, rahatsız edici sorguyu belirlemek için Profiler’in kullanıldığını düşünüyorum. Bu, yönetim stüdyosuna yapıştırılır ve anında sonuçları döndürür. Bağlantılar arasındaki tek belirgin fark, ARITH_ABORTseçenektir.

Bir yönetim stüdyosu penceresindeki hızlı bir test, ne zaman SET ARITHABORT OFFaçıldığını ve sorgunun çalıştırıldığını ve performans sorununun tekrarlandığını ve böylece görünüşte dava kapandığını göstermektedir. Aslında bu, Gregg Stark bağlantısında kullanılan sorun giderme metodolojisi gibi görünüyor .

Ancak, bu seçenek kümesiyle , önbellekten aynı kötü planı almanızın mümkün olamayacağı gerçeğini görmezden gelir .

Bu plan yeniden kullanımı, uygulama bağlantısının kullandığından farklı bir kullanıcı olarak giriş yapmış olsanız bile gerçekleşebilir.

Bunu önce bir web uygulamasından, ardından yönetim stüdyosundan bir test sorgusu uygulayarak test SET ARITHABORT OFFettim ve aşağıdaki sorgudan çıkan kullanım sayılarını görebildim.

SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 

Bu paylaşım için pf planlarının gerçekleşmesi için tüm plan önbellek anahtarları aynı olmalıdır. arithabortKendisinin yanı sıra, bazı diğer örnekler, yürütme kullanıcılarının aynı varsayılan şemaya (sorgu gizli ad çözümlemesine dayanıyorsa) ve bağlantıların da aynı languagekümeye gereksinim duyması durumundadır .

Plan önbellek anahtarlarının daha dolu bir listesi burada

Bu partiye geç kaldığımı biliyorum, ama gelecekteki ziyaretçiler için Martin kesinlikle haklı. Aynı sorunla karşılaştık - SP istemcileri için hızlı bir şekilde çalışıyordu. Sorunu araştırırken ve çözerken, Kenny Evitt'in Martin sorusuna yaptığı yorumda sorduğu sistematik testler yaptık.

Martin sorgusunun bir değişkenini kullanarak, prosedür önbelleğinde SP'yi aradım ve ikisini buldum. Planlara baktığımızda, aslında birinin ARITHABORT ON, birinin ise ARITHABORT OFF olduğu ortaya çıktı. ARITHABORT OFF sürümü bir dizin aramaya sahipken, ARITHABORT ON sürümü aynı çıktı için bir dizin taraması kullandı. İlgili parametreler göz önüne alındığında, endeks aramak çıktı için on milyonlarca kaydın aranmasını gerektirecekti.

İki prosedürü önbellekten temizledim ve .NET istemcisinin SP'yi yeniden çalıştırmasını sağladım, aynı parametreleri kullandım (bu da çok sayıda etkinliği olan bir müşteri için geniş bir tarih aralığı içeriyordu). SP anında geri döndü. Önbelleğe alınmış plan, daha önce ARITHABORT ON planında öne sürülen aynı endeks taramasını kullandı - ancak bu kez plan ARITHABORT OFF içindi. SP'yi SSMS'de aynı parametrelerle çalıştırdık ve anında anında sonuç aldık. Şimdi ikinci bir planın, ARITHABORT ON için dizin taraması ile önbelleğe alındığını gördük.

Daha sonra önbelleği temizledik, SP'yi SSMS'de dar bir tarih aralığında çalıştırdık ve anında sonuç aldık. Ortaya çıkan önbelleğe alınmış planın bir indeks arayışı içerdiğini gördük, çünkü aynı çıktı daha önce bir tarama ile gerçekleştirildi (bu aynı zamanda ARITHABORT OFF ile orijinal plandaki bir arayış). Yine SSMS'den SP'yi bu kez aynı geniş tarih aralığına koştuk ve orijinal .NET isteğindeki korkunç performansı gördük.

Kısacası, eşitsizlik, ARITHABORT'un asıl değeri ile ilgisi yoktu - onunla ya da kapalıyken, her iki müşteriden de kabul edilebilir ya da korkunç bir performans elde edebileceğiz: Önemli olan, planın derlenmesinde ve saklanmasında kullanılan parametre değerleri idi.

İken MSDN ARITHABORT KAPALI kendisi sorgu optimizasyonu üzerinde olumsuz bir etkisi olabilir gösterir, bizim test Martin doğru olduğunu teyit - Neden parametresi koklama ve sonuçtaki planı tüm parametreleri aralıkları için optimum olmayan.

Sadece bu problem vardı. İnsanların burada söylediği gibi, kök neden, biri alt optimal olan çoklu sorgu planlarıdır. Sadece ARITHABORT'un gerçekten soruna kendi başına neden olabileceğini doğrulamak istedim (problemlerle karşılaştığım sorgu parametresinden yoksun; bu da denklemden parametrenin koklamasını alıyor).

Bu bana sql server 2008 günlerinde karşılaştığım aynı sorunu hatırlattı. Bizim durumumuzda birdenbire bir sql işinin aniden yavaşladığını gördük (genellikle birkaç saniye ve şimdi 9 dakika), işin bağlantılı bir sunucuya erişmesi gerekiyor, işin adımında ARITHABORT'u ekledik ve sorun görünüyordu. birkaç gün çözüldü ve sonra geri döndü.

Daha sonra MS desteğiyle bir bilet açtık ve ilk başta onlar da öğrenemediler ve bilet çok üst düzey bir PFE ekibine yükseltildi ve iki destek PFE bu sorunu çözmeye çalıştı.

Nihai neden, kullanıcı kimlik bilgilerinin (iş adımını çalıştırmak için), temel tabloların istatistiklerine erişememesidir (bağlantılı sunucu tarafında) ve bu nedenle yürütme planı optimize edilmemiştir.

Detaylı olarak, kullanıcı DBCC SHOW_STATISTICS iznine sahip değildir (kullanıcı tablodan SEÇİM yapabilir). MSDN’ye göre , bu izin kuralı 2012 SP1 sql’den sonra değiştirildi.

SQL Server ve SQL Veritabanı İzinleri

İstatistik nesnesini görüntülemek için kullanıcının tabloya sahip olması veya kullanıcının sysadmin sabit sunucu rolünün, db_owner sabit veritabanı rolünün veya db_ddladmin sabit veritabanı rolünün bir üyesi olması gerekir.

SQL Server 2012 SP1 izin kısıtlamalarını değiştirir ve SELECT izni olan kullanıcıların bu komutu kullanmalarına izin verir. SELECT izinlerinin komutu çalıştırmak için yeterli olması için aşağıdaki gereksinimlerin mevcut olduğuna dikkat edin:

Bu sorunu doğrulamak için, profilleyiciyi bağlı sunucu tarafı örneğinde çalıştırmamız ve "Hatalar ve Uyarılar" bölümündeki bazı olayları aşağıda gösterildiği gibi açmamız yeterlidir.

Umarım bu deneyim topluluğa bir şekilde yardımcı olabilir.