web-dev-qa-db-ja.com

復元後の失敗を示すDBCCcheckdb

バックアップを新しいデータベースに復元しました。いくつかの削除クエリを実行した後、次のメッセージを受け取りました。

メッセージ824、レベル24、状態2、行1 SQL Serverは、論理整合性ベースのI/Oエラーを検出しました:...

DBCC checkdbを実行すると、次のような多数の行が表示されました。

Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:783) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057599497994240 (type Unknown), but it was not detected in the scan.

そして

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 2083043448, index ID 1, partition ID 72057608168079360, alloc unit ID 72057608304721920 (type LOB data), page (1:307605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 2083043448, index ID 1, partition ID 72057608168079360, alloc unit ID 72057608304721920 (type LOB data). The off-row data node at page (1:307605), slot 0, text ID 1368915968 is referenced by page (1:307603), slot 0, but was not seen in the scan.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 2083043448, index ID 1, partition ID 72057608168079360, alloc unit ID 72057608304721920 (type LOB data). The off-row data node at page (1:307605), slot 1, text ID 903086080 is referenced by page (1:307648), slot 0, but was not seen in the scan.
Msg 8929, Level 16, State 1, Line 1
Object ID 2083043448, index ID 1, partition ID 72057608168079360, alloc unit ID 72057609480241152 (type In-row data): Errors found in off-row data with ID 1368915968 owned by data record identified by RID = (1:43506:13)
Msg 8929, Level 16, State 1, Line 1
Object ID 2083043448, index ID 1, partition ID 72057608168079360, alloc unit ID 72057609480241152 (type In-row data): Errors found in off-row data with ID 903086080 owned by data record identified by RID = (1:102876:38)

出力の最後のセクションは次のとおりです。

CHECKDB found 1 allocation errors and 12 consistency errors in database 'Clients'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Clients).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

私の質問は次のとおりです。データベースを再度復元するか、修復を続行する必要がありますか? DBがかなり大きく、復元にかなり時間がかかるため、躊躇するだけです。

更新:もう少し情報があります。
すべてのテーブルエラーは、削除して再作成できる単一のテーブルに関連しています。ただし、IAMエラーの実際の意味やその影響はわかりません。

1
NotMe

データベースの復元を再試行する必要がありますか、それとも修復を続行する必要がありますか? DBがかなり大きく、復元にかなり時間がかかるため、躊躇するだけです。

私はおそらく両方を行うでしょうが、それを新しい名前に復元します。

すべてのテーブルエラーは、削除して再作成できる単一のテーブルに関連しています。ただし、IAMエラーの実際の意味やその影響はわかりません。

そのテーブルのデータが本当に重要ではなく、テーブルを本当にドロップして再作成できる場合は、おそらくそれが最速のオプションです。特に「repair_allow_data_loss」はおそらくデータ損失を引き起こすので、そうです。

IAMエラーの意味について:

短いバージョン:テーブルの内部が破損しています。

長いバージョン:インデックス割り当てマップは、SQLServerに実際のオブジェクトを取得する場所を指示します。この場合、RIDへの参照に基づいて、これはクラスター化されたインデックス(つまり、ヒープ)のないテーブルであり、ヒープ内でアクティブに更新されたデータを取得する場所をSQLに指示していると推測します。 (ヒープが更新されたときに発生することの1つは、新しい情報が古いスペースに収まらない場合、SQLに新しい情報を取得する場所を指示するポインターが作成されることです。)

ここに IAMページの記事、そして ここに 私があなたのためにIAM情報を探していたときに出てきたSQLServerのヒープに関する良いビデオ。

2