FCI構成のSQL Serverがなぜか「フェイルオーバー」した（フェイルオーバートラブル）：SQL Serverトラブルシューティング（31）（2/2 ページ）

解決方法

　1号機は電源を再度入れても正しく起動しなかったことから、やはりハードウェア障害が発生していました。具体的には、ハードウェア保守ベンダーに連絡して調査してもらう必要があります。

　それと平行して、今後の対策と対処に必要な準備と確認をあらためて行います。

　一般的に、クラスタノードそのものが停止してしまうケースの場合は、SQL Serverの問題ではないところで起きるケースがほとんどです。ハードウェア障害で電源すら入らなくなるケースもあれば、ハードウェアドライバの問題でブルースクリーン（BSOD：Blue Screen of Death）になってOSが停止することもあります。なお、電源が突然落ちてしまう障害のケースではログ情報が残らないこともあるのですが、OSがハードウェアからの信号を受けて停止するケースならば、そのときの情報を残した後に停止します。その情報は「ダンプファイル」と呼ばれるファイルに保存されます。

　今後の対策と万が一時に備えた準備として、あらかじめOS側でメモリダンプを取っておくことが肝要です。ある時点のメインメモリの内容をディスクに残しておく「メモリダンプ（クラッシュダンプ）」は、OSがBSODで急停止した場合以外に、ユーザー側のコマンド操作で明示的に取得することも可能です。OSのメモリダンプについては以下の種類があります。

　OSのメモリダンプは「完全メモリダンプ」の取得を推奨します。

　その理由は、恒久対策のためです。最小メモリダンプ／カーネルダンプでは、障害解析のための情報が十分でないことがあります。完全メモリダンプを取得することで、最大限の障害情報を保全できます。

　なお、完全メモリダンプの取得には、以下の条件を満たしておく必要があります。

• ページファイルのサイズが、物理メモリのサイズ＋257MB以上ある
• システムドライブの空き容量が、上記ページファイルのサイズ以上に確保されている

　これらの条件が満たされない場合にはダンプファイルが正しく作成されないので注意してください。

　Windows Serverにおけるメモリダンプ取得の設定は、システムのプロパティ→詳細設定で開く「起動と回復」から行えます。デバッグ情報の書き込み欄から「完全メモリダンプ」を選び、ダンプファイル欄に保存先のディレクトリとファイル名を指定します（図24-2）。

図24-2　「起動と回復」から、取得するメモリダンプの種類と保存先を設定する（画面は、Windows Server 2012 R2の場合）

　今回はノード障害時におけるパターンと、その次を見据えた対策方法を紹介しました。障害によって発生した際のダンプファイルは、お使いのサーバを保守しているベンダーに併せて提出して、解析してもらうことで、ベンダー側の対策や早さ／確実さを含めて今後の対策につながります。

　なお、ダンプファイルの解析は高いスキルと経験が必要となります。本記事のカバー範囲を超えることから、ここでは「少なくとも押さえておく対策」の紹介に留めます。ダンプファイルについては、別の機会にまた紹介できればと思います。