Kullanımda NOCOUNT AYARLA

SET NOCOUNT ile ilgili farklı görüşlerin olduğu bu sorudan esinlenilmiştir ...

SQL Server için SET NOCOUNT ON kullanmalı mıyız? Değilse, neden olmasın?

Ne yapar Düzenle 6, üzerinde 22 Tem 2011

Herhangi bir DML'den sonra "etkilenen xx satırları" iletisini bastırır. Bu bir sonuç kümesidir ve gönderildiğinde istemci bunu işlemelidir. Küçük ama ölçülebilir (aşağıdaki yanıtlara bakın)

Tetikleyiciler vb. İçin, istemci birden çok "etkilenen xx satırı" alır ve bu bazı ORM'ler, MS Access, JPA vb. İçin her türlü hataya neden olur (aşağıdaki düzenlemelere bakın)

Arka fon:

Genel kabul edilen en iyi uygulama (bu soruya kadar düşündüm) SET NOCOUNT ONSQL Server'da tetikleyiciler ve saklı yordamlarda kullanmaktır . Biz her yerde kullanmak ve hızlı bir google da kabul SQL Server MVP bol gösterir.

MSDN, bunun bir .net SQLDataAdapter bozabileceğini söylüyor .

Şimdi, bu benim için SQLDataAdapter tamamen basitçe CRUD işleme ile sınırlı olduğu için "etkilenen n satır" mesajı eşleşmesini bekliyor anlamına gelir. Bu yüzden kullanamıyorum:

• Yinelemeleri önlemek için VARSA (etkilenen satır yok mesajı) Not: dikkatli kullanın
• NEREDE VAR YOK (beklenenden daha az satır
• Önemsiz güncellemeleri filtreleyin (örn. Gerçekte hiçbir veri değişmez)
• Daha önce herhangi bir tablo erişimi yapın (günlük kaydı gibi)
• Karmaşıklığı veya denormlizasyonu gizle
• vb

Soruda (SQL öğelerini bilen) marc_s bunu kullanmadığını söylüyor. Bu düşündüğümden farklı (ve kendimi SQL'de de yetkin görüyorum).

Bir şey eksik olabilirim (bariz olanı belirtmekte özgürsün), ama orada ne düşünüyorsun?

Not: Bugünlerde SQLDataAdapter kullanmıyorum çünkü bu hatayı gördüm beri yıl oldu.

Yorum ve sorulardan sonraki düzenlemeler:

Düzenleme: Daha fazla düşünce ...

Birden çok istemcimiz var: biri C # SQLDataAdaptor kullanabilir, diğeri Java'dan nHibernate kullanabilir. Bunlar ile farklı şekillerde etkilenebilir SET NOCOUNT ON.

Depolanmış proc'ları yöntem olarak görüyorsanız, bazı dahili işlemlerin kendi amaçlarınız için belirli bir şekilde çalıştığını varsaymak kötü bir formdur (anti-desen).

Düzenleme 2: nHibernate soru kırma tetik , nerede SET NOCOUNT ONkümesi olamaz

(ve hayır, birinin kopyası değil bu )

Edit 3: MVP meslektaşım sayesinde daha fazla bilgi

• KB 240882 , SQL 2000 ve önceki sürümlerde bağlantı kesilmesine neden olan sorun
• Performans kazancı demosu

Düzenleme 4: 13 Mayıs 2011

Belirtilmediğinde Linq 2 SQL'i de kırıyor mu?

Düzenle 5: 14 Haz 2011

JPA, depolanmış proc'u tablo değişkenleriyle sonlandırır : JPA 2.0 SQL Server tablo değişkenlerini destekliyor mu?

Düzenle 6: 15 Ağu 2011

SSMS "Satırları düzenle" veri ızgarası için SET NOCOUNT ON: GROUP BY ile güncelleme tetiği

Düzenle 7: 07 Mar 2013

@RemusRusanu'dan daha ayrıntılı bilgi:
SET NOCOUNT ON gerçekten bir performans farkı yaratıyor mu?

Tamam şimdi araştırmamı yaptım, işte anlaşma:

TDS protokolünde, "SET NOCOUNT ON" metninin kendisi 14 bayt iken sorgu başınaSET NOCOUNT ON yalnızca 9 bayt kaydeder . Bunun 123 row(s) affectedsunucudan ayrı bir ağ paketinde düz metin olarak döndürüldüğünü düşünürdüm ama durum böyle değil. Aslında DONE_IN_PROCyanıtta gömülü olarak adlandırılan küçük bir yapıdır . Hiçbir gidiş-dönüş boşa harcanan ayrı bir ağ paketi değil.

Performans hakkında endişelenmeden neredeyse her zaman varsayılan sayma davranışına bağlı kalabilirsiniz. Bununla birlikte, önceden satır sayısını hesaplamanın, yalnızca ileri imleç gibi performansı etkileyeceği bazı durumlar vardır. Bu durumda NOCOUNT bir zorunluluk olabilir. Bunun dışında, "mümkün olan her yerde NOCOUNT kullan" sloganını izlemeye kesinlikle gerek yoktur.

Ortamın önemsizliği hakkında çok ayrıntılı bir analiz SET NOCOUNT: http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/

NOCOUNT civarında gerçek karşılaştırma rakamları bulmak beni çok kazdı, bu yüzden hızlı bir özet paylaşacağımı düşündüm.

• Saklı yordamınız döndürülen sonuçları olmayan çok hızlı işlemleri gerçekleştirmek için bir imleç kullanıyorsa, NOCOUNT OFF'un açık olması yaklaşık 10 kat daha uzun sürebilir. ¹ Bu en kötü senaryodur.
• Saklı yordamınız döndürülen sonuçları olmayan yalnızca tek bir hızlı işlem gerçekleştirirse, NOCOUNT ON ayarının yapılması % 3'lük bir performans artışı sağlayabilir . ² Bu, tipik bir ekleme veya güncelleme prosedürüyle tutarlı olacaktır. (Bunun neden her zaman daha hızlı olamayabileceği hakkında bazı tartışmalar için bu yanıtın yorumlarına bakın.)
• Saklı yordamınız sonuçları döndürürse (örneğin, bir şey SEÇEBİLİRSİNİZ), performans farkı sonuç kümesinin boyutuyla orantılı olarak azalacaktır.

• SET NOCOUNT ON olduğunda, sayım (bir Transact-SQL deyiminden etkilenen satır sayısını gösteren) döndürülmez. NOCOUNT AYARLA KAPALI olduğunda, sayı döndürülür. Herhangi bir SELECT, INSERT, UPDATE, DELETE deyimiyle kullanılır.

• SET NOCOUNT ayarı, ayrıştırma zamanında değil yürütme veya çalıştırma zamanında ayarlanır.

• SET NOCOUNT ON, saklı yordam (SP) performansını artırır.

• Sözdizimi: SET NOCOUNT {ON | KAPALI}

SET NOCOUNT ON örneği:

SET NOCOUNT OFF örneği:

Sanırım bir dereceye kadar DBA ve geliştirici sorunu.

Bir dev olarak, kesinlikle olumlu olmadıkça bunu kullanmayın söyleyebilirim - çünkü kullanmak ADO.NET kodunuzu kırabilir (Microsoft tarafından belgelendiği gibi).

Ve sanırım bir DBA olarak, diğer tarafta daha çok olursunuz - kullanımını gerçekten önlemeniz gerekmedikçe mümkün olduğunca kullanın.

Ayrıca, geliştiricileriniz ADO.NET'in ExecuteNonQueryyöntem çağrısı tarafından döndürülen "RecordsAffected" komutunu kullanıyorsa SET NOCOUNT ON, bu durumda herkes kullanırsa sorun yaşarsınız, ExecuteNonQuery her zaman 0 döndürür.

Ayrıca Peter Bromberg'in blog gönderisine bakın ve pozisyonuna göz atın .

Bu yüzden standartları kimin ayarlayacağına gerçekten değinir :-)

üzüm posası

Farklı istemcileriniz de olabileceğini söylüyorsanız, SET NOCOUNT AÇIK olarak ayarlanmamışsa klasik ADO ile ilgili sorunlar vardır.

Biri düzenli olarak deneyimliyorum: saklı yordam bir dizi deyimi çalıştırırsa (ve böylece bir dizi "xxx satır etkilenen" ileti döndürülürse), ADO bunu işlemiyor gibi görünüyor ve hata veriyor "Bir Recordset nesnesinin ActiveConnection özelliği değiştirilemiyor kaynağı olarak bir Komut nesnesi var. "

Bu yüzden gerçekten çok iyi bir neden olmadığı sürece AÇIK konuma getirmeyi savunuyorum . daha fazla okumak ve okumak için gerçekten iyi bir neden bulmuş olabilirsiniz.

İşleri daha karmaşık hale getirme riski altında, yukarıda gördüğüm herkes için biraz farklı bir kural teşvik ediyorum:

• Her zaman set NOCOUNT ONEğer proc herhangi bir çalışma yapmadan önce, bir proc üstündeki ama aynı zamanda her zaman SET NOCOUNT OFFsaklı yordam herhangi kayıt kümesi döndüren önce, yine.

Dolayısıyla, "gerçekten bir sonuç kümesi döndürmemeniz dışında genellikle sayılmaya devam edin". Bu herhangi bir istemci kodu kırmak için herhangi bir yol bilmiyorum, bu istemci kodu proc iç hakkında bir şey bilmeniz gerekmez anlamına gelir ve özellikle zahmetli değil.

NHibernate'i kıran tetikleyicilerle ilgili olarak, bu deneyimi ilk elden yaşadım. Temel olarak, NH bir GÜNCELLEME yaptığında, etkilenen belirli sayıda satır bekler. Tetikleyicilere SET NOCOUNT ON ekleyerek, NH'nin beklediği satır sayısını geri alırsınız ve böylece sorunu çözersiniz. Yani evet, NH kullanıyorsanız kesinlikle tetikleyiciler için kapatılmasını tavsiye ederim.

SP'lerde kullanım ile ilgili olarak, bu kişisel tercih meselesidir. Her zaman satır sayımını kapatmıştım, ama yine de, her iki şekilde de gerçek güçlü argümanlar yok.

Farklı bir notta, SP tabanlı mimariden gerçekten uzaklaşmayı düşünmelisiniz, o zaman bu soruya bile sahip olmayacaksınız.

'SET NOCOUNT ON' öğesinin bir ağ paketi veya gidiş dönüş kaydetmediğini doğrulamak istedim

Başka bir ana bilgisayarda test SQLServer 2017 kullandım (VM kullandım) create table ttable1 (n int); insert into ttable1 values (1),(2),(3),(4),(5),(6),(7) go create procedure procNoCount as begin set nocount on update ttable1 set n=10-n end create procedure procNormal as begin update ttable1 set n=10-n end Sonra 1433 numaralı bağlantı noktasındaki paketleri 'Wireshark' aracıyla izledim: 'yakalama filtresi' düğmesi -> 'bağlantı noktası 1433'

exec procNoCount

bu yanıt paketidir: 0000 00 50 56 c0 00 08 00 0c 29 31 3f 75 08 00 45 00 0010 00 42 d0 ce 40 00 40 06 84 0d c0 a8 32 88 c0 a8 0020 32 01 05 99 fe a5 91 49 e5 9c be fb 85 01 50 18 0030 02 b4 e6 0e 00 00 04 01 00 1a 00 35 01 00 79 00 0040 00 00 00 fe 00 00 e0 00 00 00 00 00 00 00 00 00

exec procNormal

bu yanıt paketidir: 0000 00 50 56 c0 00 08 00 0c 29 31 3f 75 08 00 45 00 0010 00 4f d0 ea 40 00 40 06 83 e4 c0 a8 32 88 c0 a8 0020 32 01 05 99 fe a5 91 49 e8 b1 be fb 8a 35 50 18 0030 03 02 e6 1b 00 00 04 01 00 27 00 35 01 00 ff 11 0040 00 c5 00 07 00 00 00 00 00 00 00 79 00 00 00 00 0050 fe 00 00 e0 00 00 00 00 00 00 00 00 00

40 satırında, 'etkilenen satır sayısı' olan '07' değerini görebiliyorum. Yanıt paketine dahil edilmiştir. Ekstra paket yok.

Bununla birlikte, kaydedilebilecek 13 ekstra bayta sahiptir, ancak sütun adlarını azaltmaktan daha fazla değmez (örn. 'ManagingDepartment' '' MD ')

Performans için kullanmak için hiçbir neden göremiyorum

AMA Diğerleri belirtildiği gibi ADO.NET kırabilir ve ben de python kullanarak bir sorun üzerinde tökezledi: MSSQL2008 - Pyodbc - Önceki SQL bir sorgu değildi

Muhtemelen hala iyi bir alışkanlık ...

SET NOCOUNT ON;

Bu kod satırı, sorgunun yürütülmesinden etkilenen sayı satırlarını döndürmemek için SQL'de kullanılır. Etkilenen satır sayısına ihtiyaç duymazsak, bunu bellek kullanımını kaydetmeye ve sorgunun yürütme hızını artırmaya yardımcı olacağından kullanabiliriz.

NOCOUNT'u AÇIN; Yukarıdaki kod, DML / DDL komut yürütüldükten sonra sql sunucu motoru tarafından ön sonuç penceresine oluşturulan mesajı durduracaktır.

Neden yapıyoruz? SQL sunucu motoru durumu almak ve iletiyi oluşturmak için bazı kaynaklar aldığından, Sql sunucu motoruna aşırı yük olarak kabul edilir.

SET NOCOUNT ONGerçekten yardımcı olabilecek bir yer, bir döngü veya imleçte sorgular yaptığınız yerdir. Bu, çok fazla ağ trafiği ekleyebilir.

CREATE PROCEDURE NoCountOn
AS
set nocount on
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO


CREATE PROCEDURE NoCountOff
AS
set nocount off
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO

SSMS'de istemci istatistiklerini açma, bir dizi EXEC NoCountOnve EXEC NoCountOffNoCountOff birinde fazladan 390KB trafik olduğunu gösterir:

Muhtemelen bir döngüde veya imleçte sorgu yapmak için ideal değil, ama ideal dünyada da yaşamıyoruz :)

Oldukça eski bir soru olduğunu biliyorum. sadece güncelleme için.

"SET NOCOUNT ON" kullanmanın en iyi yolu, SP'nizde ilk ifade olarak kullanmak ve son SELECT deyiminden hemen önce tekrar KAPALI duruma getirmektir.

SET NOCOUNT ON bile aşağıdaki gibi etkilenen satırlara erişmenize izin verir:

SET NOCOUNT ON

DECLARE @test TABLE (ID int)

INSERT INTO @test
VALUES (1),(2),(3)

DECLARE @affectedRows int = -99  

DELETE top (1)
  FROM @test
SET @affectedRows = @@rowcount

SELECT @affectedRows as affectedRows

Sonuçlar

affectedRows

1

Mesajlar

Komutlar başarıyla tamamlandı.

Tamamlanma süresi: 2020-06-18T16: 20: 16.9686874 + 02: 00

Ben istemci ve SQL arasında SET NOCOUNT ON test nasıl bilmiyorum, bu yüzden diğer SET komutu "SET İŞLEM İZOLASYON SEVİYESİ OKU UNCIMMITTED" için benzer bir davranış test

Bağlantımdan SQL'in (Davranışı OKUYUN) varsayılan davranışını değiştiren bir komut gönderdim ve sonraki komutlar için değiştirildi. Saklı bir yordam içindeki İZOLASYON düzeyini değiştirdiğimde, sonraki komutun bağlantı davranışını değiştirmedi.

Mevcut sonuç,

1. Saklı yordam içindeki ayarları değiştirmek, bağlantı varsayılan ayarlarını değiştirmez.
2. ADOCOnnection kullanarak komut göndererek ayarın değiştirilmesi, varsayılan davranışı değiştirir.

Bunun "SET NOCOUNT ON" gibi diğer SET komutlarıyla ilgili olduğunu düşünüyorum

if (sayım yok == kapalı)

{o zaman etkilenen kaç kaydın verilerini tutacaktır, bu nedenle performansı azaltın} else {değişikliklerin kaydını izlemeyecek ve dolayısıyla performansı iyileştirecektir}}

Bazen en basit şeyler bile fark yaratabilir. Her saklı yordamın bir parçası olması gereken bu basit öğelerden biri SET NOCOUNT ON. Saklı yordamın en üstüne konan bu kod satırı, her T-SQL deyimi yürütüldükten sonra SQL Server'ın istemciye geri gönderdiği iletileri kapatır. Bu herkes için yapılır SELECT, INSERT, UPDATE, ve DELETEifadeleri. Bir sorgu penceresinde bir T-SQL deyimi çalıştırdığınızda bu bilgilere sahip olmak yararlıdır, ancak saklı yordamlar çalıştırıldığında bu bilgilerin istemciye iletilmesine gerek yoktur.

Bu ek yükü ağdan kaldırarak, veritabanınız ve uygulamanız için genel performansı büyük ölçüde artırabilir.

Çalışmakta olan T-SQL deyiminden etkilenen satır sayısını almaya devam etmeniz gerekiyorsa, yine de @@ROWCOUNTseçeneği kullanabilirsiniz . Düzenlenmek suretiyle bir SET NOCOUNT ONbu fonksiyon ( @@ROWCOUNT) hala çalışır ve hala açıklamada etkilenen kaç satır tanımlamak için saklı prosedürlerde kullanılabilir.