2

数日おきに使用できなくなるデータベース（データベースAと呼びましょう）があり、再起動する必要があります。私が使用できないと言うときは、それを使用するすべてのアプリケーションが、データベースが応答するのを待ってそこでブロックするだけですが、決して応答しません。

幸運なことに、SQL Server Management Studioを使用して特定のテーブルに対してSELECTステートメントを実行すると、いくつかのレコードが表示されるように見えますが、ある時点でブロックされます。

面白いのは、特定のデータベースにLOCKEDまたはLOCKINGプロセスがないことです。アプリケーションが次のトランザクション分離を使用していることがわかりました。

ALLOW_SNAPSHOT_ISOLATION ON

LockedまたはLockingプロセスが正しく表示されない理由を説明していますか？

実際には同じスキーマを持つ別のデータベース（データベースBと呼びましょう）があり、この問題は発生していません。これらのデータベースの唯一の違いは、前述の分離です。これはデフォルトのトランザクション分離を使用しており、データベースがブロックされるという奇妙なことは一度もありませんでした。しかし、データベースAには、1日あたりに開かれるトランザクションがはるかに多くあります。はるかに。したがって、私が考えることができるのは、この場合、多数の同時トランザクションではSNAPSHOTISOLATIONを回避する必要があるということです。

誰かが問題を引き起こしているのはSNAPSHOTISOLATIONである可能性が高いことを確認できますか？つまり、ロックはなく、データベースがブロックされているだけで、実際の例外や問題の根本原因を検出するのに役立つものはありません。

私の仮定は正しいですか？きっとそう願っています。

4

1 に答える 1

2

tempdbの使用状況を監視しようとしましたか？（AFAIK、ALLOWSNAPSHOT_ISOLATION ONはtempdbに大きく依存していますが、これは標準のロック戦略には当てはまりません）

このMSTechnetページには、これを行う方法に関するヒントがいくつか記載されています（「スペースの監視」のセクションを参照）。

このクイッククエリを使用して、tempdbがいっぱいでないことを確認することもできます。

   use tempdb
   exec sp_spaceused
于 2009-12-20T14:14:39.917 に答える