SQL Azure: una sessione che blocca l'intero DB per Update e Insert

Question

Problema SQL Azure.

Ho un problema che si manifesta come la seguente eccezione sul nostro sito (asp.net):

Timeout scaduto. Il periodo di timeout è trascorso prima del completamento di l'operazione o il server non risponde. La dichiarazione è stata terminata.

Inoltre comporta l'aggiornamento e le istruzioni di inserimento non completate in SMSS. Non sono presenti blocchi X o IX quando si esegue una query: sys.dm_tran_locks e non ci sono transazioni quando si esegue una query su sys.dm_tran_active_transactions o sys.dm_tran_database_transactions.

Il problema è presente per ogni tabella nel database ma altri database nella stessa istanza non causano il problema. La durata del problema può variare da 2 minuti a 2 ore e non si verifica in momenti specifici della giornata.

Il database non è pieno.

A un certo punto questo problema non si risolve da solo, ma sono stato in grado di risolvere il problema interrogando sys.dm_exec_connections trovando la sessione più lunga in esecuzione e quindi eliminandola. La cosa strana è che la connessione era vecchia di 15 minuti, ma il problema del blocco era presente da oltre 3 ore.

C'è qualcos'altro che posso controllare?

EDIT

Come per la risposta di Paolo di seguito. In realtà avevo rintracciato il problema prima che lui rispondesse. Pubblicherò i passaggi che ho usato per capire questo di seguito, nel caso in cui aiutano qualcun altro.

Le seguenti query sono state eseguite quando era presente un "periodo di timeout".

select * from sys.dm_exec_requests 

Come si può vedere, tutte le richieste di aspettare sono in attesa nella sessione 1021 che è la richiesta di replica! TM Request indica una transazione DTC e non utilizziamo transazioni distribuite. È anche possibile vedere il wait_type di SE_REPL_COMMIT_ACK che implica di nuovo la replica.

select * from sys.dm_tran_locks 

Sempre in attesa di sessione 1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc 

E sì, SE_REPL_CATCHUP_THROTTLE ha un tempo totale di attesa di 8094034 ms, ossia 134,9 minuti !!!

Vedere anche il forum seguente per dettagli su questo problema. http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

mi è stata data la seguente risposta nella mia comunicazione con Microsoft (che abbiamo visto questo problema con 4 dei nostri 15 banche dati nel data nell'UE centro):

Domanda: Avere sono stati apportati dei cambiamenti a questi limiti di limitazione della luminosità di nelle ultime tre settimane, ovvero dopo l'avvio dei miei problemi ?

Risposta: No, non c'è.

Domanda: Ci sono modi in cui possiamo evitare o essere avvisati che ci stiamo avvicinando a un limite?

Risposta: No. Il problema potrebbe non essere causato dall'applicazione ma può essere causato da altri tenant che si affidano allo stesso hardware fisico. In altre parole, l'applicazione può avere pochissimo carico e ancora incorrere nel problema. In altre parole, il tuo stesso traffico può essere una causa di questo problema, ma può essere causato anche da altri tenant che si affidano allo stesso hardware fisico . Non c'è modo di sapere in anticipo che il problema si verificherà presto - può verificarsi in qualsiasi momento senza preavviso. Il team operativo di SQL di Azure non monitora questo tipo di errore, pertanto lo standard non cercherà automaticamente di risolvere il problema. Quindi, se si esegue in esso si dispone di due opitions:

1. creare una copia del vostro db e l'uso che e spero il db è posto su un altro server con meno carico.

2. Contatto Windows Azure Supporto e informa quest'ultimo in merito al problema e far loro fare Opzione 1 per voi

Answer 1

Si potrebbe essere in esecuzione in SE_REPL * problemi che attualmente affliggono un sacco di gente usando Sql Azure (inclusa la mia azienda).

Quando si verificano i timeout, provare a controllare le vostre richieste di attesa per i tipi di attesa di:

• SE_REPL_SLOW_SECONDARY_THROTTLE
• SE_REPL_COMMIT_ACK

Eseguire il seguente per controllare i tipi di attesa sui collegamenti attuali:

SELECT TOP 10 r.session_id, r.plan_handle, 
r.sql_handle, r.request_id, 
r.start_time, r.status, 
r.command, r.database_id, 
r.user_id, r.wait_type, 
r.wait_time, r.last_wait_type, 
r.wait_resource, r.total_elapsed_time, 
r.cpu_time, r.transaction_isolation_level, 
r.row_count 
FROM sys.dm_exec_requests r 

È anche possibile ch ECK una storia di sorta per questo eseguendo:

SELECT * FROM sys.dm_db_wait_stats 
ORDER BY wait_time_ms desc 

Se stai vedendo un sacco di SE_REPL * aspettare tipi e questi sono rimanere impostate le connessioni per un certo periodo di tempo, poi in fondo sei fregato. Microsoft è a conoscenza del problema, ma ho avuto un ticket di supporto aperto per una settimana con loro ora e stanno ancora lavorando su di esso apparentemente.

L'attesa SE_REPL * si verifica quando gli slave di replica Sql Azure rimangono indietro. Fondamentalmente l'intero db sospende le interrogazioni mentre la replica raggiunge:/

Quindi essenzialmente l'aspetto che rende Sql Azure altamente disponibile sta causando l'indisponibilità casuale dei database. Riderei all'ironia se non ci stesse uccidendo.

Date un'occhiata a questo thread per dettagli: http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8