プロアクティブなSQLServerヘルスチェック、パート4：エラーログ

歴史と重要性について言えることはたくさんあります。国の歴史、文明の歴史、私たち一人一人の歴史。私は引用が大好きで、Teddy Roosevelt（かっこいい男）からの引用が好きです：

SQL Serverに関するブログで、歴史について詩的（またはしようとしている）なのはなぜですか？ SQLServerの履歴も重要だからです。 SQL Serverにパフォーマンスの問題が存在する場合は、問題をライブでトラブルシューティングするのが理想的ですが、場合によっては、履歴情報が喫煙者、または少なくとも出発点となる可能性があります。 SQL Serverの履歴情報の優れた情報源は、ERRORLOGです。私の元の投稿「パフォーマンスの問題：最初の遭遇」で、ERRORLOGは私にとって後付けであったと述べました。もういや。クライアントの監査中、私たちは常にERRORLOGをキャプチャし、重大度の高いアラート（ログに書き込まれる）があれば通知されますが、ログで他の興味深い情報を見つけることは前例のないことではありません。ログの履歴情報を使用して、将来に備えます。この情報は、問題が壊滅的になる前に、問題または潜在的な問題を修正するのに役立ちます。

エラーログの表示

まず、ERROLOGを表示するためのいくつかのオプションを確認します。インスタンスに接続している場合は、通常、SSMSを介してそのインスタンスに移動します（[管理]、[SQL Serverログ]、ログを右クリックして、[SQL Serverログの表示]を選択します）。このウィンドウから、ログをスクロールするか、[フィルター]または[検索]オプションを使用して結果セットを絞り込むことができます。左側のペインで複数のファイルを選択して表示することもできます。

ヘルス監査の1つでキャプチャされたデータを表示している場合は、テキストエディタでログファイルを開いて確認します（ビューアにアクセスしてロードすることもできます）。ログファイルは、サーバーで確認したい場合は、ログフォルダー（デフォルトの場所：C：\ Program Files \ Microsoft SQL Server \ MSSQL12.SQL2014 \ MSSQL \ Log）にあります。多くの場合、文書化されていないプロシージャsp_readerrorlogまたは拡張ストアドプロシージャxp_readerrorlogを使用して、ログを表示および/または検索することをお勧めします。

そして最後に、PowerShellに興味がある場合は、それをその方法でログを読み取るためのオプションでもあります（この投稿を参照してください：PowerShellを使用してSQL Server 2012エラーログを解析します）。方法はあなた次第です–あなたが知っていることとあなたのために働くものを使用してください–それは本当に重要なコンテンツです。また、イベントの順序を理解するためにログを単に読む必要がある場合もあれば、特定のエラーや情報を見つけるために検索する場合もあることを忘れないでください。

エラーログには何が含まれていますか？

では、エラー以外に、ERRORLOGでどのような情報を見つけることができますか？私が最も役立つと思ったアイテムの多くを以下にリストしました。これは完全なリストではないことに注意してください（そして、あなたの多くが追加できるものの提案を持っていると確信しています-コメントを投稿してください、そして私はこれを更新できます！）、しかし繰り返しますが、これは私がしているものです最初を探しています インスタンスを積極的に見ているとき。

• サーバーが物理サーバーか仮想サーバーか（システムメーカーのエントリを探します）
• 起動時に有効になっているトレースフラグ
  • レジストリ起動パラメータのエントリ内で、右端までスクロールすると、トレースフラグが有効になっているかどうかがわかります。
    
    起動時に有効なトレースフラグ
• インスタンスの開始後に有効または無効にされたトレースフラグ
  • ユーザー（またはアプリケーション）がDBCCTRACEONまたはDBCCTRACEOFFを使用してトレースフラグを有効または無効にすると、ログにエントリが表示されます
• SQLServerによって検出されたコアとソケットの数
  • SQL Serverが利用可能なすべてのハードウェアを認識していることを常に確認したいのですが、そうでない場合は、さらに調査する必要があります。良い例については、Jonathanの投稿「CALライセンスの下でのSQL Server 0212 EnterpriseEditionのパフォーマンスの問題」およびGlennの投稿「NUMAノード間で利用可能なSQLServerコアライセンスのバランスをとる」を参照してください。ログをクエリするための便利なTSQLも含まれています。
  • このエントリのテキストはSQLServerのバージョンによって異なることに注意してください。
• SQLServerによって検出されたメモリの量
  • 繰り返しになりますが、SQLServerが使用可能なすべてのメモリを認識していることを確認したいと思います。
• メモリ内のロックされたページ（LPIM）が有効になっていることの確認
  • このオプションはWindowsセキュリティポリシーで有効になっていますが、ログで「メモリマネージャでロックされたページを使用しています」というメッセージを探すことで有効になっていることを確認できます。
  • トレースフラグ834を使用している場合、メッセージにはロックされたページは表示されず、大きなページがバッファプールに使用されていることが表示されます。
• 使用中のCLRのバージョン
• サービスプリンシパル名（SPN）登録の成功または失敗
• データベースがオンラインになるまでにかかる時間
  • データベースの起動時とオンライン時のログ記録–データベースの起動に過度の時間がかかるかどうかを確認します。
• Service Brokerおよびデータベースミラーリングエンドポイントのステータス–いずれかの機能を使用している場合は重要です
• インスタントファイル初期化（IFI）が有効になっていることの確認*
  • デフォルトでは、この情報はログに記録されませんが、トレースフラグ3004（および3605でログへの出力を強制する）を有効にすると、データファイルを作成または拡張するときに、IFIかどうかを示すメッセージがログに表示されます。使用中かどうか。
• SQLトレースのステータス
  • SQLトレースを開始または停止すると、ログに記録され、デフォルトのトレースを超えるトレースが存在するかどうかを確認します（一時的または長期的）。 SQLSentryのPerformanceAdvisorなどのサードパーティの監視ツールを実行している場合は、常に実行されているが特定のイベントのみをキャプチャしているアクティブなトレースが表示される場合があります。または、トレースが開始され、短時間実行されてから実行される場合があります。止まる。多くのイベントをキャプチャしている場合を除いて、1つまたは2つの余分なトレースについては心配していませんが、複数のトレースが実行されている場合は必ず注意を払います。
• CHECKDBが最後に完了したとき
  • このメッセージは、多くの場合、誤解されています。インスタンスが起動すると、各データベースのブートページが読み取られ、CHECKDBが最後に正常に実行された日時が記録されます。ほとんどの人はメッセージ全体を読んでいません：
    
    DBCCCHECKDBが最後に正常に完了した日付

    CHECKDBの完了日は2012年11月11日ですが、ERRORLOGの日付は2015年7月7日です。SQLServerはしないことを理解することが重要です。 起動時にデータベースに対してCHECKDBを実行すると、ブートページのdbcclastknowngood値がチェックされます（更新されるタイミングを確認するには、私の投稿「更新dbcclastknowngoodをチェックするもの」を確認してください。また、DBCC CHECKDBがデータベースに対して実行されたことがない場合は、エントリはありません。ここにデータベースが表示されます。

• CHECKDBの完了
  • CHECKDBをデータベースに対して実行すると、出力がログに記録されます。
• インスタンス設定の変更
• sp_configureまたはUIを使用してインスタンスレベルの設定（最大サーバーメモリ、並列処理のコストしきい値など）を変更する場合（誰がログに記録されないことに注意してください） 変更しました。

• データベース設定の変更
  • 誰かがAUTO_SHRINKを有効にしましたか？ RECOVERYオプションをSIMPLEに変更してから、FULLに戻しますか？ここにあります。
• データベースステータスの変更
  • 誰かがデータベースをオフラインにする（またはオンラインにする）と、ログに記録されます。
• デッドロック情報*
  • デッドロック情報をキャプチャする必要がある場合は、トレースを実行しないでください。 SQL Server 2005から2008R2を実行している場合は、トレースフラグ1222を使用して、デッドロック情報をXML形式でログに書き込みます。 SQL Server 2000以下を使用している場合は、フラグ1204をトレースできます（このトレースフラグはSQL Server 2005以降でも使用できますが、出力される情報は最小限です）。 SQL Server 2012以降を実行している場合、system_healthイベントセッションがこの情報をキャプチャするため、これは必要ありません（2008および20082にもありますが、event_fileターゲットではなくring_bufferから取得する必要があります）。
