Skip to content

MS_SQLServerLog

Jump to bottom
nishi_74322014 edited this page Aug 13, 2026 · 2 revisions

SQL Server のログ

概要

SQL Server のログについて纏めてみた。

詳細

SQLトレースとSQLプロファイラ

SQLトレース

  • トレース定義に一覧表示されているイベント クラスのインスタンスである
    イベントが収集する。
  • Transact-SQL のインスタンスでトレースを作成するための
    ストアド プロシージャが用意されている。

SQLプロファイラ

SQL トレースを作成および管理し、トレースの結果を分析および再生するために
使用するインターフェイス。

バイナリ・ファイルのテキスト化

ログ収集いろいろを参照。

移行メモ（最新化：SQL トレースは非推奨）: SQL トレースと
SQL Server Profiler は非推奨であり、後継は
拡張イベント（Extended Events / XEvent） である。

SQL トレース 拡張イベント
オーバーヘッド 大きい（本番で常用しづらい） 小さい
GUI SQL Server Profiler SSMS の XEvent セッション
既定の常時収集 無し system_health セッションが常時稼働
将来 削除予定（Analysis Services 向けは除く） 現行

特に system_health は既定で動いており、
デッドロック グラフや重大エラーが何もしなくても記録されている。
障害後の後追い調査ではまずここを見るのが現在の定石である。
本ページ以降の「どのイベントを取るか」という考え方自体は、
拡張イベントでもそのまま通用する。

エラー ログ

SQL Server のエラー ログには、

があるもよう。

SQL Server ログ

（元ページに本文の記載なし）

補足（ERRORLOG の基礎）: SQL Server ログの実体は
インスタンスの LOG フォルダー配下の ERRORLOG（テキスト）である。

事項 内容
場所 ...\MSSQL\Log\ERRORLOG（SERVERPROPERTY('ErrorLogFileName') で取得可）
世代 既定 6 世代 + 現行。サービス再起動で切り替わる
参照 SSMS の［管理］－［SQL Server ログ］、または sp_readerrorlog
明示的な切り替え EXEC sp_cycle_errorlog

既定では再起動時にしかローテートしないため、
長期間再起動しないインスタンスでは 1 ファイルが巨大になって開けなくなる。
sp_cycle_errorlog を日次のジョブに入れ、世代数を増やしておくのが
実務上の定石である。

Windowsのイベント・ログ

イベント・ログを参照。

参考

クエリストア

補足（クエリ ストアは「性能のフライト レコーダー」）: クエリ ストアは
クエリのテキスト・実行プラン・実行統計を DB 内に永続化する機能で、
本ページの他の手段とは性格が異なる。

SQL トレース / XEvent クエリ ストア
取り方 事前に仕掛ける必要がある 既定で常時記録（2022 以降の新規 DB）
分かること 起きたこと プランが変わって遅くなったという履歴
対処 － プランの強制（sp_query_store_force_plan）

「昨日まで速かったクエリが今日から遅い」という
プラン リグレッションの調査・応急処置に直接効くため、
現在はSQL Server のオプティマイザまわりの調査の
第一手段になっている（SQL Server のオプティマイザ）。

パフォーマンス ログ

SQL トレース ログに加えて、パフォーマンス カウンタを選択、
パフォーマンス ログを取得し、
問題（リソース消費量が多い処理は何処か？）を特定できる可能性がある。

移行メモ（誤字）: 元ページは「ソース消費量が多い処理」と記しているが、
文脈から「リソース消費量」である。

SQL Serverの一般的なカウンタとしきい値：その1

# リソース オブジェクト：カウンタ カウンタの説明 「しきい値」を超える条件 対策
1-1 メモリ SQL Server:
Memory Manager:
Total Server Memory (KB) 		SQL Server のバッファ プールが使用しているメモリ量 サーバの物理メモリ容量に比べて高い メモリを増設する
2-1 バッファ
キャッシュ		 SQL Server:
Buffer Manager:
Free pages 		バッファ プールの未使用ページリスト（Free Page List）にあるページの総数 4 ページ以下 メモリを増設する
2-2 〃 SQL Server:
Buffer Manager:
Buffer cache hit ratio 		バッファ キャッシュのヒット率 90% 以下 メモリを増設する
2-3 〃 SQL Server:
Buffer Manager:
Page Life expectancy 		バッファ プール内で、ページが参照されなくても保持される秒数 300 秒以下 メモリを増設する
3-1 ディスク SQL Server:
Buffer Manager:
Page Reads/Sec 		バッファ マネージャによる、ディスク上の読み取り回数/秒 ディスクの仕様で規定されている最大値に近い ・メモリを増設する
・ハードウェアの I/O 容量を増やす
・非正規化、インデックスの使用など、I/O 操作が減るようにアプリケーションまたは DB を調整する
3-2 〃 SQL Server:
Buffer Manager:
Page Writes/Sec 		バッファ マネージャによる、ディスク上の書き込み回数/秒 〃 ハードウェアの I/O 容量を増やす

備考

  • Total Server Memory: この値は仮想メモリもカウントするため、
    サーバの物理メモリ容量を超えることがある。
    タスク マネージャでは示されない、AWE のメモリ使用状況も提供される。
  • Free pages: メモリ不足の場合、レイジー ライター
    （実行プランのキャッシュに必要なメモリを管理する）
    あるいはチェック ポイントなどの処理を保持できなくなる可能性がある。
  • Buffer cache hit ratio: 100% に近いほど適正。
  • Page Reads/Writes/Sec: 一般的に、Ultra Wide SCSI ディスクは
    毎秒 50 ～ 70 回の I/O 操作を処理できる。

