SET NOCOUNT ON Verwendung

341

Inspiriert von dieser Frage, wo es unterschiedliche Ansichten zu SET NOCOUNT gibt ...

Sollten wir SET NOCOUNT ON für SQL Server verwenden? Wenn nicht, warum nicht?

Was es macht Edit 6, am 22. Juli 2011

Es unterdrückt die Meldung "xx Zeilen betroffen" nach jeder DML. Dies ist eine Ergebnismenge, die der Client beim Senden verarbeiten muss. Es ist winzig, aber messbar (siehe Antworten unten)

Bei Triggern usw. erhält der Client mehrere "betroffene xx Zeilen", was bei einigen ORMs, MS Access, JPA usw. zu allen möglichen Fehlern führt (siehe Änderungen unten).

Hintergrund:

Allgemein anerkannte Best Practice (ich dachte bis zu dieser Frage) ist die Verwendung SET NOCOUNT ONin Triggern und gespeicherten Prozeduren in SQL Server. Wir verwenden es überall und ein kurzer Blick auf Google zeigt, dass auch viele SQL Server-MVPs zustimmen.

MSDN sagt, dass dies einen .net SQLDataAdapter beschädigen kann .

Für mich bedeutet dies, dass der SQLDataAdapter auf die einfache CRUD-Verarbeitung beschränkt ist, da erwartet wird, dass die Nachricht "n betroffene Zeilen" übereinstimmt. Also kann ich nicht verwenden:

  • WENN EXISTIERT, um Duplikate zu vermeiden (keine Zeilen betroffene Nachricht) Hinweis: Mit Vorsicht verwenden
  • WO NICHT EXISTIERT (weniger Zeilen als erwartet
  • Filtern Sie triviale Updates heraus (z. B. ändern sich keine Daten tatsächlich)
  • Führen Sie vorher einen Tabellenzugriff durch (z. B. Protokollierung).
  • Komplexität oder Denormierung verbergen
  • usw

In der Frage sagt marc_s (wer kennt sich mit SQL aus), benutze es nicht. Dies unterscheidet sich von dem, was ich denke (und ich betrachte mich auch als etwas kompetent in SQL).

Es ist möglich, dass mir etwas fehlt (zögern Sie nicht, auf das Offensichtliche hinzuweisen), aber was denken Sie da draußen?

Hinweis: Es ist Jahre her, seit ich diesen Fehler gesehen habe, weil ich SQLDataAdapter heutzutage nicht mehr verwende.

Änderungen nach Kommentaren und Fragen:

Edit: Mehr Gedanken ...

Wir haben mehrere Clients: Einer kann einen C # SQLDataAdaptor verwenden, ein anderer kann nHibernate von Java verwenden. Diese können mit auf unterschiedliche Weise beeinflusst werden SET NOCOUNT ON.

Wenn Sie gespeicherte Prozesse als Methoden betrachten, ist es eine schlechte Form (Anti-Pattern) anzunehmen, dass einige interne Verarbeitungen für Ihre eigenen Zwecke auf eine bestimmte Weise funktionieren.

Edit 2: Ein Trigger, der die nHibernate-Frage bricht , wo SET NOCOUNT ONnicht gesetzt werden kann

(und nein, es ist kein Duplikat davon )

Edit 3: Noch mehr Infos, danke an meinen MVP-Kollegen

Bearbeiten 4: 13 Mai 2011

Bricht Linq 2 SQL auch, wenn nicht angegeben?

Bearbeiten 5: 14 Jun 2011

Bricht JPA ab, gespeicherter Prozess mit Tabellenvariablen: Unterstützt JPA 2.0 SQL Server-Tabellenvariablen?

Bearbeiten 6: 15 Aug 2011

Das SSMS-Datenraster "Zeilen bearbeiten" erfordert SET NOCOUNT ON: Trigger mit GROUP BY aktualisieren

Bearbeiten 7: 07 Mar 2013

Ausführlichere Details von @RemusRusanu: Macht SET NOCOUNT ON wirklich einen so großen Leistungsunterschied aus?

gbn
quelle
@AlexKuznetsov: Was wäre ein "Threadsafe" -Ansatz? Sicherlich würden in den EXISTS durchgeführte Lesevorgänge noch ausstehende Transaktionen enthalten sein?
AnthonyWJones
2
@ Jeremy Seghi: Entschuldigung für die späte Antwort. Die Nachricht (#rows betroffen) ist ein Client-Tool, das von SSMS usw. interpretiert wird. Es wird jedoch ein Paket mit diesen Informationen gesendet. Natürlich weiß ich, wie @@ rowcount usw. funktioniert, aber das ist nicht der Punkt der Frage ...
gbn
1
Keine Sorge. Persönlich stimme ich Ihrem Standpunkt zu; Ich habe nur kommentiert, dass es keine direkte Korrelation zwischen den Ergebnissen eines IF / WHERE EXISTS-Konstrukts und SET NOCOUNT gibt. Ich erhalte konsistente Ergebnisse von diesen Konstrukten unabhängig von NOCOUNT. Wenn Sie etwas anderes sagen, senden Sie es mir bitte.
Jeremy S
1
@ Jeremy Seghi: Sie haben Recht: SET NOCOUNT ON unterdrückt nur das zusätzliche Datenpaket zurück zum Client. WENN, @@ ROWCOUNT usw. alle nicht betroffen sind. Oh, und es bricht SQLDataAdapters ... :-)
gbn
1
@Kieren Johnstone: Im Nachhinein ist es eine schlecht formulierte Frage. Ich würde zum Schließen stimmen, wenn dies nicht meine Frage wäre ...
gbn

Antworten:

245

Ok, jetzt habe ich meine Nachforschungen angestellt. Hier ist der Deal:

Im TDS-Protokoll werden SET NOCOUNT ONnur 9 Bytes pro Abfrage gespeichert, während der Text "SET NOCOUNT ON" selbst satte 14 Bytes umfasst. Früher dachte ich, dass dies 123 row(s) affectedvom Server im Klartext in einem separaten Netzwerkpaket zurückgegeben wurde, aber das ist nicht der Fall. Es ist in der Tat eine kleine Struktur namens DONE_IN_PROCeingebettet in die Antwort. Es ist kein separates Netzwerkpaket, sodass keine Hin- und Rückflüge verschwendet werden.

Ich denke, Sie können sich fast immer an das Standardzählverhalten halten, ohne sich um die Leistung sorgen zu müssen. Es gibt jedoch einige Fälle, in denen die Berechnung der Anzahl der Zeilen im Voraus die Leistung beeinträchtigen würde, z. B. ein Nur-Vorwärts-Cursor. In diesem Fall könnte NOCOUNT eine Notwendigkeit sein. Abgesehen davon besteht absolut keine Notwendigkeit, dem Motto "NOCOUNT wo immer möglich verwenden" zu folgen.

Hier ist eine sehr detaillierte Analyse über die Bedeutungslosigkeit der SET NOCOUNTEinstellung: http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/

Sedat Kapanoglu
quelle
Tatsächlich. Ich habe SET NOCOUNT ON schon immer verwendet, aber marc_s hat in der anderen Frage auf die Einschränkung von SQLDataAdapter hingewiesen.
gbn
Vielen Dank. Die Bytes oder die Größe sind für mich nicht das Problem, aber der Client muss sie verarbeiten. Es ist die SQLDataAdapter-Abhängigkeit, die mich immer noch verblüfft ...
gbn
2
Danke für deine Antwort. Ich werde dies aufgrund Ihrer Untersuchungen akzeptieren, die mehr Informationen und Arbeit von mir ausgelöst haben. Ich bin jedoch nicht einverstanden mit dem Overhead: Es kann wichtig sein, wie andere Antworten zeigen. Prost, gbn
gbn
13
Es ist nicht die Anzahl der Bytes seiner
Roundtrip-
1
Im TDS-Nachrichtenstrom ist ein Beispiel, wenn nur Werte in die Tabelle eingefügt werden. DONINPROC(RPC) - oder DONE(BATCH) -Nachricht wird gestreamt, wobei rowcountauf betroffene Zeilen gesetzt wird, während done_countFlag ist true, unabhängig davon, ob dies der Fall NO_COUNTist ON. Abhängig von der Implementierung der Client-Bibliothek in Fällen, in denen die Abfrage SELECT-Anweisungen oder RPC-Aufrufe enthält, die auswählen, muss möglicherweise die Zählung deaktiviert werden. WENN deaktiviert, werden die Zeilen für die select-Anweisung weiterhin gezählt, das Flag DONE_COUNTwird jedoch auf gesetzt false. Lesen Sie immer, was Ihre Client-Bibliothek vorschlägt, da sie den Token- (Nachrichten-) Stream anstelle von Ihnen interpretiert
Milan Jaric,
86

Ich musste viel graben, um echte Benchmark-Zahlen rund um NOCOUNT zu finden, also dachte ich mir, ich würde eine kurze Zusammenfassung teilen.

  • Wenn Ihre gespeicherte Prozedur einen Cursor verwendet, um viele sehr schnelle Vorgänge ohne zurückgegebene Ergebnisse auszuführen, kann das Ausschalten von NOCOUNT ungefähr zehnmal so lange dauern wie das Einschalten. 1 Dies ist der schlimmste Fall.
  • Wenn Ihre gespeicherte Prozedur führt nur eine einzige schnelle Bedienung ohne zurückgegebenen Ergebnisse, Einstellung NOCOUNT ON könnte eine 3% ige Leistungssteigerung ergeben sich um. 2 Dies würde mit einem typischen Einfüge- oder Aktualisierungsverfahren übereinstimmen. (In den Kommentaren zu dieser Antwort finden Sie eine Diskussion darüber, warum dies möglicherweise nicht immer schneller ist.)
  • Wenn Ihre gespeicherte Prozedur Ergebnisse zurückgibt (dh Sie wählen etwas aus), verringert sich der Leistungsunterschied proportional zur Größe der Ergebnismenge.
StriplingWarrior
quelle
5
+1 für die Auswirkung auf den Cursor, dies stimmt mit meinen Beobachtungen
überein
Punkt 2 ist nicht genau! Ich meine den Blog, auf den es sich bezieht. Es war niemals! DONE und DONEPROC und DONEINPROC werden mit derselben Größe gesendet, unabhängig davon, ob NO_COUNT auf ON oder OFF gesetzt ist. RowCount ist immer noch als ULONGLONG (64 Byte) vorhanden und das Flag DONE_COUNT ist immer noch vorhanden, aber der Bitwert ist 0. SQL Server zählt sowieso die Anzahl der Zeilen, auch wenn Sie nicht daran interessiert sind, den Wert vom DONE-Token zu lesen. Wenn Sie @@ ROWCOUNT lesen, haben Sie dem Token-Stream weitere Bytes hinzugefügt, entweder in Form eines Rückgabewert-Tokens oder als andere Colmetadaten + Zeilentoken!
Milan Jaric
@MilanJaric: Danke, dass du das gerufen hast. Sie haben mir geholfen zu erkennen, dass ich den falschen Artikel verlinkt habe. Der Link wird jetzt aktualisiert und der Artikel liefert ein überzeugendes Argument, um zu zeigen, dass es mit SET NOCOUNT ON zu einer leichten Leistungsverbesserung kommen kann. Denken Sie, dass es Probleme mit den verwendeten Benchmark-Methoden gibt?
StriplingWarrior
:) immer noch ungenau über SET NOCOUNT OFF / ON, Fehler ist, dass zweite SP nicht haben SET NOCOUNT OFF;und deshalb denken sie, dass sie keine zusätzlichen Bytes als Antwort erhalten. Ein genauer Benchmark wäre die Verwendung SET NOCOUNT ONin der SET NOCOUNT OFFgespeicherten Prozedur links und rechts. Auf diese Weise erhalten Sie das TDS-Paket mit DONEINPROC (SET NOCOUNT ...), wieder zehn DONEINPROC (INSERT statement)und dann RETURNVALUE(@@ROWCOUNT), dann RETURNSTATUS 0für sp und schließlich DONPROC. Der Fehler liegt vor, weil der zweite SP im Körper kein SET NOCOUNT OFF hat!
Milan Jaric
Um zu formulieren, was sie gefunden haben, aber nicht bemerkt haben, müssen Sie bei einer 1K-Abruf-Cursor-Anforderung zunächst eine Anforderung stellen, um NOCOUNT für die Verbindung auf EIN oder AUS zu setzen, und dann dieselbe Verbindung verwenden, um den Cursor-Abruf 1K-mal aufzurufen, um etwas Bandbreite zu sparen. Der tatsächliche Verbindungsstatus für NOCOUNT ON oder OFF hat keinen Einfluss auf die Bandbreite. Er kann nur die Client-Bibliothek verwirren, z. B. ADO.net oder ODBC. Also "benutze SET NOCOUNT <WHATEVER> nicht, wenn dir die Bandbreite wichtig ist" :)
Milan Jaric
77
  • Wenn SET NOCOUNT auf ON gesetzt ist, wird die Anzahl (die die Anzahl der von einer Transact-SQL-Anweisung betroffenen Zeilen angibt) nicht zurückgegeben. Wenn SET NOCOUNT AUS ist, wird die Zählung zurückgegeben. Es wird mit jeder Anweisung SELECT, INSERT, UPDATE, DELETE verwendet.

  • Die Einstellung von SET NOCOUNT wird zur Ausführungs- oder Laufzeit und nicht zur Analysezeit festgelegt.

  • SET NOCOUNT ON verbessert die Leistung der gespeicherten Prozedur (SP).

  • Syntax: SET NOCOUNT {ON | AUS }

