SQL Server 2005 Blocking Problem (ASYNC_NETWORK_IO)

Question

Sono responsabile di un'applicazione di terze parti (nessun accesso al sorgente) in esecuzione su IIS e SQL Server 2005 (500 utenti simultanei, dati da 1 TB, 8 server IIS). Recentemente abbiamo iniziato a vedere un blocco significativo sul database (dopo mesi di esecuzione di questa applicazione in produzione senza problemi). Ciò si verifica a intervalli casuali durante il giorno, approssimativamente ogni 30 minuti e colpisce tra 20 e 100 sessioni ogni volta. Tutte le sessioni alla fine raggiungono il timeout dell'applicazione e le sessioni si interrompono.

Il problema scompare e quindi riemerge gradualmente. Lo SPID responsabile per il blocco ha sempre le seguenti caratteristiche:

• WAIT TYPE = ASYNC_NETWORK_IO
• Il in esecuzione SQL è “(@claimid varchar (15)) SELEZIONA claimid, enrollid, status, orgclaimid, resubclaimid, primaryclaimid FROM claim WHERE primaryclaimid = @claimid AND primaryclaimid <> claimid) ". Questo è SQL relativamente innocuo che dovrebbe restituire solo uno o due record, non un dataset grande .
• NESSUN ALTRO istruzioni SQL sono state implicate nel blocco, solo questa istruzione SQL .
• Questo è l'SQL parametrizzato per il quale un piano di esecuzione viene memorizzato nella cache in sys.dm_exec_cached_plans.
• Questo SPID ha un blocco S a livello di oggetto nella tabella dei reclami, quindi vengono bloccati anche tutti gli UPDATE/INSERT della tabella dei sinistri.
• ID HOST varia. Diversi server Web sono responsabili delle sessioni di blocco. Ad esempio, a volte ci risalire al web server 1, a volte web server 2.

Quando risaliamo al server web implicati nel blocco, vediamo quanto segue:

• C'è sempre qualche sorta di errore relativo all'applicazione nell'evento Registro eventi sul server Web, collegato all'ID host e all'ID processo host dalla sessione SQL.
• I messaggi di errore variano, in genere alcuni tipi di SystemOutofMemory . (Questi messaggi di errore sembrano essere simili a messaggi di errore che abbiamo visto in passato senza tali drammatiche conseguenze . Pensiamo che stava accadendo prima, ma non hanno portato a bloccare. Perché ora?)
• Nessun problema noto con gli adattatori della rete sui server Web o del server SQL.

(In ogni caso, il set di record restituito dalla query incriminata sarebbe piccolo.)

cose escludere:

• indici sono regolarmente deframmentati.
• Statistiche regolarmente aggiornate.
• Dimensione campione aumentata delle statistiche su claim.primaryclaimid.
• Ricompilazione forzata del piano di esecuzione memorizzato nella cache.
• Creato un indice composto con primaryclaimid, claimid.
• Nessun problema di rete.
• Nessun problema noto sul server Web.
• Nessuna modifica al software applicativo sui server Web .

Noi ipotizziamo che la catena di eventi più o meno così:

1. processo server Web invia SQL sopra.
2. SQL server esegue SQL, durante , che acquisisce un blocco nella tabella di reclamo .
3. Il processo del server Web ha un errore e i dies .
4. La sessione del server SQL è in attesa per il processo del server Web per leggere il set di dati .
5. sessioni SQL Server che devono ottenere i blocchi X su parti della tabella rivendicazione (rivendicazioni chiunque tratti) sono bloccata dal blocco sul tavolo rivendicazione e restano bloccati fino tutti colpito il tempo di applicazione out.

Qualsiasi suggerimento per la risoluzione dei problemi durante l'attesa per l'assistenza del fornitore sarebbe il benvenuto.

C'è un modo per forzare SQL Server a bloccare a livello di riga/pagina solo per questa specifica istruzione SQL? C'è un modo per impostare una soglia su ASYNC_NETWORK_IO attende solo?

Answer 1

ASYNC_NETWORK_IO è causato dai client che non sono in grado di ricevere dati abbastanza veloci e riempiono i buffer di rete (semplicemente messi). Non esiste alcuna impostazione magica di SQL Server per risolverlo.

• riavviare il client (anche se si tratta di web server)
• garantire NIC sono impostati correttamente (firmware, full duplex ecc)
• garantire cavi fisici sono ok (eventuali perdite di pacchetti, ecc?)
• ecc

è non un problema di SQL Server, in quanto tale ...

• Blog article 1
• BOL:

ASYNC_NETWORK_IO verifica sulla rete scrive quando l'attività è bloccata dietro rete.Verificare che il client sia elaborando i dati dal server.

• And another con il collegamento a MS whitepaper

Answer 2

Ho avuto lo stesso problema e ha ottenuto risolto quando ho disabilitato l'antivirus Kaspersky sul client.