助けてください、私のデータベースは壊れています。 今何？

破損したデータベースは、おそらくほとんどのデータベース管理者にとって最悪の悪夢の1つです。 損傷の結果は、ダウンタイム、悲鳴を上げるマネージャー、その他あらゆる種類の不快なものです。

この記事では、損傷したデータベースではできないことを説明し、実行する必要があるもの、損傷の種類、およびそれらを修正する方法について説明します。

データベースが破損していることを検出する方法

通常、破損したページにアクセスしようとすると、破損が非常に検出されます。 リクエスト、バックアップ、またはインデックス再作成の手順により、重大度レベルの高いエラーが発生します。

データベースの破損が検出された場合のシステムメッセージの例を次に示します。

SQL Serverは、論理的な一貫性ベースのI / Oエラーを検出しました：チェックサムが正しくありません（予想される値：0xfdff74c9;実際の値：0xfdff74cb）。 ファイル 'D：\ Develop \ Databases \ Broken1.mdf'のオフセット0x0000002229a000にあるデータベースID 13のページ（1：69965）の読み取り中に発生しました。

論理ページ1をフェッチしようとしました：データベース13の69965が失敗しました。 281474980642816ではなく、割り当てユニット72057594049069056に属します。

主な問題は、データベースの整合性チェックが継続的に実行されていない場合、何かを修正するのが難しい瞬間に、数時間後、数日後、さらには数か月後に損傷を検出できることです。 。

データベースが「疑わしい」状態（ SQL Serverのロシア語版では「疑わしい」-およそTranslator ）になったときの状況については説明しません。 データベースが「疑わしい」状態になる可能性のあるあらゆる種類の理由の説明と、これを修正するための多くのオプションは、本ではないにしても、別の記事のトピックです。

データベースがまだ破損している場合の対処方法

1. パニックにならないで
2. 取り外さないでください
3. SQL Serverを再起動しないでください
4. すぐに復旧を開始しないでください
5. 整合性チェックを実行する
6. 理由を見つける

パニックにならないでください

データベースの破損を検出する際の最も重要なことは、パニックに陥らないことです。 決定は慎重に検討する必要があり、考えられるすべての要因を考慮する必要があります。 不明確な決定を下すことで状況を悪化させるのは簡単です。

データベースをデタッチしないでください

ほとんどの場合、SQL Serverがデータベースの破損を検出すると、データベースに実際に破損したページがあることを意味します。 データベースのデタッチとアタッチ、バックアップと復元、SQL Serverサービスの再起動、またはサーバーの再起動によって、これが事実ではないことをSQL Serverに納得させようとしても、エラーは消えません。

データベースが破損し、SQL Serverが接続時にこれを検出した場合、データベースを接続できません。 このデータベースを表示する方法はいくつかありますが、切断しない方がはるかに良い方法です。

SQL Serverを再起動しないでください

切断して参加するときと同じように、SQL Serverサービスを再起動しても、検出されたエラー（存在する場合）を修正することはできません。

サービスを再起動すると、状況が悪化する可能性があります。 SQL Serverは、再起動後のデータベースリカバリフェーズ中にエラーを検出すると、「疑わしい」とマークし、データベースリカバリプロセスを大幅に複雑にします。

すぐに復旧を開始しないでください

「回復」オプション（通常はデータ損失）の1つを使用してDBCC CHECKDBを実行するだけで、状況が改善されることを期待するかもしれません（ 私の経験では、非コアSQL Serverフォーラムで最初に推奨されるのはDBCC CHECKDB REPAIR_ALLOW_DATA_LOSSを実行することです-翻訳者のコメント ）。 多くの場合、このような回復を開始することはお勧めしません。 すべてのエラーの修正を保証するものではなく、許容できないデータの損失につながる可能性があります。

この回復は、エラーを修正する最後のステップです。 他の選択肢がない場合にのみ開始する必要がありますが、そもそも開始しないでください。

整合性チェックを実行する

データベースの修正方法を決定するためには、正確に何が破損しているかを確実に知る必要があります。 これを把握できる唯一の方法は、All_ErrorMsgsパラメーターを指定してDBCC CHECKDBを実行することです（SQL Server 2005 SP3、SQL Server 2008 SP1、および以前のバージョンでは、このパラメーターは既定で有効になっているため、指定する必要はありません）。 No_InfoMsgsパラメーターを指定せずにDBCC CHECKDBを実行すると、このプロシージャの出力には各テーブルの行とページの数に関する情報が含まれることに注意してください。

DBCC CHECKDBは、大規模なデータベースでの実行に時間がかかる場合がありますが、この手順が完了するまで待つ必要があります。 データベースにすべての問題に関する情報がある場合にのみ、有能な回復戦略を構築できます。

理由を見つける

エラーが修正されると、作業を終了したと見なすことはできません。 これらのエラーの原因が特定されていない場合、再び発生する可能性があります。 通常、エラーの主な原因はI / Oサブシステムの問題ですが、「低レベルソフトウェア」（アンチウイルスなど）の誤操作、人間の行動、またはSQL Serverのバグ自体によっても発生する可能性があります。

次は何ですか

エラーを完全かつ完全に修正するための追加手順は、CheckDBの結果に依存します。 少し先に、最も頻繁に発生するエラーのいくつかを示します（この記事は、あらゆる種類のエラーの完全な説明を主張するものではないことに注意してください）。

記載されているエラーは、重大度の低い順に並べられています。 一般に、CheckDBで検出された最も重大なエラーについては、それらを解決するために利用可能なメソッドの説明があります。

記事に記載されていないエラーが突然見つかった場合は、最後のセクション「ヘルプの検索」に注意してください。

無効なページスペース情報

メッセージ2508、レベル16、状態3、行1

オブジェクト "Broken1"、インデックスID 0、パーティションID 76911687695381、割り当てユニットID 76911687695381（行内データ型）の行内データRSVDページ数が正しくありません。 DBCC UPDATEUSAGEを実行します。

SQL Server 2000では、メタデータに格納されているテーブルまたはインデックスの行とページの数が正しくない（さらにはマイナスになる）可能性があり、DBCC CHECKDBはそれに関して何も間違っていませんでした。 SQL Server 2005では、この番号は正確である必要があり、CheckDBは突然不一致を検出した場合に警告を発行します。

これは軽微な問題であり、非常に簡単に解決できます。 メッセージに記載されているように、目的のデータベースのコンテキストでDBCC UPDATEUSAGEを実行するだけで、警告が消えます。 このエラーは、SQL Server 2000からアップグレードされたデータベースでは一般的であり、SQL Server 2005/2008で作成されたデータベースには表示されません。

メッセージ8914、レベル16、状態1、行1

オブジェクトID 181575685、インデックスID 1、パーティションID 293374720802816、割り当てユニットID 76911687695381（タイプLOBデータ）のページ（1：26839）のPFS空き領域情報が正しくありません。 期待値0_PCT_FULL、実際の値100_PCT_FULL。

このエラーは、データベース内のページの空き状況を考慮したPFSページ（ページの空き領域）に誤った値が含まれている場合に表示されます。 前述のように、このエラーは重大ではありません。 SQL Server 2000でページがどれだけいっぱいになっているかを判断するために使用されるアルゴリズムは、常に正しく機能しませんでした。 この問題を解決するには、REPAIR_ALLOW_DATA_LOSSパラメーターを指定してDBCC CHECKDBを実行する必要があります。これがデータベース内の唯一のエラーである場合、データは実際には影響を受けません。

非クラスター化インデックスのみにダメージを与える

CheckDBによって検出されたすべてのエラーがID = 2以上のインデックスに関連している場合、これは非クラスター化インデックスのみが破損していることを意味します。 非クラスター化インデックスに含まれる情報は「冗長」であるため（ 同じデータがヒープまたはクラスターインデックスに保存されます-およそTranslator ）、これらの損傷はデータを失うことなく修復できます。

CheckDBで検出されたすべてのエラーが非クラスター化インデックスに関連している場合、DBCC CHECKDBの推奨される「回復レベル」はREPAIR_REBUILDです。 そのようなエラーの例（実際、このタイプのエラーははるかに多くあります）：

メッセージ8941、レベル16、状態1、行1

テーブルエラー：オブジェクトID 181575685、インデックスID 4、ページ（3：224866）。 テスト（ソート済み[i] .offset> = PAGEHEADSIZE）が失敗しました。 スロット159、オフセット0x1は無効です。

メッセージ8942、レベル16、状態1、行1

テーブルエラー：オブジェクトID 181575685、インデックスID 4、ページ（3：224866）。 テスト（ソート済み[i] .offset> = max）が失敗しました。 スロット0、オフセット0x9fは前の行と重複しています。

この場合、破損した非クラスター化インデックスを削除して再作成することにより、破損を完全に修復できます。 インデックス（ALTER INDEX REBUILD）をオンライン（およびオフライン）で再構築すると、古いインデックスのページが読み取られて新しいインデックスが作成されるため、失敗します。 したがって、古いインデックスを削除して再作成する必要があります。

これは、DBCC CHECKDBがREPAIR_REBUILDパラメーターを使用して行うこととまったく同じですが、データベースはシングルユーザーモードである必要があります。 このため、通常、これらの操作を手動で実行して、インデックスが再作成されている間もデータベースが機能し続けることが最善です。

必要なインデックスを再作成するのに十分な時間がなく、「クリーン」な（エラーのない）完全バックアップと、ログの切れ目のないトランザクションログのバックアップがある場合、破損したページを復元できます。

LOBページの破損

メッセージ8964、レベル16、状態1、行1

テーブルエラー：オブジェクトID 181575685、インデックスID 1、パーティションID 72057594145669120、割り当てユニットID 72057594087800832（タイプLOBデータ）。 ページ（1：2444050）、スロット0、テキストID 901891555328の行外データノードは参照されません。

このエラーは、データページがリンクしていないLOBページ（大きなオブジェクト）があることを示しています。 これは、クラスターインデックス（またはヒープ）が以前に破損しており、破損したページが削除された場合に発生する可能性があります。

CheckDBがそのようなエラーについてのみ話す場合、REPAIR_ALLOW_DATA_LOSSパラメーターを指定してDBCC CHECKDBを実行できます-これらのページは破棄されます。 これらのページにリンクするデータページがまだないため、データの損失はありません。

範囲外エラー

メッセージ2570、Sev 16、State 3、Line 17

ページ（1：1103587）、オブジェクトID 34のスロット24、インデックスID 1、パーティションID 281474978938880、割り当てユニットID 281474978938880（「行内データ」タイプ）。 列の値は、データ型«日時»の範囲外である«変更»。 有効な値に列を更新します。

これらのエラーは、列に範囲外の値が含まれていることを示します。 これは、深夜0時からバイト数が2で割り切れないUnicode文字列、または不正な精度値を持つ実数/実数から1440分以上経過したと想定する日時値です。

DATA_PURITYパラメーターを有効にしてDBCC CHECKDBコマンドを実行したことがない場合、SQL Server 2000以前からアップグレードしたデータベースでは、これらのエラーのチェックはデフォルトでは実行されません。

CheckDBはこれらのエラーを修正できません。これは、間違った値の代わりにどの値を設定するのかわからないためです。 これらのエラーの訂正は、多くの努力を必要としませんが、それは手動で行われます。 誤った値が許容可能な何かに置き換えてください。 主な問題は、 - 無効な値のための検索です。 このナレッジベースの記事には、段階的な手順が記載されています。

クラスタ化インデックスまたはヒープの損傷

クラスターインデックスのヒープページまたはリーフページが破損していることが判明した場合、これはそれらのデータが失われていることを意味します。 クラスタ化インデックスのリーフレベルのページにはデータページが直接含まれており、それらのページには冗長性は一切提供されません。

CheckDBがクラスター化インデックスのリーフレベルのページに損傷を報告する場合、DBCC CHECKDBに必要な「回復レベル」はREPAIR_ALLOW_DATA_LOSSです。

このようなエラーの例：

サーバー：メッセージ8976、レベル16、状態1、行2

