Query SQL semplici non terminate [chiuso]

Non so come formulare la domanda perché non sappiamo ancora molto, ma vorrei chiederlo prima o poi perché sembra qualcosa che non dovrebbe essere trascurato.

Questa settimana abbiamo iniziato ad avere problemi con il nostro server di database. Sembra essere un problema di coerenza dei dati e si manifesta con timeout anche su query molto semplici e tabelle di piccole dimensioni. Abbiamo "risolto" il problema riavviando il server all'inizio di questa settimana ed è andato via, ma ora sembra che stia tornando e questa volta su tabelle più cruciali. Ad esempio, ho appena svolto alcune indagini e sto esaminando una query come questa:

SELECT * FROM table WHERE id = 1234

per un determinato ID. La tabella ha circa 30+ milioni di righe. Ma sembra che accada solo per una piccola parte dei record. Scommetto che quando riavvio il server o eseguo il backup e ripristino il database su un altro server, andrà tutto bene. Ma proverò.

A questo punto, sto correndo:

DBCC CHECKTABLE ('table', NOINDEX)

ma sembra che funzionerà per sempre. Quando abbiamo affrontato i problemi per la prima volta, ho controllato il tavolo offensivo e andava bene. Questo nuovo tavolo è molto più grande.

Alcune informazioni tecniche di base:

• SQL Server 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlarge, 32 GB RAM, 4 x 1TB RAID 0
• quasi nessun disco IO, sembra che la maggior parte del db sia in memoria
• dimensione totale db: 100 GB

I volumi ELB sono nuovi di zecca. Li abbiamo creati questa settimana.

Modifica: ho appena usato il seguente comando:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

e ho scoperto che la mia query è in attesa di un blocco condiviso (LCK_M_S) in cui la sessione di blocco è in attesa di un altro blocco condiviso bloccato da una sessione che non esiste.

Modifica 2: OK, la sessione esiste (l'ho trovata usando sys.dm_exec_sessions), ma non sembra fare nulla ora.

Modifica 3: non riesco a trovare nulla di interessante sulla sessione. Vedo da quale server web proviene, ma non molto altro.

Modifica 4: Modifica 4: Abbiamo trovato un possibile bug nel nostro codice: una funzione che non assicurava la chiusura di una connessione al database. D'altra parte, sembrava che la transazione utilizzata dalla funzione venisse correttamente eliminata, nel qual caso tutti i blocchi avrebbero dovuto essere cancellati. Non è ancora molto chiaro per me, ma sembra essere la ragione probabile. Ripareremo il bug e lo terremo d'occhio.

Per me questo problema è stato causato da una connessione al database lasciata aperta da Visual Studio messa in pausa in modalità debug. L'arresto del processo di debug ha consentito il completamento immediato della query.

Qual è il tipo di attesa per la query quando è bloccata? Questo ti dirà esattamente cosa sta aspettando. Vai a trovare e installare sp_whoisactive sul server ed esegui la procedura memorizzata in caso di problemi. Questo ti mostrerà lo spid e ti darà il tipo di attesa.

Probabilmente sei bloccato da qualcuno che scrive su quella riga, o un'altra riga su quella pagina o stai aspettando che il disco risponda.

Prova a eseguire DBCC CHECKDBsul DB problematico e attendi fino al termine. Se c'è un'incoerenza dei dati fisici che produce un comportamento così strano, è troppo pericoloso lavorare con questo DB poiché potresti perdere tutti i tuoi dati.

1. Eseguire il backup il più presto possibile.
2. Controlla il DB.

MA

Se la tabella ha colonne BLOB con quantità relativamente grandi di dati, è assolutamente normale che i controlli su questa tabella richiedano molto tempo.

non sono sicuro di cosa ti aspetti come risposta, ma se la tabella ha oltre 30 milioni di righe, si prevede che il comando DBCC funzionerà a lungo.

Quando dici:

Ma sembra che accada solo per una piccola parte dei record

vuoi dire che sei preoccupato che l'intero tavolo non venga scannerizzato? È normale che se si dispone di un indice su ID, l'indice verrebbe scansionato e ciò comporterebbe meno letture.