Quali sono le possibili cause per l'esecuzione di sp_reset_connection impiegando molto tempo?

Perché la sp_reset_connectionprocedura memorizzata dal sistema impiegherebbe più tempo di qualche millisecondo per essere eseguita, come visto tramite SQL Server Profiler?

Ho preso una semplice traccia da un sistema di produzione usando SQL Server Profiler e poi ho usato SqlNexus per analizzarlo. SqlNexus indica che sp_reset_connection ha la durata cumulativa più alta, pari al 33% della traccia complessiva. La durata osservata varia da 0 a 7 secondi (da 12 a 6.833.270 microsecondi), ma in media a 0,956 secondi.

Comprendo che sp_reset_connection viene chiamato quando viene riutilizzata una connessione in pool. Ho visto un suggerimento che ciò può accadere a causa di tracce estranee , ma non sembra essere il caso.

Ho letto cosa sta facendo il server quando viene chiamato lo sproc ma non credo che nessuno di questi sarebbe problematico in questo caso - il codice non sta lasciando transazioni aperte o enormi tabelle temporanee che dovrebbero essere ripulite.

Ho anche guardato /server/199974/sp-reset-connection-taking-a-long-time-to-run ma non è stato utile.

EDIT (23-12-2013): in tutti i casi, letture e scritture sono 0 e la CPU è quasi sempre 0 (solo due istanze di CPU diversa da zero, entrambe a 16ms).

Finalmente ho avuto il tempo di scrivere una risposta più dettagliata.

Ci sono in genere tre ragioni principali come una semplice procedura sp_reset_connection richiederà molto tempo per essere eseguita.

1. Stai aspettando risorse CPU
2. Sei bloccato su un lucchetto da qualche parte (forse a causa di DML o di una transazione concorrente)
3. La tua rete è lenta e richiede molto tempo per restituire il risultato al client

Annuncio 1) Se stai aspettando risorse CPU, questo dovrebbe comparire mentre il segnale è in attesa. Si prega di vedere il mio commento sulla tua domanda su come diagnosticare se questo è il problema

Annuncio 2) Se stai aspettando un lucchetto, è meglio diagnosticare confrontando due istantanee di sys.dm_os_wait_stats. Vedi questo articolo su come eseguire questa operazione:

• http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Se vedi lunghe attese per LCK_ [Something], esegui una query sys.dm_tran_locks per individuare quali oggetti sono bloccati. Nel tuo caso, mi aspetterei di vedere qualche forma di blocchi SCH- [Something]> che ti bloccano.

Annuncio 3) Il modo più semplice per diagnosticare i problemi di rete per cercare prima OLEDB e ASYNC_NETWORK_IO attende nel passaggio 2 (se aspetti a lungo la rete, uno di questi viene visualizzato). Se quelle attese sono alte, usa xperf -on latencyo un programma di monitoraggio della rete come netmon o WireShark per controllare le tue latenze. Se la rete sembra lenta, ciò potrebbe anche essere causato dal server delle applicazioni chiamante che non risponde abbastanza velocemente alla connessione da riciclare.

Ho appena trovato un articolo KB per un bug che potrebbe essere correlato a questo problema. In FIX: i problemi di prestazioni si verificano quando l'attività di blocco del database aumenta in SQL Server (KB 2926217), uno dei sintomi descritti sp_reset_connectionpotrebbe richiedere molto tempo per il completamento. L'aggiornamento rapido è incluso nei seguenti aggiornamenti:

• Aggiornamento cumulativo 17 per SQL Server 2008 SP3
• Aggiornamento cumulativo 13 per SQL Server 2008 R2 SP2
• Aggiornamento cumulativo 9 per SQL Server 2012 SP1
• Aggiornamento cumulativo 1 per SQL Server 2014

Il server su cui ho osservato questo comportamento stava eseguendo SQL Server 2008 SP3 con Cumulative Update 5, quindi è possibile che si sia verificato questo errore. Non ho ancora provato l'aggiornamento cumulativo (il problema non si ripresenta sempre) quindi non posso verificare se lo risolverà o meno. Tuttavia, volevo fornire le informazioni nel caso in cui qualcuno avesse gli stessi sintomi.