テーブルエラー：オブジェクトID 181575685、インデックスID 1、パーティションID 76911687695381、割り当てユニットID 76911687695381（行データ型）。 ページ（1：22417）はスキャンで見られませんでしたが、その親（1：479）と前のページ（1：715544）はそれを参照しています。

サーバー：メッセージ8939、レベル16、状態1、行2

テーブルエラー：オブジェクトID 181575685、インデックスID 0、ページ（1：168576）。 テスト（m_freeData> = PAGEHEADSIZE && m_freeData <=（UINT）PAGESIZE-m_slotCnt * sizeof（Slot））は失敗しました。 値は44と8028です。

CheckDBによって返されたエラーがインデックスID = 0または1に関連している場合、これはデータが直接破損していることを意味することに注意してください。

このタイプのエラーが修正されますが、修正は線やページ全体を破壊することです。 CheckDBがエラー修正データを削除すると、外部キーによって課せられた制限はチェックされず、トリガーは起動しません。 行またはページだけ削除します。 その結果、データに一貫性がなくなったり、論理的な整合性が損なわれたりする可能性があります（単一行でLOBページにリンクできなくなったり、非クラスター化インデックス行が "nowhere"を示す場合があります）。 そのためこれらの効果により、そのような回復は推奨されません。

あなたは「クリーン」のバックアップを持っている場合は、それからの回復は通常、このようなエラーを訂正するために、よりpredpochitelnymです。 データベースが完全復旧モデルであり、ログの切れ目のないチェーン（最後の「完全な」完全バックアップから開始）でトランザクションログのバックアップがある場合、ログのアクティブな部分をバックアップし、データベース全体（または破損したページのみ）を復元できます。それによってデータが全く失われることはありません。

破損していないデータを含むバックアップがない場合、オプションは1つだけです-REPAIR_ALLOW_DATA_LOSSパラメーターを指定してDBCC CHECKDBを起動します。 これは、この手順の期間中、シングルユーザーモードに翻訳データベースが必要になります。

また、データの損失を回避する方法はありませんが、クラスター化インデックスから削除されるデータを確認できます。 これについては、Paul Renadal によるこの投稿をご覧ください。

メタデータへの損傷

メッセージ3853、レベル16、状態1、行1

sys.columnsの行（object_id = 181575685、column_id = 1）の属性（object_id = 181575685）には、sys.objectsに一致する行（object_id = 181575685）がありません。

通常、誰かがシステムテーブルに直接手を加えたときに、SQL Server 2000からアップグレードされたデータベースで同様のエラーが発生します。

SQL Serverのどのバージョンのシステムテーブルでも、外部キーは使用されないため、SQL Server 2000ではsysobjects（テーブルなど）から行を削除し、削除された行を参照する行をsyscolumnsおよびsysindexesテーブルに残すことができました。

SQL Server 2000では、CheckDBはシステムカタログの整合性をチェックしなかったため、このような問題はしばしば気付かれずにハングしました。 SQL Server 2005では、CHECKDBは、システムカタログの整合性をチェックし、そのようなエラーが発生することがあります。

これらのエラーの修正は最も簡単なことではありません。 CheckDBはそれらを修正できません。システムテーブルからレコードを削除することしかできないため、大量のデータが失われる可能性があるためです。 SQL Server 2005へのアップグレード前にこのデータベースのバックアップを作成し、アップグレードがごく最近であった場合、それをSQL Server 2000に展開し、そのシステムテーブルを手動で調整し、データベースをSQL Server 2005に再度転送できます。

SQL Server 2000にデータベースのバックアップがない場合、または更新が長すぎてデータの損失が許容できない場合、2つの方法があります。 1つ目は、SQL Server 2005でシステムテーブルを編集することですが、システムテーブルは文書化されておらず、以前のバージョンよりもはるかに複雑であるため、これはかなり複雑で危険なプロセスであることに注意してください。 で、この記事、追加の情報を見つけることができます。

2番目の方法は、すべてのデータベースオブジェクトのスクリプトを作成し、すべてのデータをエクスポートした後、新しいデータベースを作成し、オブジェクトを復元してデータを入力します。 本実施形態がより好ましいです。

取り返しのつかないダメージ

