1. ここからはじめる
SQL Server の状態取得
小澤 真之 (@Masayuki_Ozawa)

2. 自己紹介
2
 SQL Serve 関連の案件を中心に仕事をしていけるといいなと考え
ているフリーランスのエンジニアです。
 SE の雑記 というブログをやっています
http://blog.engineer-memo.com/
 SNS はこちら
 Twitter :
@Masayuki_Ozawa
 Facebook : http://www.facebook.com/masayuki.ozawa
2012/12/01SQLSaturday #181

3. 現状取得の重要性
2012/12/01SQLSaturday #1813
 突然こんなこと言われたことがありませんか？？
最近 サーバーが遅くなった
気がするんだけど、どうして？？

4. どうして突然遅くなった？？
2012/12/01SQLSaturday #1814
 データが増えた？？
 利生者数が増えた？？
 インデックスの断片化？？
 統計情報が古くなって最適な実行プランではない？？
 そもそも、遅くなったって何と比較して？？
 感覚値との比較？？
 サーバーの使用状況の変化を把握することで
何があったかを確認することが重要!!

5. レスポンス悪化時の
問題解決の 2 つのアプローチ
2012/12/01SQLSaturday #1815

6. 二つのアプローチ
2012/12/01SQLSaturday #1816
• クエリの実行プランの最適化
• インデックスチューニング
• ロックの最適化 ……
クエリ最適化 (部分最適)
• ハードウェアリソースの使用状況の最適化
• CPU / ディスク / メモリ /ネットワーク
• 待ち事象 (Wait Stats / Latch Stats) ……
サーバー最適化 (全体最適）
処理が遅い画面が分かっている
全体的 / なんとなく遅い
今回の内容

7. ここからはじめてみてはどうでしょう
2012/12/01SQLSaturday #1817

8. 基本情報を取得するからはじめてみる
2012/12/01SQLSaturday #1818
 リソースの基本情報を正しく取得 / 整理する
ところから、はじめてみてはどうでしょう。
 サーバーの基本的なリソース
 CPU
 ディスク
 メモリ
 ネットワーク

9. このグラフをどう見ますか？？
9
 以下のようなディスクの使用率のグラフがあります。
ディスクがボトルネックになっているでしょうか?
Disk Read が頻繁に発生
Disk Queue が頻繁に発生
Disk Write は定期的に発生
Logical Disk : Current Disk Queue Length
Logical Disk : Avg. Disk Bytes/Read
Logical Disk : Avg. Disk Bytes/Write
2012/12/01SQLSaturday #181

10. ボトルネックになっているのは？？
2012/12/01SQLSaturday #18110
1. ディスクのスペックが不足している
2. CPU のスペックが不足している
3. メモリのサイズが不足している
4. わからない
私の回答はこれ

11. 各リソースの情報をどう読む?
11
 CPU
 サーバー全体の CPU の使用率
 SQL Server のプロセスの CPU の使用率
 コンパイル / リコンパイルの発生状況
 CPU キュー
 メモリ
 サーバーの使用可能な空きメモリ
 SQL Server のメモリ使用状況
 キャッシュヒット率
 ディスク
 ディスク読み込み / ディスク書き込み
 (ディスクキュー)
 ネットワーク
 受信バイト / 送信バイト
 ネットワークキュー
2012/12/01SQLSaturday #181

12. キホンのキホン
2012/12/01SQLSaturday #18112
 瞬間値や平均値ではなく時系列にデータを整理する
 瞬間値 (最大値) は有効なデータになりえます？？
 瞬間的に 100% に達するのは問題でしょうか??
 リソースを有効に使っているという見方もできます。
 リソースの使用状況を 波形 で見れるようにするのが重要
 100% に張り付いた状態が継続していないことを確認
 ピーク時間とオフピーク時間のリソースの使用状況を確認
 複数のリソースの情報を組み合わせて確認する
 一つのリソースだけで判断しないことがポイント
先ほどわからないといった理由はこれ

13. たとえばこのようなことが考えられます
2012/12/01SQLSaturday #18113
 ディスク
 ディスクの書き込みではなく読み込みの頻度が多い
→ ディスク / メモリがボトルネックになりえる
 CPU
 ユーザーが増えたことにより再利用されない SQL が頻繁に実行され、コンパ
イルの発生が頻発し CPU が 100% になっている
→ CPU / メモリがボトルネックになりえる
 メモリ
 データの増加によって、メモリが不足して頻繁にデータがディスクから読み込
まれている
→ メモリ / ディスクがボトルネックになりえる

14. 使用するツール
2012/12/01SQLSaturday #18114

15. 現状を見るために使用するツール
15
 SQL Server 2000
 Undocumented DBCC
 システムテーブル
 OS のパフォーマンスモニター
 SQL Server 2005
 動的管理ビュー (DMV)
 SSMS の標準レポート
 SQL Server 2005 Performance Dashboard Reports
 SQL Server 2008 / R2 / SQL Server 2012
 データコレクション (ただし、Enterprise Edition)
 SQL Server 2008 以降は SQL Server の機能でパフォーマンス状態のレポートが作れるよ
うになりました
 拡張イベント (XEvent)
今回はこれ
これも少し
2012/12/01SQLSaturday #181

16. データコレクションの画面例
16 2012/12/01SQLSaturday #181

17. パフォーマンスモニタとは？？
17
 リアルタイムのパフォーマンス情報
 現状を確認するときに使用します
 パフォーマンス情報のログの取得
 ベースラインを作成するときに使用します
 リモート (別のコンピュータ) からも取得できます
 サーバーのディスク容量が無くても別のコンピューターにログを取得できます
 SQL Server 固有のカウンタならメモリの情報を取得できます
 タスクマネージャーでメモリの使用状況が取得できなくても、SQL Server 固
有のカウンタからはメモリの使用状況を取得することができます。
2012/12/01SQLSaturday #181
エディションに依存せずに
使用できるので
どの環境でも情報を取得可能

18. データ取得時の環境例
18
モニタリング端末
PerflogUser
(Performance Log User)
(Performance Monitor User)
モニター対象
PerflogUser
(Performance Log User)
(Performance Monitor User)
ログ取得ディレクトリ
別端末から取得
同一ユーザー名 / 同一パスワード
(ワークグループ環境のため)
2012/12/01SQLSaturday #181

19. パフォーマンスモニタで取得する項目の例
19
 「SQL Server Perlman Counters Poster」でビングってください
 Quest Software さんから SQL Server のパフォーマンスモニタのカウンタに
ついて、まとまった情報が公開されています
2012/12/01SQLSaturday #181

20. 最初にすること
2012/12/01SQLSaturday #18120

21. こういうデータを見ていませんか？
21
 最大 / 最小 / 平均を表にする
 タスクマネージャーで確認
CPU Memory
最大 最小 平均 最大 最小 平均
9:00 50% 10% 40% 10GB 10GB 10GB
10:00 90% 10% 80% 10GB 10GB 10GB
11:00 96% 15% 90% 10GB 10GB 10GB
sqlservr.exe の
状態を確認
2012/12/01SQLSaturday #181

22. データの読み方
22
4 つのポイント
1. 波形を見る
2. 同じ種類の複数の情報を重ねる
3. 違う種類の情報と比較する
4. 比率を見る
2012/12/01SQLSaturday #181

23. 波形を読む
23
波形から
CPU 使用率の
高い時間を把握
Processor : %Processor Time (_Total)
2012/12/01SQLSaturday #181
ピークタイム (高負荷) と
オフピークタイム (低負荷) の
状態を確認する

24. 同じ種類の複数の情報を重ねる
24
Processor : % Processor Time (_Total)
Process : % Processor Time (sqlservr)
プロセッサの使用率の波形と
SQL Server のプロセスの
波形が一致
2012/12/01SQLSaturday #181
SQL Server のプロセスが
CPU を多く使用している
ことが読み取れる

25. 違う種類の情報と比較する
25
Buffer Manager : Buffer Cache Hit Ratio
Plan Cache : Cache Hit Ratio
Buffer Manager : Page life expectancy
データのキャッシュヒット率
メモリが不足していると低い
クエリのキャッシュヒット率
アドホッククエリが多いと低い
メモリ内のデータでどの程度の
時間処理ができているか
300秒以上が一般的な推奨値
2012/12/01SQLSaturday #181
どの用途のメモリが
不足しているかを確認

26. 比率を見る
26
SQL Server の使用メモリ
サーバー上の空きメモリ
SQL Server 以外の使用メモリ
Memory : Available MBytes
Process : Working Set (sqlservr 以外)
Memory Manager : Total Server Memory (KB)
2012/12/01SQLSaturday #181
全体のメモリに対して
どの程度使用しているか

27. SQL Server のメモリ構造
27
Buffer Manager : Database Pages
Plan Cache : Cache Pages
Memory Manager : Connection Memory (KB)
Memory Manager : Granted Workspace Memory (KB)
Memory Manager : Lock Memory (KB)
一時利用
キャッシュ
2012/12/01SQLSaturday #181

28. 一歩踏み込んでメモリの状態を確認
28
プロシージャキャッシュ
Buffer Manager : Free pages
Buffer Manager : Database Pages
Plan Cache : Cache Pages (_Total)
※各値はページ数なので 8KB をかける
※SQL Server 2012 ではカウンタ名少しが変わっています
データキャッシュ
2012/12/01SQLSaturday #181
フリーページ
SQL Server が確保している
メモリでも内部的には
空きがあることが

29. DMV でさらにブレークダウン
29
 データキャッシュの詳細は [sys].[dm_os_buffer_descriptors] で
 プロシージャキャッシュの詳細は [sys].[dm_exec_cached_plans] で
2012/12/01SQLSaturday #181
DB 単位のメモリの
使用状況を取得
用途単位でメモリの
使用状況を取得

30. 最初のグラフを改めて見直すと
30
Disk Read が頻繁に発生
Disk Queue が頻繁に発生
Disk Write は定期的に発生
Logical Disk : Current Disk Queue Length
Logical Disk : Avg. Disk Bytes/Read
Logical Disk : Avg. Disk Bytes/Write
2012/12/01SQLSaturday #181

31. 組み合わせると見えてくる!!
31
 データキャッシュのヒット率が低いとディスクからデータの読み込み
が発生しているので、ディスク負荷が高くなる傾向に
 プランキャッシュのヒット率が低いとコンパイルの発生回数が多くな
るため、CPU 負荷が高くなる傾向に
 ディスク / CPU の値が高くてもメモリネック
の場合があります。
 このような場合は、違う種類の情報を比較する
ことが重要です。
2012/12/01SQLSaturday #181

32. 使い分けが重要
32
 パフォーマンスモニタは現状を俯瞰するのが得意です
 各カウンターで現状を取得して、特異点があれば DMV でブレークダウン
 DMV は現状の状態詳細に取得するのが得意です
 DMV の情報はサービスを再起動すると初期化されるのでログとして取得する
場合はユーザー定義のデータコレクションまたは、定期的にクエリを実行して
テーブルに格納することで対応
 拡張イベントはイベントを取得するのが得意です
 今回は紹介できていませんが拡張イベントでは内部動作を取得できます。
 セッション単位の待ち事象 (Wait Stats / Ratch Stats)
 ブロッキング (ロックの競合)
2012/12/01SQLSaturday #181

33. 33 2012/12/01SQLSaturday #181

34. さらに踏み込みたい方は
2012/12/01SQLSaturday #18134

35. 実行状態の遷移
2012/12/01SQLSaturday #18135
実行状態
(RUNNING)
実行可能状態
(RUNNABLE)
待機状態
(SUSPENDED)
処理を実行している状態
CPU
メモリ
ディスク
処理を待機している状態
ロック
並列処理同期
ディスク I/O
待機がなくなり処理の開始待ち
CPU 使用権の譲渡
キューの解放

36. 待機状態の理由を考える
2012/12/01SQLSaturday #18136
 実行状態が長い = 処理に時間がかかる
 どの処理で時間がかかっているかを確認
 実行プランのイテレータを確認
 sys.dm_exec_requests (実行中の要求) で確認することができます。
 待機状態が長い = リソースを使用できる状態になるのに時間がかかる
 どのリソースを使用可能な状態になるのに時間がかかっているかを確認
 sys.dm_os_wait_stats (待機の累計) で確認をすることができます。

37. 最初の一歩は利用状況モニターから
2012/12/01SQLSaturday #18137

38. 詳しく知りたい方はこちらを
2012/12/01SQLSaturday #18138
 SQL Wait Stats Joes 2 Pros: SQL Performance Tuning
Techniques Using Wait Statistics

39. まとめ
39
 パフォーマンスモニターの勘所がわかれば状態取得ははじめられます
 インデックスチューニング / DMV 詳細確認は難しいかもしれませんが、基本的な情
報を取得して整理するところからはじめてみてはどうでしょう。
 取得したデータを読むときは単純な値を控えるのではなく波形や複数の情報
を組み合わせることが重要になってきます
 組み合わせることで見えてくる事象があります。
 定期的にベースラインと現状を比較し、負荷があがっているかを判断するの
が予防保守として重要になってきます
 ベースラインを作成したら終わりではなく定期的にベースラインとの比較をするのが
大事です
 急に遅くなっていないことを証明するための予防線
2012/12/01SQLSaturday #181