Beispiel für SET NOCOUNT ON:

Geben Sie hier die Bildbeschreibung ein

Beispiel für SET NOCOUNT OFF:

Geben Sie hier die Bildbeschreibung ein

Bhaumik Patel
quelle
7
Einfach und schnell mit Screenshots zu verstehen. Gut gemacht. :)
Shaijut
35

Ich denke, bis zu einem gewissen Grad handelt es sich um ein Problem zwischen DBA und Entwickler.

Meistens würde ich als Entwickler sagen, dass Sie es nur verwenden, wenn Sie es unbedingt müssen - da die Verwendung Ihren ADO.NET-Code beschädigen kann (wie von Microsoft dokumentiert).

Und ich denke, als DBA wären Sie eher auf der anderen Seite - verwenden Sie es, wann immer es möglich ist, es sei denn, Sie müssen die Verwendung wirklich verhindern.

Wenn Ihre Entwickler jemals "RecordsAffected" verwenden, das vom ExecuteNonQueryMethodenaufruf von ADO.NET zurückgegeben wird, sind Sie in Schwierigkeiten, wenn alle verwenden, SET NOCOUNT ONda ExecuteNonQuery in diesem Fall immer 0 zurückgibt.

Sehen Sie sich auch den Blog-Beitrag von Peter Bromberg an und überprüfen Sie seine Position.

Es kommt also wirklich darauf an, wer die Standards setzen darf :-)

Marc

marc_s
quelle
Er befasst sich jedoch mit einfachem CRUD: Das von ihm erwähnte
Datenraster
Ich denke, wenn Sie niemals SqlDataAdapters verwenden und niemals nach der von ExecuteNonQuery zurückgegebenen Nummer "Betroffene Datensätze" suchen und sich darauf verlassen (z. B. wenn Sie etwas wie Linq-to-SQL oder NHibernate verwenden), haben Sie wahrscheinlich keine Probleme Verwenden von SET NOCOUNT ON in allen gespeicherten Prozessen.
marc_s
12

Wenn Sie sagen, dass Sie möglicherweise auch andere Clients haben, gibt es Probleme mit klassischem ADO, wenn SET NOCOUNT nicht aktiviert ist.

Eine, die ich regelmäßig erlebe: Wenn eine gespeicherte Prozedur eine Reihe von Anweisungen ausführt (und daher eine Reihe von Nachrichten "xxx Zeilen betroffen" zurückgegeben werden), scheint ADO dies nicht zu behandeln und löst den Fehler "Die ActiveConnection-Eigenschaft eines Recordset-Objekts kann nicht geändert werden welches ein Befehlsobjekt als Quelle hat. "

