Errore "periodo di timeout della richiesta di blocco superato" Errore durante il tentativo di visualizzare gerarchie di database

Sto riscontrando problemi con un database.

1. Sono in grado di eseguire query di base, anche se molto più lentamente del normale.

2. Quando provo a visualizzare gli alberi della gerarchia per tabelle, viste o procedure in Esplora oggetti SSMS, ottengo lock request time out period exceeded.

3. I miei report SSRS eseguiti su oggetti in questo database non vengono più completati.

4. Anche i lavori associati alle procedure memorizzate su questo database non vengono eseguiti.

Ho provato a usare sp_who2per trovare ed eliminare tutte le connessioni sul database, tuttavia questo non ha risolto il problema.

Cosa sta succedendo qui? Come posso risolvere questo?

Era stato causato da un perpetuo rollback di una transazione. Alla fine ho dovuto riavviare il mio cluster di server

Escludendo la considerazione di Harware, forse è necessario eseguire lo script per verificare quali sono le attività che trattengono la sessione SQL, uno degli scenari comuni è quello di non utilizzare un Implicit transactions Optionin SQL Server Management Studio.

Ho riscontrato questo problema quando ho iniziato una transazione esplicita in cui ho creato una tabella in tempdb da uno script in esecuzione in un altro database (non tempdb). Quando ho eseguito il commit della transazione, il commit non sembrava rilasciare il blocco sulla tabella che avevo creato in tempdb.

Grazie a questa pagina , ho USEeseguito tempdb ed eseguito DBCC OPENTRANe ottenuto lo SPID della connessione a tempdb che stava causando il blocco. Quindi io KILL <SPID number>per ucciderlo.

Non molto grazioso, e ho perso tutte le informazioni nella tabella che avevo creato in tempdb, ma nel mio caso era OK.

Ci sono così tante cose che potrebbero essere che tutto ciò che posso offrire sono alcune domande per aiutarti a orientarti verso una risposta.

1. Il DB su un server è dedicato solo all'esecuzione di SQL Server? In caso contrario, altri processi potrebbero interferire rubando tempo prezioso al processore.

2. Il server DB ha sostanzialmente memoria insufficiente? SQL Server tenterà di allocare ogni singolo byte possibile, ma se è a capacità e le tue query richiedono il caricamento di più dati, deve ricorrere all'utilizzo della memoria virtuale, il che aumenta radicalmente il tempo necessario anche alle query semplici.

3. La larghezza di banda della rete del server DB è troppo piccola per gestire il trasferimento dei dati in modo tempestivo?

Alla fine, sembra che la macchina su cui si sta ospitando SQL Server sia sottodimensionata per ciò che si sta tentando di fare. È del tutto possibile che tu abbia finalmente raggiunto quei limiti hardware in cui le prestazioni diminuiscono radicalmente. In questo caso (le domande precedenti ti aiuteranno a determinarlo), ti consigliamo di spostare il DB su un server che sia correttamente dimensionato per la quantità di dati (e query) che stai tentando di elaborare.

Ciò potrebbe significare l'utilizzo di processori più veloci, unità più veloci o semplicemente l'installazione di più RAM.

"Quando provo a visualizzare gli alberi della gerarchia per tabelle, viste o procedure in Esplora oggetti SSMS, ottengo il periodo di timeout della richiesta di blocco superato."

Ho avuto esattamente lo stesso problema. Sono andato alla finestra di esecuzione della query e; ROLLBACKdichiarazione digitata ed eseguita .

Sembra che alcune delle serie di dichiarazioni che stavo eseguendo prima, tenessero aperta la transazione. In particolare, perché alcuni di loro in cui dichiarazioni DDL. Dopo aver eseguito il rollback, le gerarchie di oggetti hanno iniziato a funzionare.

Come molti hanno già sottolineato, di solito c'è una transazione di lunga durata, principalmente causata dalla mia mancata SET ON TRANSAZIONI IMPLICIT ON, che non dovrebbe assolutamente essere utilizzata. Per capire perché consulta l'articolo approfondito di Brent Ozar

Ad ogni modo, è possibile ottenere un elenco di transazioni in sospeso di lunga durata utilizzando la seguente query.

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last Plan]
FROM
    sys.dm_tran_database_transactions [s_tdt]
JOIN
    sys.dm_tran_session_transactions [s_tst]
ON
    [s_tst].[transaction_id] = [s_tdt].[transaction_id]
JOIN
    sys.[dm_exec_sessions] [s_es]
ON
    [s_es].[session_id] = [s_tst].[session_id]
JOIN
    sys.dm_exec_connections [s_ec]
ON
    [s_ec].[session_id] = [s_tst].[session_id]
LEFT OUTER JOIN
    sys.dm_exec_requests [s_er]
ON
    [s_er].[session_id] = [s_tst].[session_id]
CROSS APPLY
    sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est]
OUTER APPLY
    sys.dm_exec_query_plan ([s_er].[plan_handle]) AS [s_eqp]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/