こんにちは、私の名前はカートです。GSEチームに所属するシニア プリンシパル エンジニアです。
このビデオでは、SQL Serverエラー ログについて説明します。場所、含まれている情報、Microsoft SQL Serverの問題のトラブルシューティングに役立つ理由。
通常、ログにアクセスする最も簡単な方法は、Microsoft SQL Server Management Studioを使用することです。
[Management]コンテナ、[SQL Server logs]の順にドリル ダウンすると、このSQLインストール用にSQL Serverが収集した使用可能なエラー ログが表示されます。
これに対して発生した過去のイベントのSQLによってサーバーに保持されるアーカイブ ログは6つあります。現在のログは、SQL Serverが最後に再起動されて以降のすべての情報を収集するログであり、エラーログはSQL Serverが再起動されるたびに再生成されます。
現在のログを見ると、ここに表示されることが期待できるもののいくつかがわかります。最初に表示されるのは、SQL Serverのインストールの種類です。この場合はSQL Server 2019です。
製品のバージョン情報も確認できます。この例では、SQL Server の基本 RTM インストールを使用しています。OS情報も確認できます。
このケースでは、Windows 10のワークステーションのインストールを扱っています。ログを見ていくと、Studio Managementで一番古いイベントがログの一番下に記録され、最新のイベントがログの一番上付近に記録されているのが分かります。
ログを調べてみると、認証モードが混在していることが分かります。エラー ログの実際の場所が分かります。これは、エラー ログ プログラム ファイル/Microsoft SQL Serverのデフォルトの場所であり、SQL自体のインスタンスのインストール フォルダーです。
SQL Serverの起動に使用された サービス アカウント情報もあります。重要なもう 1 つのエントリは、起動パラメーター、SQL が現在データベース ファイルに対して持っている既定の場所、エラー ログの場所、および SQL Server のログ ファイルです。
また、システム上のコア、SQLが使用できるプロセッサの数、およびシステムの起動時にSQLが物理レベルで認識している使用可能なメモリの量に関する情報も取得できます。
その他の情報として、システム データベースがオンラインになります。ユーザーの本番データベースがある場合は、その情報も表示されますが、SQL Serverのエラー ログの最も注目すべき点とその最大の利点は、SQL Serverが認識したエラーに関する情報を実際に返すことです。
また、これは起動時間だけでなく、サービスが実行されている有効期間全体にわたって発生する可能性があります。したがって、ここには非常に重要ではないエラーがありますが、システム上のPolybase構成であるPolybaseを参照しています。
実際には、Polybaseはこれでインストールされておらず、Polybaseの構成情報がないため、このインストールでは問題になりませんが、これはエラーとして表示されるメッセージの例です。
ここで、エラー ログが非常に役立つ場所についてもう少し詳しく説明します。たとえば、SQL Serverが起動していないときです。
このログは、以前の現在のログであり、この起動試行ではSQL Serverは実際には起動しませんでした。
そして、これは製造されたエラーであり、このエラーを作成した方法は、システム データベースであるモデル データベースの場所を移動することでした。
このデータベースは、SQL Serverで作成されるすべてのデータベースのテンプレートです。SQL Server の起動時には、起動して tempdb データベースを使用する必要があり、model データベースは tempdb のテンプレートです。
したがって、model データベースがないと、tempdb は起動できないか、オンラインにならず、SQL Server サービスを開始できませんでした。
これが、このエラー ログで確認できることの例です。エラーが表示され、エラーが生成された理由に関する詳細情報 (この場合はデータベース ファイル model データベース ファイルが見つかりませんでした) が表示され、後で model データベース ログ ファイルが見つからなかったこと、つまり tempdb データベースを作成できなかったことが示されます。
これは、エラー ログが問題のトラブルシューティング方法に関する情報を返す可能性があるという悪いニュースです。
ここで、このようなエラーのエントリが表示された場合、これはアプリケーションログにも含まれることを覚えておく必要があります。
そのため、まったく同じイベントがシステム アプリケーション ログに記録され、最初に表示されるエラー メッセージはデータベース ファイルが見つからなかったことを示し、2 番目のエラー メッセージはログ ファイルが見つからなかったことを示しています。
ここでも、実際に発生した障害の一例です。実際の問題をトラブルシューティングする場合、これは非常に重要です。
たとえば、model データベースなどの主要なデータベース ファイルが破損している場合、SQL のサービスは開始されず、この領域で情報を取得して、それについて学習し、トラブルシューティングを行います。
エラーログの内容についてはこれで十分です。ファイルエクスプローラーでエラーログにライブでアクセスすることもできます。繰り返しになりますが、エラーログのファイルの場所を知る必要があり、エラーログ自体で確認されました。
これは、エラー ログの既定の場所にあり、SQL Serverのインストールのログ ディレクトリーにあることがわかっています。
常に同じ情報を表示 – 表示するテキストエディタを選択できます。ここでも景色が違います。
未加工のログ自体を見ると、最も古いイベントがログの上部にあり、最新のイベントが下部にあります。
エラー ログの場所を見つけるもう1つの方法があります。それは、SQL Serverのインスタンスの[スタート]メニューからプログラムをインストールする方法です。
ここでは、[SQL Server Configuration Manager]に移動します。Configuration Managerには、このSQLのインストールのすべてのサービスが表示されます。
「SQL Serverサービス」に移動して右クリックし、[プロパティ]、[スタートアップパラメータ]に移動します。「-e」パラメータはエラーログがある場所です。
また、Studio Managementのインストールを確認していない可能性があるため、これを理解することが非常に重要になる場合があります。
そうでない場合は、SQLの特定のインストールで使用可能なすべての可能なドライブの場所について考え始める必要があります。
多くの場合、Configuration Managerにアクセスしてスタートアップ パラメーターを検索し、そのときにエラー ログの場所を正確に見つけることができます。
SQL Serverエラー ログの説明は以上です。ログの場所と、Microsoft SQL Serverのトラブルシューティングにどのように役立つかについて、このビデオがお役に立てば幸いです。
ご視聴ありがとうございました。そして、さようなら。
