DB階層を表示しようとすると「ロック要求のタイムアウト期間を超えました」エラー

データベースに問題があります。

1. 通常よりはるかに遅くなりますが、基本的なクエリを実行できます。

2. SSMS Object Explorerでテーブル、ビュー、またはプロシージャの階層ツリーを表示しようとすると、が表示されますlock request time out period exceeded。

3. このデータベース内のオブジェクトで実行される私のSSRSレポートは完了していません。

4. このデータベースに保存されているプロシージャに関連付けられているジョブも実行されません。

私が使ってみましたsp_who2が、これは問題を解決していない、データベース上のすべての接続を見つけ、殺すために。

ここで何が起こっていますか？どうすれば解決できますか？

トランザクションの永続的なロールバックが原因でした。最終的にサーバークラスターを再起動する必要がありました

Harwareの考慮事項を除き、おそらく、SQLセッションを差し控えるアクティビティを確認するためにスクリプトを実行する必要があります。一般的なシナリオの1つは、Implicit transactions OptionSQL Server Management Studioで使用しないことです。

別のデータベース（tempdbではない）で実行されているスクリプトからtempdbにテーブルを作成する明示的なトランザクションを開始したときに、この問題が発生しました。トランザクションをコミットしたときに、tempdbで作成したテーブルのロックがコミットによって解放されなかったようです。

このページのおかげで、私はUSEtempdbを実行DBCC OPENTRANし、ロックを引き起こしていたtempdbへの接続のSPIDを取得しました。それから私KILL <SPID number>はそれを殺します。

あまり優雅ではなく、tempdbで作成したテーブルのすべての情報を失いましたが、私の場合はそれで問題ありませんでした。

これは非常に多くのことがあるので、私が提供できるのは、答えに導くためのいくつかの質問だけです。

1. SQL Serverの実行専用のサーバー上のDBですか？そうでない場合、他のプロセスが貴重なプロセッサー時間を盗むことによって干渉している可能性があります。

2. DBサーバーは基本的にメモリ不足ですか？SQL Serverは可能な限りすべてのバイトを割り当てようとしますが、容量に余裕があり、クエリでより多くのデータをロードする必要がある場合は、仮想メモリの使用にフォールバックする必要があり、単純なクエリでも時間が大幅に増加します。

3. DBサーバーのネットワーク帯域幅は、データをタイムリーに転送するために小さいですか？

結局のところ、SQL Serverをホストしているマシンは、やろうとしていることに対して十分なサイズになっていないようです。パフォーマンスが根本的に低下しているハードウェアの限界にようやく到達した可能性は完全にあります。この場合（上記の質問はそれを判断するのに役立ちます）、処理しようとしているデータ（およびクエリ）の量に適したサイズのサーバーにDBを移動する必要があります。

これは、より高速なプロセッサ、より高速なドライブを使用するか、単にRAMを増設することを意味します。

「SSMS Object Explorerでテーブル、ビュー、またはプロシージャの階層ツリーを表示しようとすると、ロック要求のタイムアウト期間を超過します。」

私はまったく同じ問題を抱えていました。クエリ実行ウィンドウに行きました。入力および実行されたROLLBACKステートメント。

その前に実行していた一連のステートメントの一部が、開いたトランザクションを保持しているように見えます。特に、それらのいくつかはDDLステートメントであるためです。ロールバックを発行すると、オブジェクト階層が機能し始めました。

多くの人がすでに指摘しているように、通常は長期にわたるトランザクションがあり、主にミスがSET IMPLICIT TRANSACTIONS ONを使用したため、まったく使用しないでください。なぜブレントオザーの洞察力に富んだ記事をご覧ください

とにかく、次のクエリを使用して、長続きする保留中のトランザクションのリストを取得できます。

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/