• FlushCacheメッセージ
  • チェックポイントプロセスがデータベースのリカバリ間隔を超えたためにキャッシュがSQLServerによってフラッシュされている場合、ログに一連のFlushCacheメッセージが表示されます（詳細については、Bob Dorrによるこの投稿を参照してください）。これらのメッセージを、DBCCFREEPROCCACHEまたはDBCCFREESYSTEMCACHEを実行したときに表示されるメッセージと混同しないでください。
    
    DBCCFREEPROCCACHEまたはDBCCFREESYSTEMCACHEの実行後のメッセージ

• AppDomainアンロードメッセージ
  • ログにはAppDomainsが作成された時期も記録され、CLRを使用している場合にのみ表示されます。メモリ不足のためにAppDomainのアンロードメッセージが表示された場合は、さらに調査する必要があります。

使用中の認証モード、専用管理接続（DAC）が有効になっているかどうかなど、ログには他にも役立つ情報がありますが、sys.configurationsからも取得でき、インスタンスベースラインで確認します。前に説明しました（プロアクティブSQL Serverヘルスチェック、パート3：インスタンスとデータベースの設定）。

あなたが期待するかもしれない、ERROLOGにないものは何ですか？

これは今のところ短いリストです。ログにあると思っていたものの、そうではなかったものを見つけた方もいらっしゃるかもしれませんが…

• データベースファイルまたはファイルグループの追加または削除
• 拡張イベントセッションの開始または停止
  • ただし、サーバーレベルのDDLトリガーまたはイベント通知をデプロイする場合は、この情報をログに記録できます。詳細については、Jonathanの投稿「ログ拡張イベントの変更をERRORLOGに記録する」を参照してください。
• 実行中のDBCCDROPCLEANBUFFERSはエラーログに表示されます

ログの管理

デフォルトでは、SQL Serverは（現在のファイルに加えて）最新の6つのログファイルのみを保持し、SQLServerが再起動するたびにログファイルがロールオーバーすることに注意してください。その結果、非常に大きなログファイルが作成されることがあり、これを開くのに時間がかかり、掘り下げるのが面倒です。逆に、インスタンスが数回再起動される場合は、重要な情報が失われる可能性があります。保持するファイルの数をより高い値（30など）に増やし、sp_cycle_errorlogを使用して週に1回ファイルをロールオーバーするエージェントジョブを作成することをお勧めします。

ファイルの管理に加えて、ログに書き込まれる情報に影響を与えることができます。 ERRORLOGで混乱を引き起こす最も一般的なエントリの1つは、正常なバックアップエントリです。

バックアップが正常に完了しました

多数のデータベースを含むインスタンスがあり、トランザクションログのバックアップが定期的に（たとえば15分ごとに）行われる場合、ログがすぐにメッセージでいっぱいになるため、真の問題を見つけるのが難しくなります。幸い、トレースフラグ3226を使用して、正常なバックアップメッセージを無効にすることができます（エラーは引き続きログに表示され、すべてのエントリは引き続きmsdbに存在します）。

ログを乱雑にする別のメッセージのセットは、成功したログインメッセージです。これは、[セキュリティ]タブでインスタンスに設定するオプションです：

成功または失敗したログインをログに記録するためのセキュリティオプション

成功したログイン、または失敗したログインと成功したログインをログに記録すると、ファイルを毎日ロールオーバーした場合でも、非常に大きなログファイルが作成される可能性があります（接続するユーザーの数によって異なります）。失敗したログインのみをキャプチャすることをお勧めします。成功したログインをログに記録する必要がある企業の場合は、SQL Server 2008で追加された監査機能の使用を検討してください。補足：ログイン監査設定を変更した場合、インスタンスを再起動するまで有効になりません。

エラーログを過小評価しないでください

ご覧のとおり、ERRORLOGには、パフォーマンスのトラブルシューティングやエラーの調査だけでなく、インスタンスをプロアクティブに監視するときにも使用できる優れた情報がいくつかあります。他のどこにも見つからない情報をログで見つけることができます。定期的にチェックしていて、後付けとして残さないようにしてください。

このシリーズの他のパートをご覧ください：

• パート1：ディスクスペース
• パート2：メンテナンス
• パート3：インスタンスとデータベースの設定