Erreur de dépassement du délai d'expiration de la demande de verrouillage lors de la tentative de visualisation des hiérarchies DB

J'ai des problèmes avec une base de données.

1. Je peux exécuter des requêtes de base, bien que beaucoup plus lentement que la normale.

2. Lorsque j'essaie d'afficher les arborescences de hiérarchie pour les tables, les vues ou les procédures dans l'Explorateur d'objets SSMS, j'obtiens lock request time out period exceeded.

3. Mes rapports SSRS qui s'exécutent sur des objets de cette base de données ne se terminent plus.

4. Les travaux associés aux procédures stockées dans cette base de données ne s'exécutent pas non plus.

J'ai essayé d'utiliser sp_who2pour trouver et tuer toutes les connexions sur la base de données, mais cela n'a pas résolu le problème.

Qu'est-ce qui se passe ici? Comment puis-je résoudre ça?

Elle était causée par l'annulation perpétuelle d'une transaction. J'ai finalement dû redémarrer mon cluster de serveurs

À l'exception de Harware, vous devrez peut-être exécuter le script pour vérifier quelles sont les activités qui bloquent la session SQL, l'un des scénarios courants est de ne pas utiliser un Implicit transactions Optiondans SQL Server Management Studio.

J'ai eu ce problème lorsque j'ai commencé une transaction explicite dans laquelle j'ai créé une table dans tempdb à partir d'un script exécuté dans une autre base de données (pas tempdb). Lorsque j'ai validé la transaction, la validation n'a pas semblé libérer le verrou sur la table que j'avais créée dans tempdb.

Grâce à cette page , j'ai USEcréé tempdb et exécuté DBCC OPENTRANet obtenu le SPID de la connexion à tempdb qui provoquait le verrouillage. Ensuite, je KILL <SPID number>le tuer.

Pas très gracieux, et j'ai perdu toutes les informations dans le tableau que j'avais créé dans tempdb, mais c'était OK dans mon cas.

Il y a tellement de choses que cela pourrait être que tout ce que je peux offrir sont quelques questions pour vous guider vers une réponse.

1. La base de données sur un serveur est-elle uniquement dédiée à l'exécution de SQL Server? Sinon, d'autres processus peuvent interférer en volant un temps processeur précieux.

2. Le serveur DB est-il essentiellement à court de mémoire? SQL Server tentera d'allouer chaque octet possible, mais s'il est à pleine capacité et que vos requêtes nécessitent davantage de données à charger, il doit alors recourir à la mémoire virtuelle, ce qui augmente radicalement le temps que même les requêtes simples peuvent prendre.

3. La bande passante réseau du serveur de base de données est-elle trop petite pour gérer le transfert des données en temps opportun?

À la fin de la journée, il semble que la machine sur laquelle vous hébergez SQL Server est sous-dimensionnée pour ce que vous essayez de faire. Il est tout à fait possible que vous ayez finalement atteint ces limites matérielles où les performances diminuent radicalement. Si tel est le cas (les questions ci-dessus vous aideront à le déterminer), vous souhaiterez déplacer la base de données vers un serveur correctement dimensionné pour la quantité de données (et de requêtes) que vous essayez de traiter.

Cela pourrait signifier utiliser des processeurs plus rapides, des disques plus rapides ou simplement installer plus de RAM.

"Lorsque j'essaie d'afficher les arborescences de hiérarchie pour les tables, les vues ou les procédures dans SSMS Object Explorer, le délai d'expiration de la demande de verrouillage est dépassé."

J'avais exactement le même problème. Je suis allé à la fenêtre d'exécution de la requête et; ROLLBACKinstruction tapée et exécutée .

On dirait que certaines des séries de déclarations que j'exécutais avant cela, ont tenu une transaction ouverte. Plus précisément, parce que certains d'entre eux contenaient des instructions DDL. Une fois que j'ai émis la restauration, les hiérarchies d'objets ont commencé à fonctionner.

Comme beaucoup l'avaient déjà fait remarquer, il y a généralement une transaction de longue durée, principalement causée par le manque utilisé SET IMPLICIT TRANSACTIONS ON, qui ne devrait pas être utilisé du tout. Pour voir pourquoi vérifier l'article perspicace de Brent Ozar

Quoi qu'il en soit, vous pouvez obtenir une liste des transactions en attente de longue durée en utilisant la requête suivante.

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/