web-dev-qa-db-ja.com

データベース内の一貫性のないページの修復

SQL 2000DBがあります。 RAIDアレイの障害が原因で、サーバーがクラッシュしました。 DBCC CHECKDBを実行すると、9ページに27の整合性エラーがあるというエラーが発生します。

これらのページでDBCCPAGEを実行すると、次のようになります。

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

示されたインデックスはクラスター化されておらず、2つの列を含む一意の制約によって作成されているため、インデックスを削除して再作成してみました。これにより、次のエラーが発生しました。

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

ただし、実行中

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

0行を返します。

これが私たちが計画していることです：

  • DBのサーバー前のクラッシュコピーを復元し、DBCCCHECKDBを実行します
  • それがクリーンに戻った場合は、回復せずに再度復元します
  • すべてのサブシーケンスTLOGバックアップを適用します
  • 本番アプリを停止し、テールログのバックアップを取り、それも適用します
  • 製品DBを削除し、新しく復元したDBの名前を変更して製品にします。
  • 製品アプリを起動します

誰かがこのアプローチに穴を開けてくれませんか？たぶん、別のアプローチを提案しますか？必要なのは最小限のダウンタイムです。

SQL 2000DBサイズ94GB破損したページがあるテーブルには、4億6000万行以上のデータがあります

助けてくれてありがとう。

ラージ

sql-serverdbcc
8
Raj

あなたの回復ソリューションは、先に進むための教科書の方法です。適切なバックアップがあり、破損したデータベースのトランザクションログをバックアップできると仮定すると、戦略は実装する教科書です。

ただし、先に進む前に、影響を受けるテーブルのみを再作成する可能性を検討しましたか？

場合によっては、影響を受けるテーブルの正確なコピーを作成することで、

select *
into NewTableFromOld
from DamagedTable

次に、損傷したテーブルを新しいものとドロップ/スワップし、適切な制約とインデックスを追加することを忘れないでください。

2
John Sansom

最初にデータをファイルにまとめてから、新しいテーブルにまとめて戻します。 SELECT INTOは、そのレコード数には適切ではありません（IMO）。

0
m4rty