CHECKDBはすべてを修正することはできません。 以下のようなエラーは修正不能であり、唯一のオプションは、そのような損傷がないバックアップからデータベースを復元することです。 完全バックアップがあり、ログチェーンが現在の時刻まで壊れていない場合、トランザクションログの最終フラグメントをバックアップでき、データを失うことなくデータベースを復元できます。

そのようなバックアップがない場合、できることは、それらのオブジェクトのスクリプトを作成し、まだ利用可能なデータをアップロードすることだけです。 破損が原因で、すべてのデータにアクセスできるわけではなく、ほとんどの場合、エラーなしですべてのオブジェクトをスクリプト化できるとは限りません。

システムテーブルへの損傷

メッセージ7985、レベル16、状態2、行1

システムテーブルの事前チェック：オブジェクトID4。ラッチタイプSHでページ（1：358）を読み取ってラッチできませんでした。

修復不可能なエラーにより、チェック文が終了しました。

メッセージ8921、レベル16、状態1、行1

チェック終了。 事実を収集しながら、障害が検出されました。 おそらくスペースまたはシステム・テーブルのうちtempdbが矛盾しています。

CheckDBは、データベースの内容を把握するために、いくつかの重要なシステムテーブルに依存しています。 これらのテーブル自体が破損している場合、CheckDBは、データベースの内容と現在の状態を比較するためのものを推測することさえできず、何かを修正することは言うまでもありません。

「カードの配布」への損傷

メッセージ8946、レベル16、状態12、行1

テーブルエラー：割り当てページ（1：2264640）に無効なPFS_PAGEページヘッダー値があります。 タイプは0です。チェックタイプ、ページ上のアロケーションユニットIDとページIDです。

メッセージ8998、レベル16、状態2、行1

GAM、SGAM、またはPFSページのページエラーにより、（1：2264640）から（1：2272727）までのデータベースID 13ページの割り当て整合性チェックが妨げられます。

この場合、データベース内のデータの配置を決定する1つまたは複数のページ（ 配布カード -約Translator ）が破損しています。 これらのページは、データベースで使用されているページとエクステントを決定するために使用され、空いているされています。 CheckDBはそのようなエラーを修正できません。これは、データを配置するために使用されるエクステントとそうでないエクステントを（これらのページなしで）判断することはほとんど不可能だからです。 このような「配布マップ」を単純に削除することはできません。それらのいずれかを削除すると、4 GBのデータが削除されるためです。

検索ヘルプ

何をする必要があるかわからない場合は、助けを求めてください。 突然、データベースの破損に関するメッセージが表示されますが、このメッセージは上記で説明されていないので、助けを求めてください。 あなたが最良の回復方法を選択することがわからない場合は - 助けを求めます。

あなたはシニアDBAを持っている場合は、それを参照してください。 「メンター」がいる場合は、彼に聞いてください。 フォーラムでアドバイスを求めますが、フォーラムで受け取ったすべてのアドバイスが役立つわけではないことを忘れないでください。 実際、そこから絶対に間違った、さらには危険な決定が時々公表されます。

最後に、マイクロソフトカスタマーサポートに連絡してください。 無料ではありませんが、破損したデータベースで何ができるかを本当に知っているので、データベースが企業にとって重要な場合、ソリューションの独立した検索中のダウンタイムのコストは、サポートに連絡するコストよりもはるかに高くなる可能性があります。

おわりに

この記事では、破損したデータベースが検出されたときにできること、さらに重要なこととして、してはいけないことの例をいくつか示しました。 説明した問題を解決するために使用できる方法と、適切なバックアップを作成することの重要性（ および適切な復旧モデル（約Translator ） を選択すること）を理解してください。



注意：これは、さらに、一度に行われていない私の最初の翻訳であり、そしていくつかのアプローチでは、自由な時間がある夜は、テキスト全体が誰かにいくつかの矛盾を見えるかもしれませんので。 私がどこかで縛られすぎていて、テキストの一部が突然理解しにくいことが判明した場合、私は喜んですべてのコメントを聞きます。

敬具、充填されていません。

PS「公開」ボタンをクリックしようとしたときに、 SQL Server Centralからのこのようなコミックを含むメーリングリストがメールに落ちました。