Daher empfehle ich generell, es einzuschalten, es sei denn, es gibt einen wirklich guten Grund, dies nicht zu tun. Sie haben vielleicht den wirklich sehr guten Grund gefunden, in den ich mehr hineinlesen muss.

Chris J.
quelle
9

Auf die Gefahr hin, die Dinge komplizierter zu machen, empfehle ich eine etwas andere Regel als alle oben genannten:

  • Setzen Sie immer NOCOUNT ONoben in einem Prozess, bevor Sie Arbeiten im Prozess ausführen, aber auch immer SET NOCOUNT OFFwieder, bevor Sie Datensätze aus dem gespeicherten Prozess zurückgeben.

Also "im Allgemeinen nicht zählen, außer wenn Sie tatsächlich eine Ergebnismenge zurückgeben". Ich kenne keine Möglichkeiten, wie dies einen Client-Code beschädigen kann. Dies bedeutet, dass der Client-Code nie etwas über die Proc-Interna wissen muss und nicht besonders belastend ist.

Tao
quelle
Vielen Dank. Sie können die Zeilenanzahl natürlich aus dem DataSet oder dem konsumierenden Container abrufen, dies kann jedoch hilfreich sein. Wir können keine Trigger für SELECTs haben, daher wäre dies sicher: Die meisten Clientfehler werden durch falsche Meldungen bei Datenänderungen verursacht.
Gbn
Das Problem mit dieser Regel ist nur, dass es schwieriger zu testen ist als "Ist SET NOCOUNT ON oben im Prozess?"; Ich frage mich, ob SQL Analysis-Tools wie Sql Enlight auf solche Dinge testen können ... Hinzufügen zu meiner langfristigen Aufgabenliste für mein SQL-Formatierungsprojekt :)
Tao
5

In Bezug auf die Auslöser, die NHibernate brechen, hatte ich diese Erfahrung aus erster Hand. Grundsätzlich erwartet NH bei einem UPDATE eine bestimmte Anzahl betroffener Zeilen. Durch Hinzufügen von SET NOCOUNT ON zu den Triggern erhalten Sie die Anzahl der Zeilen wieder auf den erwarteten Wert von NH, wodurch das Problem behoben wird. Also ja, ich würde definitiv empfehlen, es für Trigger auszuschalten, wenn Sie NH verwenden.

In Bezug auf die Verwendung in SPs ist es eine Frage der persönlichen Präferenz. Ich hatte die Zeilenanzahl immer ausgeschaltet, aber andererseits gibt es auch keine wirklich starken Argumente.

In einem anderen Sinne sollten Sie wirklich überlegen, sich von der SP-basierten Architektur zu entfernen, dann werden Sie diese Frage nicht einmal haben.

zvolkov
quelle
1
Ich bin nicht damit einverstanden, mich von gespeicherten Prozessen zu entfernen. Dies würde bedeuten, dass wir dasselbe SQL in zwei verschiedenen Client-Codebasen haben und unseren Client-Codierern vertrauen müssen. Wir sind Entwickler-DBAs. Und meinst du nicht "SET NOCOUNT ON "?
gbn
@CodeBlend: Google es einfach für mehr als du jemals brauchst. Jedoch ... stackoverflow.com/a/4040466/27535
gbn
3

Ich wollte mich vergewissern, dass 'SET NOCOUNT ON' weder ein Netzwerkpaket noch eine Hin- und Rückfahrt speichert

Ich habe einen Test-SQLServer 2017 auf einem anderen Host verwendet (ich habe eine VM verwendet). 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 Dann habe ich Pakete auf Port 1433 mit dem Tool 'Wireshark' verfolgt: Schaltfläche 'Filter erfassen' -> 'Port 1433'

exec procNoCount

Dies ist das Antwortpaket: 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

Dies ist das Antwortpaket: 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

In Zeile 40 sehe ich '07', was die Anzahl der 'betroffenen Zeile (n)' ist. Es ist im Antwortpaket enthalten. Kein zusätzliches Paket.

Es hat jedoch 13 zusätzliche Bytes, die gespeichert werden könnten, aber wahrscheinlich nicht mehr wert sind, als Spaltennamen zu reduzieren (z. B. 'ManagingDepartment' auf 'MD').

Ich sehe also keinen Grund, es für die Leistung zu verwenden

ABER Wie andere bereits erwähnt haben, kann ADO.NET beschädigt werden, und ich bin auch auf ein Problem mit Python gestoßen : MSSQL2008 - Pyodbc - Vorheriges SQL war keine Abfrage

Also wahrscheinlich noch eine gute Angewohnheit ...

phil_w
quelle
1
SET NOCOUNT ON;

Diese Codezeile wird in SQL verwendet, um die bei der Ausführung der Abfrage betroffenen Zahlenzeilen nicht zurückzugeben. Wenn wir die Anzahl der betroffenen Zeilen nicht benötigen, können wir dies verwenden, da dies zur Speicherung der Speichernutzung und zur Erhöhung der Ausführungsgeschwindigkeit der Abfrage beitragen würde.

user1509
quelle
2
Beachten Sie, dass @@ ROWCOUNT noch eingestellt ist. SET NOCOUNT ON unterdrückt jede zusätzliche Antwort, die SQL Server an den Client sendet. Siehe die akzeptierte Antwort oben bitte
gbn
1

SET NOCOUNT ON; Der obige Code stoppt die von der SQL Server Engine generierte Nachricht im Fronted-Ergebnisfenster nach der Ausführung des DML / DDL-Befehls.

Warum machen wir das? Da die SQL Server-Engine einige Ressourcen benötigt, um den Status abzurufen und die Nachricht zu generieren, wird dies als Überlastung der SQL Server-Engine angesehen. Daher setzen wir die Nicht-Zähl-Nachricht auf.

Subhransu Panda
quelle
1

Ein Ort, der SET NOCOUNT ONwirklich helfen kann, ist, wo Sie Abfragen in einer Schleife oder einem Cursor ausführen. Dies kann zu viel Netzwerkverkehr führen.

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

Wenn Sie die Client-Statistik in SSMS aktivieren, wird ausgeführt EXEC NoCountOnund EXEC NoCountOffzeigt, dass auf dem NoCountOff ein zusätzlicher 390-KB-Datenverkehr vorhanden war:

Kundenstatistik

Wahrscheinlich nicht ideal, um Abfragen in einer Schleife oder einem Cursor durchzuführen, aber wir leben auch nicht in einer idealen Welt :)

bcoughlan
quelle
0

Ich weiß, dass es eine ziemlich alte Frage ist. aber nur zum aktualisieren.

Die beste Möglichkeit, "SET NOCOUNT ON" zu verwenden, besteht darin, es als erste Anweisung in Ihrem SP zu platzieren und es kurz vor der letzten SELECT-Anweisung wieder auszuschalten.

KRules
quelle
-1

Ich weiß nicht, wie ich SET NOCOUNT ON zwischen Client und SQL testen soll, daher habe ich ein ähnliches Verhalten für andere SET-Befehle getestet: "SET TRANSACTION ISOLATION LEVEL READ UNCIMMITTED"

Ich habe einen Befehl von meiner Verbindung gesendet, der das Standardverhalten von SQL (READ COMMITTED) geändert hat, und er wurde für die nächsten Befehle geändert. Als ich die ISOLATION-Ebene in einer gespeicherten Prozedur geändert habe, hat sich das Verbindungsverhalten für den nächsten Befehl nicht geändert.

Aktuelle Schlussfolgerung,

  1. Durch Ändern der Einstellungen in der gespeicherten Prozedur werden die Standardeinstellungen der Verbindung nicht geändert.
  2. Durch Ändern der Einstellung durch Senden von Befehlen mit ADOCOnnection wird das Standardverhalten geändert.

Ich denke, dass dies für andere SET-Befehle wie "SET NOCOUNT ON" relevant ist.

Rabia Mansour
quelle
Bedeutet Ihr Punkt 1 oben, dass Sie NOCOUNT am Ende nicht wirklich AUSSTELLEN müssen, da dies keine Auswirkungen auf die globale Umgebung hat?
Funkymushroom
Ich bin mir nicht sicher, ob er das mit Punkt 1 gemeint hat, aber in meinen Tests ist die globale Umgebung anscheinend nicht von SET NOCOUNT ON in einer gespeicherten Prozedur betroffen.
Doug
Dies war eine schlechte Vergleichswahl, da die Isolationsstufe explizit mit einer bestimmten Transaktion zusammenhängt. Es gibt also keinen besonderen Grund zu der NOCOUNT
Annahme
-1

if (setze keine Zählung == aus)

{Dann werden Daten darüber gespeichert, wie viele Datensätze betroffen sind, um die Leistung zu verringern.} Sonst {Es werden keine Änderungen aufgezeichnet, wodurch die Leistung verbessert wird.}}

Shubham Sharma
quelle
-1

Manchmal können sogar die einfachsten Dinge einen Unterschied machen. Eines dieser einfachen Elemente, das Teil jeder gespeicherten Prozedur sein sollte, ist SET NOCOUNT ON. Diese eine Codezeile am Anfang einer gespeicherten Prozedur deaktiviert die Nachrichten, die SQL Server nach Ausführung jeder T-SQL-Anweisung an den Client zurücksendet. Dies erfolgt für alle SELECT, INSERT, UPDATE, und DELETEAussagen. Diese Informationen sind praktisch, wenn Sie eine T-SQL-Anweisung in einem Abfragefenster ausführen. Wenn jedoch gespeicherte Prozeduren ausgeführt werden, müssen diese Informationen nicht an den Client zurückgegeben werden.

Durch Entfernen dieses zusätzlichen Overheads aus dem Netzwerk kann die Gesamtleistung Ihrer Datenbank und Anwendung erheblich verbessert werden.

Wenn Sie weiterhin die Anzahl der Zeilen abrufen müssen, die von der ausgeführten T-SQL-Anweisung betroffen sind, können Sie die @@ROWCOUNTOption weiterhin verwenden . Durch die Ausgabe einer SET NOCOUNT ONFunktion funktioniert this ( @@ROWCOUNT) weiterhin und kann weiterhin in Ihren gespeicherten Prozeduren verwendet werden, um zu ermitteln, wie viele Zeilen von der Anweisung betroffen waren.

Vinayak Savale
quelle