web-dev-qa-db-ja.com

本番システムでのDBCCの使用

Hyper-V VM（64GB RAM and 16 virtual cores）でSQL Server 2008 R2を実行しているシステムがあります。

システム内の別のVM（アプリケーションサーバー））は、クエリとデータ更新の両方で非常に集中的にdbサーバーにアクセスします。

特定のメンテナンスサブプランのストアドプロシージャが実行されたときに、アプリケーションサーバーで2つの主な例外が発生しました。

2つの例外は次のとおりです。

  1. System.Data.SqlClient.SqlException（0x80131904）：タイムアウトの期限が切れました。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません（.......）

  1. System.Data.SqlClient.SqlException（0x80131904）：指定されたバージョンID（1859）のアプリドメインは、メモリ不足のためにアンロードされ、見つかりませんでした。 （.....）

この時点で実行される保守計画ストアドプロシージャには、次のステートメントがあります。

DBCC FREESYSTEMCACHE ('ALL')
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
CHECKPOINT 
DBCC DROPCLEANBUFFERS

これは明らかにいくつかのテストの後に問題を引き起こしています。また、私はそれを発見しました：

  • タイムアウト例外はこれによって引き起こされます：

    CHECKPOINT 
DBCC DROPCLEANBUFFERS

  • これにより、メモリ不足の例外が発生します。

    DBCC FREESYSTEMCACHE ('ALL')
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

残念ながら、このメンテナンスタスクが発生する理由はわかりません。私の最初の考えはこのタスクを削除することですが、これらを実行しないことによってさらに問題が発生するかどうかはわかりません。

これらのDBCCコマンドは本当に必要ですか？

ありがとう

sql-serversql-server-2008-r2t-sqldbcctimeout
4
Fernando

まず、その仕事をしている人を見つけて、昼食をとっている間にチョークボードを引っかく猫の音を聞いている椅子に縛り付けます。

これを実行したら、ジョブの実行前後の長期間のリソース使用率とパフォーマンスデータを比較します。ジョブの実行後、perfのディップと多くのリソースが非常にビジーになると思います。ジョブを一時的に中断し、1週間注意深く監視して、何が起こるかを確認できます。問題が発生することはないと思いますが、prodシステムへのすべての変更と同様に、しばらくの間目を離さず、パフォーマンス、リソースの使用状況、および待機データを確実にキャプチャしてください。

これらのsprocは通常、特にパフォーマンステストのテスト環境で実行され、コールドスタートでの特定のクエリまたは全体的なワークロードの動作を確認します。また、システムの特定の部分が予期しない負荷スパイク、特にストレージをどのように処理するかを確認するためにも使用できます。

私たちは、標準のパフォーマンスチューニング方法が本番システムでこれらのことを行うことを含む単一のサポートエンジニアに出会いました。私たちは彼を十分に早く取り除くことができませんでした。これらすべてを本番システムで定期的に実行することは、サーバーを毎日再起動してサーバーを正常な状態に保ち、忙しい日の真っ最中に実行して最良の結果を得るのとほぼ同じです。

3
SQLmojoe

残念ながら答えはそれが依存することになるでしょう。メンテナンスプランにあるものから、サーバー統計、キャッシュ、および実行中の値を1日の特定の時刻にリセットしようとした人が、SQL Serverを実際に再起動せずにSQL Serverを最初に起動したときの状態にリセットしているようです。

CHECKPOINTは、メモリ内のすべてのダーティページをディスクに書き込むようにデータベースに指示します。デフォルトでは、SQL Serverはデータベースに対して自動チェックポイントを実行し、特定の時間内にデータベースのリカバリを実行できるようにします。詳細は MicrosoftのTechNet にあります。ディスクに書き込む必要のあるメモリ内のページが多く、ディスクI/Oサブシステムに追加の圧力がかかる可能性がある場合、これを手動で実行すると、かなり集中的なプロセスになる可能性があります。記事で説明されているCHECKPOINT間隔をチェックして、デフォルトの0から変更されているかどうかを確認することをお勧めします。

_DBCC DROPCLEANBUFFERS_は、すでにディスクからロードされている8KBページのメモリをすべて消去します。これにより、SQL Serverはディスクからメモリにデータを再読み込みし、メモリにデータが存在しない着信クエリを実行します。 MSのバッファ管理に関するTechNet記事 負荷の大きいマシンでこのコマンドを実行すると、ディスクI/Oサブシステムに負荷がかかり、タイムアウトが発生する可能性があります。

DBCC FREESYSTEMCACHE ('ALL')-SQL Serverが最後に再起動されてから構築されたすべてのキャッシュをクリアします。発生しているメモリ圧力の例外は、SQL Serverがプロシージャキャッシュを含むすべてのキャッシュをバックアップする必要があり、これも_DBCC FREEPROCCACHE_コマンドでクリアされます。これは、実行プランがまだ構築されていない場合に発生するすべてのクエリについて、実際にクエリを実行する前に、CPUとメモリに圧力をかけて実行プランを生成することを意味します。

FREESYSTEMCACHEとFREEPROCCACHEの違いに対する@Kinの回答

FREESYSTEMCACHEに関するTechNetの詳細

FREEPROCCACHEに関するTechNetの詳細

_DBCC FREESESSIONCACHE_-OPENROWSETおよびOPENDATASOURCEを使用する分散クエリのキャッシュを削除します。このコマンドの詳細は少しまばらです。 SQL SERVER CENTRALブログの投稿

結局のところ、コマンドは実際には、パフォーマンスのためにデータベースを調整している開発/テスト環境でのみ使用されるべきです。また、運用環境でこれらを使用する正当な理由がある場合もありますが、あなたがそれらを時々または定期的に使用する本当に良い理由がない限り、私はそれらがおそらくより多くの問題を引き起こしていて解決していると思います。しかし、それらが導入された理由の履歴を知らずに、データベーススキーマ/手順とアプリケーションを調査して、それらの理由があるかどうか、または理由があるかどうかを特定する必要があります。

1
Aaron