回答:
これがSQL ServerのPerfmonチュートリアルです。http：//www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/
その他のカウンターとしきい値については、クエストにいたときに行ったポスターを以下に示します。http：//www.quest.com/documents/landing.aspx？id = 11635
これは、グーグルのスポットで利用できる資料がたくさんある大きなトピックです。出発点として、これらは私が最初に見る傾向があるカウンターです：
プロセッサー–プロセッサー時間の割合
システム–プロセッサキューの長さ
おそらく、要求するすべてのDBAから、CPU使用率の異なるターゲット値を取得します。SQL Serverライセンスは高価であるため、一方ではCPUの使用率を最大化したい一方で、他方で可用性を犠牲にしたくはありません。ワークロードが十分に理解されている理想的な世界では、70％の使用率を目標とし、80〜90％で警告し、90％以上で警告することができます。ピークとトラフのワークロードで現実世界に戻ると、平均50〜60％をターゲットにする方が快適な場合があります。
メモリ–利用可能なMバイト
ページングファイル–使用率
専用のSQL Serverでは、インストールされているRAMに応じて、使用可能なメモリが100〜200 MB未満になると、OSが不足し、OSページングのリスクが生じる可能性があります。一般に、ページファイルのアクティビティはあまり見たくないので、使用率％が2％を超えているかどうか調査し、5％に達したかどうかを心配します。
バッファマネージャ–バッファキャッシュヒット率
バッファマネージャ–ページの平均寿命
これらのカウンターは両方とも、サーバーの確立されたベースラインに対してより適切に考慮されます。理想的には、キャッシュヒット率をできる限り100％に近づけ、PLEを数千秒で実行したいとします。彼らが過去の平均から離れるときは注意してください。
SQL統計–バッチリクエスト/秒
SQL統計–コンパイル/秒
SQL統計–再コンパイル/秒
1秒あたりの要求数は、サーバーの "ビジー"状態の相対的な目安です。コンパイル/再コンパイルの値が高い場合は、クエリのコンパイルでCPUサイクルが浪費されている可能性があります。
物理ディスク–平均 ディスク秒/読み取り
物理ディスク–平均 ディスク秒/書き込み
物理ディスク–ディスク読み取り/秒
物理ディスク–ディスク書き込み/秒
適切に構成されたIOシステムの大まかなガイドラインは、ログドライブの場合は<5ms（理想的には1ms）、データの場合は<20ms（理想的には<10ms）です。1秒あたりの読み取り/書き込みは、ドライブの既知の制限に対して考慮する必要があります。つまり、1000 IOPSの容量がある場合、平均IOPSが750に達したときにアップグレードオプションを評価します。