補足（現在の目安に読み替える）: 本表のしきい値は
HDD・32bit 時代の目安である。現在は次のように読み替えたい。

カウンタ 当時の目安 現在の見方
Buffer cache hit ratio 90% 以下で警戒 ほぼ常に 99% 以上になり、指標として使えない
Page Life expectancy 300 秒 固定値ではなく**「急落したか」を見る**（NUMA ノード別に見る）
Page Reads/Sec 50〜70 IOPS NVMe SSD なら数万 IOPS。台数ではなくレイテンシ（Avg. Disk sec/Read < 数 ms）で見る

また現在は、パフォーマンス カウンタより
待ち事象（sys.dm_os_wait_stats）から入るのが定石である
（「何を待っているか」が分かれば、
CPU / メモリ / I/O / ロックのどれが原因かを絞り込める）。

SQL Serverの一般的なカウンタとしきい値：その2

# リソース オブジェクト：カウンタ カウンタの説明 備考
1-1 負荷
（トランザクション）		 SQL Server:
Databases:
Transactions/sec 		DB で開始されたトランザクションの数/秒 この数値はシステム規模の参考になる。また、トランザクション負荷の増減をチェックするのにも役立つ
1-2 〃 SQL Server:
Databases:
Active Transactions 		現在の DB で、アクティブなトランザクションの数 Transactions/sec が (_Total) Active Transactions を超える場合、サーバの負荷が超過状態であることを示す
1-3 〃 SQL Server:
General Statistics:
User Connections 		SQL Server に現在接続しているユーザ数 この値の大幅な変動には注意すべき
2-1 インデックス SQL Server:
Access Methods:
Full Scans/Sec 		フル スキャンの数/秒 この値が大きくなる場合、アプリケーションがインデックスを効率的に使用していないことが考えられる。原因となるクエリを調べ、必要に応じてインデックスを作成する。tempdb はほとんどインデックス付けされないため、高くなることがある
2-2 〃 SQL Server:
Access Methods:
Index Searches/Sec 		インデックス検索数/秒 データ アクセスのパターンをチェックできる。インデックスは「範囲スキャン」「単一インデックス レコードのフェッチ」「インデックスの中で再度位置付け」に使用される
2-3 〃 SQL Server:
Access Methods:
Page Splits/Sec 		ページ分割回数/秒 性能上問題となるページ分割の回数をチェックできる
3-1 ロック SQL Server:Locks:
Average Wait Time (ms) 		待ち状態の原因となる各ロック要求の平均待ち時間 状況の監視に使用する
3-2 〃 SQL Server:Locks:
Lock Waits/Sec 		ロック取得のために待機しなければならない要求の数/秒 〃
3-3 〃 SQL Server:Locks:
Lock Timeouts/sec 		タイムアウトしたロック要求の数/秒 NOWAIT ロックの要求を除く
3-4 〃 SQL Server:Locks:
Number of Deadlocks/sec 		デッドロックに帰着するロック要求の数/秒 〃
3-5 〃 SQL Server:Latches:
Average Latch Wait Time 		ラッチ要求の平均待ち時間 ラッチは、負荷の軽い短期の同期化オブジェクトで、トランザクション全体にわたってロックする必要がない動作を保護する。この数値が大きくなると、サーバがリソースを求めて競合に巻き込まれる恐れがある
4-1 その他 SQL Server:
SQL Statistics:
SQL Compilations/Sec 		SQL コンパイルの回数/秒（再コンパイル含む） 利用状況が安定したら通常この値は安定する。再コンパイルは「スキーマの変更」「大量 INSERT / DELETE」などで発生する。常に高い場合は調査が必要（アドホック クエリ問題の監視）
4-2 〃 SQL Server:
SQL Statistics:
SQL Re-Compilations/Sec 		クエリの再コンパイルの回数/秒 〃
4-3 〃 SQL Server:
Memory Manager:
Memory Grants Pending 		作業領域メモリの使用許可を待っている処理の数 アドホック クエリ、結合方法の問題の監視に使用できる
4-4 〃 SQL Server:
Buffer Manager:
Stolen Page Count 		他のサーバ メモリ要求によって奪われたバッファ キャッシュのページの数 〃

移行メモ（カウンタの所属オブジェクト）: 元ページは
Memory Grants Pending を「Buffer Manager」に分類しているが、
実際には SQLServer:Memory Manager オブジェクトのカウンタである
（Stolen Page Count は Buffer Manager で正しい）。
また SQL Server：Latche は Latches の誤記である。

参考

SQL Troubleshooting

MSDN Blogs > Microsoft SQL Server Japan Support Team Blog > SQL Troubleshooting
（SQL Server トラブルシューティング 6 回シリーズ）

  1. SQL Server エラーログとイベント ログを採取する
  2. パフォーマンス ログの採取方法
  3. パフォーマンス ログの確認方法について
  4. サーバートレースの解析方法 1
  5. サーバートレースの解析方法 2
  6. ブロッキング情報の確認方法

補足（現在の一次情報）: 上記の MSDN Blogs は
移転・失効しているものが多い。現在は次を参照する。

関連

Tags: 移行, データアクセス, SQL Server, 障害対応, 性能, デバッグ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally