SET NOCOUNT ON sull'utilizzo

Ispirato da questa domanda in cui ci sono viste diverse su SET NOCOUNT ...

Dovremmo usare SET NOCOUNT ON per SQL Server? In caso contrario, perché no?

Cosa fa Modifica 6, il 22 lug 2011

Sopprime il messaggio "Righe xx interessate" dopo qualsiasi DML. Questo è un gruppo di risultati e quando viene inviato, il client deve elaborarlo. È piccolo, ma misurabile (vedi risposte sotto)

Per i trigger ecc., Il client riceverà più "righe xx interessate" e questo causerà tutti i tipi di errori per alcuni ORM, MS Access, JPA ecc. (Vedere le modifiche di seguito)

Sfondo:

Le best practice generalmente accettate (ho pensato fino a questa domanda) devono essere utilizzate SET NOCOUNT ONnei trigger e nelle stored procedure in SQL Server. Lo usiamo ovunque e un rapido google mostra anche molti MVP di SQL Server d'accordo.

MSDN dice che questo può rompere un .net SQLDataAdapter .

Ora, questo significa per me che SQLDataAdapter è limitato all'elaborazione CRUD semplicemente perché si aspetta che il messaggio "n righe interessate" corrisponda. Quindi, non posso usare:

• SE ESISTE per evitare duplicati (nessun messaggio sulle righe interessate) Nota: utilizzare con cautela
• DOVE NON ESISTE (meno righe del previsto
• Filtra aggiornamenti banali (ad es. Nessun dato cambia effettivamente)
• Effettua qualsiasi accesso alla tabella prima (come la registrazione)
• Nascondi complessità o denormlizzazione
• eccetera

Nella domanda marc_s (che conosce le sue cose SQL) dice di non usarlo. Ciò differisce da quello che penso (e mi considero un po 'competente anche in SQL).

È possibile che mi manchi qualcosa (sentiti libero di sottolineare l'ovvio), ma cosa ne pensi là fuori?

Nota: sono passati anni da quando ho visto questo errore perché al giorno d'oggi non uso SQLDataAdapter.

Modifiche dopo commenti e domande:

Modifica: più pensieri ...

Abbiamo più client: uno può usare un SQLDataAdaptor C #, un altro può usare nHibernate da Java. Questi possono essere influenzati in diversi modi con SET NOCOUNT ON.

Se consideri i proc memorizzati come metodi, allora è una cattiva forma (anti-pattern) supporre che l'elaborazione interna funzioni in un certo modo per i tuoi scopi.

Modifica 2: un trigger che interrompe la domanda nHibernate , dove SET NOCOUNT ONnon può essere impostato

(e no, non è un duplicato di questo )

Modifica 3: ancora più informazioni, grazie al mio collega MVP

• 240882 KB , problema che causa disconnessioni su SQL 2000 e precedenti
• Demo del guadagno in termini di prestazioni

Modifica 4: 13 maggio 2011

Rompe anche Linq 2 SQL quando non specificato?

Modifica 5: 14 giu 2011

Rompere JPA, proc memorizzato con variabili di tabella: JPA 2.0 supporta le variabili di tabella di SQL Server?

Modifica 6: 15 ago 2011

La griglia di dati "Modifica righe" di SSMS richiede SET NOCOUNT ON: Aggiorna trigger con GROUP BY

Modifica 7: 07 Mar 2013

Dettagli più dettagliati da @RemusRusanu:
SET NOCOUNT ON fa davvero molta differenza nelle prestazioni

Ok ora ho fatto le mie ricerche, ecco l'affare:

Nel protocollo TDS, SET NOCOUNT ONsalva solo 9 byte per query mentre il testo "SET NOCOUNT ON" stesso è di ben 14 byte. Pensavo che 123 row(s) affectedfosse restituito dal server in testo normale in un pacchetto di rete separato, ma non è così. In realtà è una piccola struttura chiamata DONE_IN_PROCincorporata nella risposta. Non è un pacchetto di rete separato, quindi non vengono sprecati viaggi di andata e ritorno.

Penso che si possa attenersi al comportamento di conteggio predefinito quasi sempre senza preoccuparsi delle prestazioni. In alcuni casi, tuttavia, il calcolo anticipato del numero di righe influisce sulle prestazioni, ad esempio un cursore di sola andata. In tal caso, NOCOUNT potrebbe essere una necessità. A parte questo, non è assolutamente necessario seguire il motto "usa NOCOUNT ove possibile".

Ecco un'analisi molto dettagliata sull'insignificanza SET NOCOUNTdell'impostazione: http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/

Mi ci sono voluti un sacco di ricerche per trovare cifre di riferimento reali intorno a NOCOUNT, quindi ho pensato di condividere un breve riassunto.

• Se la procedura memorizzata utilizza un cursore per eseguire molte operazioni molto rapide senza risultati restituiti, la disattivazione di NOCOUNT può richiedere circa 10 volte il tempo di averlo attivato. ¹ Questo è lo scenario peggiore.
• Se la procedura memorizzata esegue solo una singola operazione rapida senza risultati restituiti, l'impostazione di NOCOUNT ON potrebbe produrre un aumento delle prestazioni di circa il 3%. ² Ciò sarebbe coerente con una tipica procedura di inserimento o aggiornamento. (Vedi i commenti su questa risposta per alcune discussioni sul perché questo potrebbe non essere sempre più veloce.)
• Se la procedura memorizzata restituisce risultati (ovvero SELEZIONA qualcosa), la differenza di prestazioni diminuirà proporzionalmente alla dimensione del set di risultati.

• Quando SET NOCOUNT è ON, il conteggio (che indica il numero di righe interessate da un'istruzione Transact-SQL) non viene restituito. Quando SET NOCOUNT è OFF, il conteggio viene restituito. Viene utilizzato con qualsiasi istruzione SELECT, INSERT, UPDATE, DELETE.

• L'impostazione di SET NOCOUNT è impostata in fase di esecuzione o di esecuzione e non in fase di analisi.

• SET NOCOUNT ON migliora le prestazioni della stored procedure (SP).

• Sintassi: SET NOCOUNT {ON | OFF}

Esempio di SET NOCOUNT ON:

Esempio di SET NOCOUNT OFF:

Immagino che sia un problema DBA vs. sviluppatore.

Per lo più da dev, direi di non usarlo a meno che non sia assolutamente necessario, perché usarlo può violare il codice ADO.NET (come documentato da Microsoft).

E immagino che come DBA, saresti più dall'altra parte: usalo quando possibile a meno che tu non debba davvero impedirne l'uso.

Inoltre, se i tuoi sviluppatori usano mai "RecordsAffected" restituito dalla ExecuteNonQuerychiamata del metodo di ADO.NET , sei nei guai se tutti lo usano SET NOCOUNT ONpoiché in questo caso, ExecuteNonQuery restituirà sempre 0.

Vedi anche il post sul blog di Peter Bromberg e controlla la sua posizione.

Quindi si riduce davvero a chi arriva a stabilire gli standard :-)

Marc

Se stai dicendo che potresti avere anche client diversi, ci sono problemi con ADO classico se SET NOCOUNT non è impostato su ON.

Uno che sperimento regolarmente: se una procedura memorizzata esegue un numero di istruzioni (e quindi vengono restituiti un numero di messaggi "xxx righe interessate"), ADO sembra non gestirlo e genera l'errore "Impossibile modificare la proprietà ActiveConnection di un oggetto Recordset che ha un oggetto Command come sorgente. "

Quindi in genere consiglio di impostarlo su ON a meno che non ci sia davvero un buon motivo per non farlo. potresti aver trovato l'ottimo motivo per cui devo andare a leggere di più.

A rischio di complicare le cose, incoraggio una regola leggermente diversa da tutte quelle che vedo sopra:

• Impostare sempre NOCOUNT ONnella parte superiore di un proc, prima di eseguire qualsiasi lavoro nel proc, ma anche sempre di SET NOCOUNT OFFnuovo, prima di restituire qualsiasi recordset dal proc memorizzato.

Quindi "generalmente continua con nocount, tranne quando stai effettivamente restituendo un set di risultati". Non so in alcun modo che questo possa violare qualsiasi codice client, significa che il codice client non ha mai bisogno di sapere nulla sui proc interni e non è particolarmente oneroso.

Per quanto riguarda i fattori scatenanti della rottura di NHibernate, ho avuto l'esperienza di prima mano. Fondamentalmente, quando NH fa un AGGIORNAMENTO si aspetta un certo numero di righe interessate. Aggiungendo SET NOCOUNT ON ai trigger si ottiene il numero di righe su ciò che NH si aspettava, risolvendo così il problema. Quindi sì, consiglio vivamente di disattivarlo per i trigger se si utilizza NH.

Per quanto riguarda l'utilizzo negli SP, è una questione di preferenze personali. Avevo sempre disattivato il conteggio delle righe, ma, di nuovo, non ci sono argomenti concreti in nessun modo.

In una nota diversa, dovresti davvero considerare di abbandonare l'architettura basata su SP, quindi non avrai nemmeno questa domanda.

Volevo verificare che "SET NOCOUNT ON" non salvi un pacchetto di rete né un roundtrip

Ho usato un SQLServer di prova 2017 su un altro host (ho usato una macchina virtuale) 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 Quindi ho tracciato i pacchetti sulla porta 1433 con lo strumento 'Wireshark': pulsante 'filtro cattura' -> 'porta 1433'

exec procNoCount

questo è il pacchetto di risposta: 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

questo è il pacchetto di risposta: 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

Nella riga 40 posso vedere '07' che è il numero di 'righe interessate'. È incluso nel pacchetto di risposta. Nessun pacchetto aggiuntivo.

Dispone tuttavia di 13 byte extra che potrebbero essere salvati, ma probabilmente non ne vale la pena rispetto alla riduzione dei nomi di colonna (ad es. "ManagingDepartment" in "MD")

Quindi non vedo alcun motivo per usarlo per le prestazioni

MA Come altri hanno già detto, può rompere ADO.NET e ho anche inciampato su un problema usando Python: MSSQL2008 - Pyodbc - SQL precedente non era una query

Quindi probabilmente una buona abitudine ancora ...

SET NOCOUNT ON;

Questa riga di codice viene utilizzata in SQL per non restituire il numero di righe interessate nell'esecuzione della query. Se non richiediamo il numero di righe interessate, possiamo utilizzarlo in quanto ciò aiuterebbe a risparmiare l'utilizzo della memoria e aumenterebbe l'intervallo di esecuzione della query.

SET NOCOUNT ON; Il codice precedente interromperà il messaggio generato dal motore del server sql alla finestra dei risultati con il fronte dopo l'esecuzione del comando DML / DDL.

Perché lo facciamo? Poiché il motore del server SQL richiede alcune risorse per ottenere lo stato e generare il messaggio, viene considerato come sovraccarico del motore del server SQL.

Un posto che SET NOCOUNT ONpuò davvero aiutare è dove stai facendo query in un ciclo o un cursore. Questo può aggiungere molto traffico di rete.

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

L'attivazione delle statistiche del client in SSMS, una serie di EXEC NoCountOne EXEC NoCountOffmostra che c'era un traffico extra di 390 KB su NoCountOff:

Probabilmente non è l'ideale per fare query in un ciclo o cursore, ma non viviamo nemmeno nel mondo ideale :)

So che è una domanda piuttosto vecchia. ma solo per l'aggiornamento.

Il modo migliore per usare "SET NOCOUNT ON" è metterlo come prima istruzione nel tuo SP e impostarlo nuovamente su OFF appena prima dell'ultima istruzione SELECT.

SET NOCOUNT ON consente anche di accedere alle righe interessate in questo modo:

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

risultati

affectedRows

1

messaggi

Comandi completati correttamente.

Tempo di completamento: 2020-06-18T16: 20: 16.9686874 + 02: 00

Non so come testare SET NOCOUNT ON tra client e SQL, quindi ho testato un comportamento simile per altri comandi SET "SET TRANSACTION ISOLATION LEVEL READ UNCIMMITTED"

Ho inviato un comando dalla mia connessione modificando il comportamento predefinito di SQL (LEGGI COMMITTATO) ed è stato modificato per i comandi successivi. Quando ho modificato il livello ISOLATION all'interno di una procedura memorizzata, non è cambiato il comportamento della connessione per il comando successivo.

Conclusione attuale,

1. La modifica delle impostazioni all'interno della procedura memorizzata non modifica le impostazioni predefinite della connessione.
2. La modifica delle impostazioni inviando comandi mediante ADOCOnnection modifica il comportamento predefinito.

Penso che questo sia rilevante per altri comandi SET come "SET NOCOUNT ON"

if (imposta no count == off)

{allora manterrà i dati di quanti record interessati, quindi riduci le prestazioni} altrimenti {non traccerà il record delle modifiche, quindi migliora perfomace}}

A volte anche le cose più semplici possono fare la differenza. Uno di questi semplici elementi che dovrebbero far parte di ogni procedura memorizzata è SET NOCOUNT ON. Questa riga di codice, inserita all'inizio di una procedura memorizzata, disattiva i messaggi che SQL Server restituisce al client dopo l'esecuzione di ogni istruzione T-SQL. Questa operazione viene eseguita per tutti SELECT, INSERT, UPDATE, e DELETEle dichiarazioni. Avere queste informazioni è utile quando si esegue un'istruzione T-SQL in una finestra di query, ma quando vengono eseguite le procedure memorizzate non è necessario che queste informazioni vengano restituite al client.

Rimuovendo questo sovraccarico aggiuntivo dalla rete, è possibile migliorare notevolmente le prestazioni complessive per il database e l'applicazione.

Se è ancora necessario ottenere il numero di righe interessate dall'istruzione T-SQL in esecuzione, è comunque possibile utilizzare l' @@ROWCOUNTopzione. Emettendo una SET NOCOUNT ONfunzione this ( @@ROWCOUNT) funziona ancora e può ancora essere utilizzato nelle procedure memorizzate per identificare quante righe sono state interessate dall'istruzione.