SQL Serverエージェントアラートに関する前回の記事では、重大度の高いエラー19〜25およびエラー825に対してSQLエージェントアラートを設定および構成する方法を段階的に説明しました。この記事では、これらのエラーについて詳しく説明し、環境で発生した場合の対処方法を共有してください。
重大度が19以上のエラーは、現在のバッチの完了を停止します。重大度が20以上のエラーは致命的なエラーであり、現在のクライアント接続を終了します。これらのエラーは、データベース内のすべてのプロセスにも影響を与える可能性があります。致命的なエラーは、その名前が示すとおりです。実行中のプロセスが終了し、クライアント接続が閉じられます。
重大度19のエラー
重大度19のエラーは、リソースの不足によるエラーです。これは、（構成できない）内部制限を超えて、現在のバッチが終了したことを意味します。これらのエラーはめったに発生せず、問題を修正するためにできることはほとんどありません。重大度19のエラーが発生した場合は、プライマリサポートプロバイダーに連絡する必要があります。通常、それはMicrosoftです。
SQL Serverを使用してきた長年の間に、重大度19のエラーが生成されたインシデントを思い出せません。 Bingを検索しても、エラーの発生を見つけるのに苦労しました。私が見つけたいくつかの参照は、SQL Serverの初期バージョンに関連しており、SQLServer自体のバグを参照していました。
重大度20のエラー
重大度20のエラーは、現在のプロセスでの致命的なエラーです。これは、ステートメントで問題が発生し、終了したことを示しています。これは現在のプロセスにのみ影響するため、データベース自体が破損している可能性はほとんどありません。これらのエラーは個々のステートメントに関連付けられているため、エラーメッセージ全体を収集し、そのコードの責任者またはチームに連絡する必要があります。これは、社内またはアプリケーションのベンダーである可能性があります。エラーの例は次のとおりです。
エラー：18056、重大度20、状態：29クライアントは、接続プール用にリセットされたSPID123のセッションを再利用できませんでした。
このエラーは、プールされた接続でリセットしようとしたときにエラーが発生したことに関連しているため、アプリケーションの開発者またはベンダーに連絡します。また、SQL Serverログを確認します。このログには、エラーの原因となっている実際の状況に関するより詳細なエラーメッセージが含まれている可能性があります。
重大度21のエラー
重大度21のエラーは、そのデータベースを使用するすべてのプロセスに影響を与えるデータベースの致命的なエラーです。
このエラーは、Enterprise機能を使用してデータベースをStandard Editionインスタンスに復元しようとしたとき、およびデータベースが破損していてユーザーが破損したページにアクセスしようとしたときに発生することがあります。このタイプのエラーメッセージの例は次のとおりです。
エラー：605、重大度：21、状態1データベース'DB_NAME'の論理ページ（1：8574233）をフェッチしようとしましたが、オブジェクト'Table01'ではなくオブジェクト'0'に属しています。
Enterprise機能を使用しているデータベースをStandardEditionインスタンスに復元しようとする場合は、最初にEnterprise機能を削除する必要があります。たとえば、データ圧縮または変更データキャプチャを使用している場合は、最初にそれらの機能の使用を停止してデータベースから削除し、データベースをバックアップしてから、StandardEditionインスタンスに復元する必要があります。 DMV sys.dm_db_persisted_sku_featuresを使用できます エンタープライズ専用の機能が使用されているかどうかを確認します。
破損エラーの場合は、 DBCC CHECKDBを実行する必要があります 腐敗の程度を判断し、そこから進みます。運が良ければ、エラーは非クラスター化インデックスにあり、再構築して問題を解決できます。破損がより深刻な場合は、復元操作を検討している可能性があります。破損と破損のさまざまな側面を解決する方法をよりよく理解するために、PaulRandalによるさまざまなブログ投稿を確認することをお勧めします。 Paulには、ここで表示できる破損に関するカテゴリ全体があります：
- http://www.sqlskills.com/blogs/paul/category/corruption/
DBCC CHECKDBを実行しています データベースに対して定期的にスケジュールされたジョブの一部として、破損をできるだけ早く検出することを強くお勧めします。破損を定期的にチェックしていない場合、破損したデータを回復できないという大きなリスクがあります。
重大度22のエラー
重大度22のエラーは、テーブルの整合性が疑われるために致命的なエラーであり、基本的に、メッセージで指定されたテーブルまたはインデックスが破損していることを示します。腐敗は起こり、頻繁に起こります。私たちの経験では、破損の大部分はI/Oサブシステム関連の問題が原因で発生します。重大度22のエラーが発生した場合は、 DBCC CHECKDBを実行する必要があります。 損傷の程度を判断します。エラーの例は次のとおりです。
データベース内の無効なファイルID##のXYZを開くことができませんでした。テーブルまたはデータベースが破損している可能性があります。
エラーが非クラスター化インデックスにある場合は、インデックスを再構築して破損を修正するだけです。破損がヒープまたはクラスター化インデックスにある場合は、データベースを一貫性のある状態に復元する必要があります。
破損がメモリにあるがディスクにはないという報告を見たことがあります。その場合、インスタンスを再起動するか、データベースをオフラインにしてからオンラインに設定すると、エラーが解消されます。
重大度23のエラー
重大度23のエラーは、データベース自体に整合性の問題があることを報告するもう1つの致命的なエラーです。解決策は、重大度22のエラーの解決策とよく似ており、 DBCC CHECKDBをすぐに実行する必要があります。 データベースへの損傷の全範囲を見つけるため。
このレベルの破損は、データベース全体に影響を及ぼしていると検出されます。これは、データファイル自体の破損またはログファイルの破損である可能性があります。エラーの詳細は、根本的な問題にあなたを導きます。たとえば、次のエラーは、データベースを復元するか、ログを再構築する必要があることを示しています。一貫性を保つために、最新のバックアップと使用可能なすべてのトランザクションログバックアップから復元します。
エラー：9004、重大度：23状態：6データベース'db_name'のログの処理中にエラーが発生しました。可能であれば、バックアップから復元します。バックアップが利用できない場合は、ログを再構築する必要があるかもしれません。
重大度24エラー
重大度24のエラーは、ハードウェアに関連する致命的なエラーです。このメッセージは、ある種のメディア障害が原因で発生します。私が見たこれらのタイプのエラーの最も一般的なものは、メモリとI/Oエラーの問題に関連しています。例：
エラー：832、重大度：24、状態：1一定であるはずのページが変更されました（期待値：<期待値>、実際のチェックサム：<実際の値>、データベース
このようなエラーが発生した場合は、システムサポートチームに連絡してサーバーでメモリテストを実行し、サーバーに適切なヘルスチェックを行う必要があります。このエラーは、メモリの不良またはメモリスクリブラー（カーネルプロセスまたはSQL Serverのメモリを変更しているもの）である可能性があります。
別の例：
エラー：824、重大度：24、状態：2SQLServerが論理整合性ベースのI/Oエラーを検出しました：不正なページID（予期される1：123、実際の0：0）。これは、データベースID
このエラーは、データベースのプライマリデータファイルの整合性エラーを示しています。すぐにDBCCCHECKDBを実行する必要があります 破損の程度を判断し、データベースを修復または復元するための適切なアクションを実行します。
重大度25のエラー
重大度25のエラーは、致命的なシステムエラーです。重大度25は、多かれ少なかれ、その他の致命的なエラーのキャッチオールであると聞いています。失敗したアップグレードに関連する場合にのみこのエラーが発生しました。アップグレードスクリプトの1つが実行できず、重大度25のエラーがスローされます。次のようなエラーが発生します：
アップグレードステップ'sqlagent90_sysdbupg.sql'でエラー598、状態1、重大度25が発生したため、データベース'master'のスクリプトレベルのアップグレードに失敗しました。これは重大なエラー状態であり、通常の操作を妨げる可能性があり、データベースはオフラインになります。 'master'データベースのアップグレード中にエラーが発生した場合、SQLServerインスタンス全体を起動できなくなります。以前のエラーログエントリでエラーを調べ、適切な修正アクションを実行してデータベースを再起動し、スクリプトのアップグレード手順が完了するようにします。この場合、このメッセージの前のエラーは、SQLServerのデフォルトのデータの場所のパスが正しくないことを示していました。それが修正されると、アップグレードは正常に実行されました。
エラー825
エラー825は、読み取り-再試行警告と呼ばれることがよくありますが、条件は読み取り操作と書き込み操作の両方に当てはまります。このエラーは、操作の再試行が必要であり、SQLServerが成功するまでに試行を再試行する必要があった回数を通知します。 SQL Serverは最大4回操作を再試行しますが、4回再試行すると、823または824エラーが発生します。エラー825メッセージは次のようになります：
オフセット0x00000002000でのファイル'pathto file name \ db_name.mdf'の読み取りは、エラー：不正なチェックサム（予想：XYZ;実際のABC）で2回失敗した後、成功しました。 SQL Serverエラーログおよびシステムイベントログの追加メッセージにより、詳細が提供される場合があります。このエラー状態はデータベースの整合性を脅かすため、修正する必要があります。完全なデータベース整合性チェック（DBCC CHECKDB）を完了します。このエラーは多くの要因によって引き起こされる可能性があります。詳細については、SQL ServerBooksOnlineを参照してください。
これらのメッセージは、ディスクサブシステムに大きな問題があることを示しているため重要です。トラブルシューティング方法は、 DBCC CHECKDBを実行することです。 エラーが推奨するようにデータベースの整合性を確保し、オペレーティングシステムまたはストレージデバイスからのエラーがないかWindowsイベントログを確認します。ストレージとハードウェアのサポートチームに、基盤となるI/Oサブシステムのエラーも確認してもらう必要があります。
概要
SQLAgentアラートを構成するのは無料で簡単です。これらのアラートにプロアクティブで対応することは、あなたとあなたの顧客のダウンタイムを最小限に抑えるために重要です。これまでに学んだように、SQL Serverとデータベースの整合性に影響を与える可能性のあるものはたくさんあります。これらのエラーから回復できるようにするための最善の防御策は、適切なバックアップを作成し、 DBCC CHECKDB> 。 DBCC CHECKDBを実行することを常にお勧めします データベースに対して定期的に破損を検出し、破損をすばやく検出するほど、データをバックアップして、データを失うことなく復元できるようにする可能性が高くなります。