単純なSQLクエリが完了しない[終了]

質問の具体的な作り方はまだよくわからないのでよくわかりませんが、見過ごさないようになっているので、早めに質問したいと思います。

今週、データベースサーバーに問題が発生しました。これはデータの一貫性の問題のようであり、非常に単純なクエリや小さなテーブルでもタイムアウトによって明らかになります。今週初めにサーバーを再起動することで問題を「修正」し、サーバーはなくなりましたが、今では、より重要なテーブルでサーバーが戻ってきているようです。たとえば、私はいくつかの調査を行っただけで、次のようなクエリを見ています。

SELECT * FROM table WHERE id = 1234

特定のID。テーブルには約3,000万行以上あります。しかし、それはレコードのごく一部でのみ発生するようです。私はサーバーを再起動するか、別のサーバーにデータベースをバックアップおよび復元するときに、それはすべてうまくいくに違いない。でもやってみます。

この時点で、私は実行しています：

DBCC CHECKTABLE ('table', NOINDEX)

しかし、それは永遠に実行されるようです。初めて問題にぶつかったとき、問題のあるテーブルをチェックしたところ、問題はありませんでした。この新しいテーブルははるかに大きくなっています。

いくつかの背景技術情報：

• SQL Server 2008 R2、Windows Server 2008 R2
• AWS / EC2、m2.2xlarge、32 GB RAM、4 x 1TB RAID 0
• ほとんどディスクIOはありません。ほとんどのデータベースはメモリ内にあるようです
• 合計DBサイズ：100GB

ELBボリュームは「新品」です。今週作成しました。

編集：私は次のコマンドを使用しました：

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

私のクエリは、共有ロック（LCK_M_S）を待機していることを発見しました。ブロッキングセッションは、存在しないセッションによってブロックされた別の共有ロックを待機しています。

編集2：OK、セッションは存在します（私はを使用してそれを見つけましたsys.dm_exec_sessions）が、今は何も実行していないようです。

編集3：セッションについて興味深いことは何も見つかりません。私はそれがどのWebサーバーから来たのかはわかりますが、それ以外はあまりわかりません。

編集4：編集4：コードにバグがある可能性があります。データベース接続が閉じられていることを確認していない関数です。一方、関数が使用していたトランザクションは、正しく破棄されていたように見えました。この場合、すべてのロックがクリアされているはずです。それは私にはまだはっきりしていませんが、それが理由かもしれません。バグを修正し、監視します。

私にとってこの問題は、デバッグモードで一時停止されたVisual Studioによって開かれたままのデータベース接続が原因で発生しました。デバッグプロセスを停止すると、クエリをすぐに完了できます。

ハングしたときのクエリの待機タイプは何ですか？これは、それが待っていることを正確に教えてくれます。サーバーにsp_whoisactiveを見つけてインストールし、問題が発生したときにストアドプロシージャを実行します。これにより、spidが表示され、待機タイプが表示されます。

奇数は、その行またはそのページの別の行に書き込む誰かによってブロックされているか、ディスクが応答するのを待っていることです。

DBCC CHECKDB問題のあるDBで実行して、完了するまで待ちます。このような奇妙な動作を引き起こす物理的なデータの不整合がある場合、すべてのデータを失う可能性があるため、このDBで作業するのは危険です。

1. できるだけ早くバックアップを行ってください。
2. DBを確認してください。

だが

テーブルに比較的大量のデータを含むBLOB列がある場合、このテーブルに対するチェックに長い時間がかかることは絶対に正常です。

あなたが答えとして何を期待するのか本当にわかりませんが、テーブルに3000万以上の行がある場合、DBCCコマンドが長時間実行されると予想されました。

あなたが言う時：

しかし、それはレコードのごく一部でのみ発生するようです

テーブル全体がスキャンされていないのではないかと心配していますか？IDにインデックスがある場合、これは正常です。インデックスがスキャンされ、読み取りが少なくなります。