高可用Windowsシステムの研究 SQL Server 2005の高可用テクノロジ編 第3回　可用性向上のための機能と各種ツール群 2．可用性向上を支援するツール群 デジタルアドバンテージ 資料提供、技術協力：マイクロソフト 2007/05/30
Page1 Page2 Page3 Page4

　システムの可用性を向上させるためには、システムが健全な状態にあるかどうかを常にチェックし、異常が発生したらすぐにそれを検出できるようにすること、そして異常の原因を素早く特定し、問題を早期に解決することが重要である。SQL Server 2005では、これらの目的に役立つ各種ツールが提供されており、可用性の高いシステムの設計と運用を支援している。それらのうち主要なツールについて、以下で紹介しよう。

ログ収集ツール

　システムが刻々と生成するログは、システムの状態を診断する際、管理者にとって最も頼りになる情報の1つだ。SQL Server 2005は、自身が実行した処理やシステムの状況などに応じて、さまざまな情報をログとして生成する。SQL Server 2005が生成するログ（主要なもの）には次のようなものがある。

SQL Server 2005が生成するログ

SQL Server 2005は、実行した処理やシステムの状況などに応じて、さまざまな情報をログとして生成する。これらのうち、SQL Serverエラー・ログとWindowsイベント・ログ、SQL Serverエージェント・ログの3つについては、管理ツールのSQL Server Management Studio（以下Management Studio）で1画面に組み合わせて内容を確認できる。

SQL Serverエラー・ログ

　SQL Serverインスタンスの起動から終了までの活動記録をログとして生成し続けるのがSQL Serverエラー・ログである。具体的には、各種エラーの発生時、バックアップ取得および復元操作、自動復旧などの状態を記録する。このためSQL Serverエラー・ログを確認すれば、バックアップ操作や復元操作、バッチ・コマンド、そのほかのスクリプトやプロセスなどが正常に終了したかどうかを確認できる。

SQL Serverエラー・ログ

SQL Serverインスタンスの起動から終了までの活動記録がログとして出力される。画面はSQL Serverエラー・ログの情報をManagement Studioで表示したところ。

待ち受けしているネットワーク・ポートの情報。 　 SQL Serverのバージョン情報（ビルド番号）。 　 SQL ServerのセッションID。

　このSQL Serverエラー・ログには、SQL Serverのインスタンスが停止されてから再起動された場合の自動復旧メッセージやカーネル・メッセージなどが含まれているので、可用性向上という観点では、現在または潜在的に問題がある領域を検出するときに役立つ情報だ。

　SQL Serverで新しいインスタンスが起動すると、そのたびに新しいエラー・ログ・ファイルが作成される（デフォルトでは、「%Program Files%\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\」フォルダに作成される）。従って、インスタンスを再起動すれば、新しいエラー・ログ・ファイルを作成できるが、インスタンスを再起動したくないなら、sp_cycle_errorlogシステム・ストアド・プロシージャを使用すれば、インスタンスを起動したまま新たなエラー・ログ・ファイルを作成できる。SQL Serverを継続運用していると、エラー・ログ・ファイルのサイズが膨大になる。このsp_cycle_errorlogを使えば、インスタンスを再起動させることなく、エラー・ログ・ファイルを切り替えられる。

　SQL Serverは、ログのバックアップを新しいものから過去6個まで保持する（デフォルト時）。現在稼働中のインスタンスのログのファイル名はERRORLOG（拡張子なし）で、過去のログ・ファイルはERRORLOG.1、ERRORLOG.2と過去の世代数が拡張子として付けられる。

　なお、エラー・ログの管理世代数を増やす場合、Management Studioより、［管理］−［SQL Server ログ］を右クリックし、［構成］を選択する。続いて［再利用する前に、エラーログファイル数を制限する］のチェック・ボックスをオンにし、［エラー ログ ファイルの最大数］の値を変更すればよい。

SQL Serverエージェント・ログ

　「SQL Serverエージェント」は、スケジュールに従って「ジョブ」と呼ばれる管理タスクを実行するWindowsサービスである。このSQL Serverエージェントのジョブ情報は、SQL Serverを使用してデータベースに格納される。

　ジョブの実行状態に何か異常が発生すると、メッセージがSQL Serverエージェント・ログに書き込まれる。デフォルトでは、「エラー」と「警告」の情報が書き込まれる。以下は、SQL Serverエージェント・ログの内容をManagement Studioで表示したところだ。

SQL Serverエージェント・ログ

スケジュールに従って実行されるジョブに何らかの異常が発生すると、SQL Serverエージェント・ログに情報が出力される。

　システムの負荷増大やログ・データの肥大化の問題から、デフォルトでは有効になっていないが、必要なら、SQL Serverエージェントの実行トレース（ジョブ実行時の詳細な監査ログ）のメッセージを出力させることも可能だ。これは、特定の問題の原因を追究する場合などに役立つ。

　SQL Serverエージェント・ログの出力先は「Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\」フォルダ（デフォルト時）で、現在稼働しているエージェントのエラー・ログはSQLAGENT.OUTファイルに、過去のエラー・ログはSQLAGENT.nとして、拡張子（n）に世代が記録される。デフォルトでは、第9世代までのエラー・ログが保持される。

Windowsイベント・ログ

