5

(従来の理由により) SQL 2005 (9.0.5266) を実行し、TEXT 列 (さまざまなデータ型の他のいくつかの列と共に) を含む運用システムにテーブルがあります。

突然 (1 週間前から)、この 1 つのテーブルのサイズが 1 日あたり 10 ～ 15 GB ずつ直線的に増加していることに気付きました (以前は常に一定のサイズのままでした)。テーブルはメッセージング システムのキューであり、テーブル内のデータは数秒ごとに完全に更新されます。いつでも 0 行から約 1000 行の範囲である可能性がありますが、メッセージが挿入されて送信されると急速に変動します (その時点で削除されます)。

成長が始まった日に変更されたものは何も見つからないため、この段階では明らかな潜在的な原因は特定されていません.

「明らかな」原因の 1 つは TEXT 列であるため、大量の値が現在格納されているかどうかを確認しましたが、(DATALENGTH を使用して) 約 32k を超える単一の行は見つかりませんでした。CHECKDB を実行し、スペース使用量を更新し、すべてのインデックスを再構築しました。サイズは何も縮小されませんでした (CHECKDB はエラーを表示しませんでした)。

sys.allocation_units をクエリしたところ、サイズの増加は間違いなく LOB_DATA です (これは、total_pages と used_pa​​ges が一定の割合で一緒に増加していることを示しています)。

昨夜、データベースのサイズを縮小するために、問題のテーブル (幸いなことに、アプリケーションによってビューを介して参照されます) と一緒に新しいテーブルを作成し、古いテーブルを削除して、新しいテーブルの名前を変更しました。昨夜、スペースの問題を軽減し、今日さらに調査するための危険なテーブルのバックアップがあったという事実に安心して出発しました。ただし、今朝、テーブルのサイズはすでに最大 14 GB (および増加) になっていますが、テーブルには通常 ~500 行しかなく、MAX(DATALENGTH(text_column)) は約 35k しか示していません。

この「暴走」の成長を引き起こしている可能性のあるものについてのアイデア、またはスペースを正確に使用しているものについてより多くの情報を取得するために試行またはクエリできるその他のアイデアはありますか?

乾杯、デイブ

4

2 に答える 2

1

これは、キューを扱う際の一般的な問題です。リンクされた記事では Service Broker キューについて説明していますが、問題はキューとして使用される通常のテーブルでも同じです。十分なリソース (CPU、メモリ、ディスク IO) を備えたビジー状態のシステムがあり、このシステムのキューを高スループットにプッシュすると、これらのリソースの大部分が 2 つの操作を処理するために使用されます。 ) およびデキュー (つまり、DELETE)。ただし、レコードの完全なライフサイクルには3 つ必要です。操作: INSERT、DELETE、ゴースト パージ。CPU/メモリ/ディスク IO のニーズに関しては、それらのコストはほぼ同じであるため、そのキューをシステム リソースの 90% に使用する場合は、それぞれに 30% のリソースを割り当てる必要があります。ただし、制御できるのは最初の 2 つだけです (つまり、ユーザー セッションで実行される明示的なステートメント)。3 つ目のゴースト パージは、SQL Server によって制御されるバックグラウンド プロセスであり、ゴースト クリーンアップ プロセスが 30% のリソースを消費する可能性はありません。これは基本的な問題であり、ペダルを十分に長く踏み込むと、*がヒットします。ゴースト レコードが蓄積され、システム/ワークロード固有のしきい値を超えると、パフォーマンスが急速に低下し、症状が悪化してパフォーマンスが低下します (負のフィードバック ループが形成されます)。

幸いなことに、Service Broker キューではなく実際のテーブルをキューとして使用するため、 や などのより優れたツールを自由に使用できALTER TABLE REORGANIZEますALTER TABLE REBUILD。最良の解決策は、オンラインでのインデックス/テーブルの再構築です。SQL Server 2012 は、BLOB を含むテーブルでのオンライン操作をサポートしており、それを活用できます。もちろん、廃止された廃止されたTEXT型を取り除き、 を使用する必要がありますVARCHAR(MAX)が、それは言うまでもありません。

補足として：

ゴースト レコードしかないページがある場合、それらのページを再度読み取ることはなく、クリーンアップのマークも付けられません。

これは正しくありません。ゴーストしかないページは、スキャンによって検出され、パージされます。私が言ったように、問題は検出ではなく、リソースです。システムを十分にプッシュすると、ゴーストのクリーンアップに先んじて競争し、ゴーストが追いつくことはありません.

于 2012-08-17T12:04:34.890 に答える
0

今朝早く、この「問題キュー テーブル」を使用して、インスタンスで SQL サービスを再起動しました。これで問題が解決したようです。再起動直後に LOB_DATA の使用中ページ数を監視したところ、すぐに減少し始めました。かなりゆっくりとクリーンアップされていたので、保持されていた 60 GB 以上のスペースを再利用するのにおそらく 1 時間か 2 時間かかりました (すべて問題がないことを確認してから就寝しました)。

現時点では、テーブルは使用中の割り当て (100 ページ未満) に関しては正常に戻り、再成長の兆候は見られません。

このテーブルを少なくとも 10 年間同じように (キューとして) 使用しており、過去 1、2 週間よりも忙しい時期があったことを考えると、私は驚かれることでしょう。それが上記の Remus によって説明された問題である場合 (どのように発生するかは理解していますが、この特定のキューはゴースト クリーンアップ プロセスを圧倒するほど十分にビジーではないと思いますか?)。非常に奇妙な...

助けてくれてありがとう！

于 2012-08-20T22:10:02.563 に答える