　周知のとおり、Windowsイベント・ログは、SQL Serverだけのログ情報を記録するのではなく、Windowsシステム全般のログ情報を記録するところである（コントロール・パネルの「イベント・ビューア」などでも、Windowsイベント・ログの情報を参照できる）。SQL Serverは、ハードウェアやネットワークなど、システムに関連する警告やエラーをWindowsイベント・ログに出力する。

　前述したとおり、Windowsイベント・ログは、コントロール・パネルのイベント・ビューアなどからも参照可能だが、SQL Server 2005付属のManagement Studioから参照することも可能だ。Management Studioを使えば、ログ・ファイル・ビューアから、これまでに説明したSQL Serverログ、SQL Serverエージェント・ログ、Windowsイベント・ログを同一のウィンドウで確認することも可能である。ログの分析では、時系列や事象ごとに複数のログ情報を追跡することになる。これら複数のログ情報を1つのウィンドウで参照すれば、追跡は非常に容易になる。

　Windows Server 2003では、デフォルトでアプリケーション・ログ（実行中のアプリケーションに関するログ情報）、システム・ログ（各種システム関連のログ情報）、セキュリティ・ログ（セキュリティ関連のログ情報）がWindowsイベント・ログとして出力される。SQL Serverの障害追跡などでは、SQL Serverの情報だけでなく、Windowsシステムやほかのアプリケーションの状態を併せて追跡する必要に迫られることが多い。Windowsイベント・ログと各種SQL ServerログをManagement Studioで組み合わせて表示すれば、こうした追跡がしやすい。例えば、データベース・システムに対する不正アクセスの影響を分析する際などは、Windowsイベント・ログのセキュリティ・ログとSQL Serverログを組み合わせることになるだろう。

Windowsイベント・ログ

Management Studioでは、Windows OSの標準ログであるWindowsログの情報も表示できる。SQL Serverログと組み合わせて分析することで、Windows OSの状態やほかのアプリケーションの状態、セキュリティ関連イベントとSQL Serverの事象を関連付けて分析することが容易になる。

ユーザー・ダンプ生成機能

　SQL Server 2005には、アクセス違反などの例外が生じたときに、自動的にダンプ・ファイル（SQL Serverが使用しているメモリ情報などを出力したファイル）を生成する機能がある。

　デフォルトでは、該当プロセスのスレッド・スタック・メモリの情報と、レジスタ・ダンプのみを含むミニダンプ（mini dump）だけが生成される。この場合、生成されるファイルのサイズは最大でも1Mbytes程度で、生成に必要なオーバーヘッドも非常に小さい（環境にもよるが、通常は無視できる程度）。しかしこの情報で不十分な場合には、トレース・フラグと呼ばれる情報を設定することで、プロセスの仮想アドレス空間内にコミットされているすべてのメモリを含むフルダンプ（full dump）を生成させることもできる。ただしこの場合、ダンプ・ファイルのサイズ、および生成にかかる負荷が大きくなる（フルダンプの実行時間は、ハードディスクの性能に大きく依存する）。またこの際には、メモリ上のスナップショットを取得する必要があるため、ダンプ・ファイルの書き出し中は、sqlservr.exeのプロセスがフリーズ状態になる。この間、実行中のクエリは一時的に停止され、新規ログイン要求は受け付けられなくなる。

　デフォルトのユーザー・ダンプの出力先は「%Program Files%\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\」フォルダである。ダンプ・ファイルは、このフォルダにSQLDmprXXXX.mdmpというファイル名で保存される（XXXXの部分は、現在フォルダにあるダンプ・ファイルと重複しないように、数値が増加される）。

　前述したように、通常ユーザー・ダンプは、アクセス違反が発生したときなどに自動的に生成される。しかし場合によっては、手作業でダンプを生成したいことがある。特定の状況で、SQL Server内部で何が起こっているかを調査するような場合だ。

　このような場合に備えて、SQL Server 2005には、Sqldumper.exeと呼ばれるコマンドライン・ツールが用意されている。コマンドラインからこのコマンドを実行すれば、その時点のプロセス・ダンプを取得することができる。実際、例外発生時の自動ダンプでは、内部的にはこのコマンドが呼び出されている。

　また、何らかの理由でSQL Serverがハングアップしてしまったときでも、このコマンドを実行すれば、ユーザー・ダンプを取得できる。

　コマンドのパラメータとしては、ダンプを取得したいプロセスのプロセスIDと、ダンプの種類（ミニダンプか、フルダンプか）を指定する。このためSqldumper.exeコマンドの実行では、目的とするプロセスのプロセスIDを調査しておく必要がある。これには、SQL Serverエラー・ログにある起動時の情報を確認するか、タスク・マネージャで［プロセス］タブを選択し、プロセスの一覧情報でプロセスID（PID）を確認してもよい。

　Sqldumper.exeの使用方法については、以下のサポート技術情報が詳しい。

• SQL Server 2005 でダンプ ファイルを生成するために、Sqldumper.exe ユーティリティを使用する方法

INDEX
	［高可用Windowsシステムの研究］
	第3回　可用性向上のための機能と各種ツール群
	1．可用性向上のための機能
	2．可用性向上を支援するツール群
	3．SQL Server／データベースの構成確認

　

［高可用Windowsシステムの研究］

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）