web-dev-qa-db-ja.com

PFSページの破損の問題と質問

最近、本番データベースでPFSページの破損が発生しました。古いバックアップをチェックしてクリーンなものを見つけているところですが、この問題を修正するために必要な時間を短縮するために別のプロセスが機能するかどうか疑問に思っていました。これまでのところ、クライアントの問題は発生しておらず、DBは引き続き使用可能ですが、明らかに問題を修正する必要があります。個々のPFSページを修復できないことはわかっていますが、以下は機能しますか？

Msg 8948, Sev 16, State 6, Line 1 : Database error: Page (8:15390050) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]
Msg 8948, Sev 16, State 1, Line 1 : Database error: Page (8:15390051) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]
Msg 8948, Sev 16, State 1, Line 1 : Database error: Page (8:15390052) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]
Msg 8948, Sev 16, State 1, Line 1 : Database error: Page (8:15390053) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]
Msg 8948, Sev 16, State 1, Line 1 : Database error: Page (8:15390054) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]
Msg 8948, Sev 16, State 1, Line 1 : Database error: Page (8:15390055) is marked with the wrong type in PFS page (8:15383376). PFS status 0x40 expected 0x60. [SQLSTATE 42000]

私はDBCCページを使用して発見し、6ページすべてが1つのテーブルに属しているので、これが機能して古いバックアップから復元する必要がないことを願っていますが、私が読んだすべての内容は、バックアップからの復元か修復の許可データロス。また、0x60ステータスとは何ですか？ DBCCページを使用すると、0x40ステータスがAllocatedであることを示しているため、0x60のステータスが何であるか知りたいです。このプロセスについて人々はどう思いますか？腐敗を解消するのに役立ちますか？

  1. すべてのデータをバックアップテーブルにコピーする-新しいデータページを割り当てる必要があります。つまり、これらのページのPFSページエントリはクリーンである必要があります。
  2. ソーステーブルを削除します-テーブルが存在しないため、不良なPFSページエントリが削除されると思います...しかし、PFSページが破損している場合、SQL Serverはエラーをまったく削除できますか、それともテーブルを削除した後もエラーは残りますか？
  3. テーブルの名前をソーステーブルに戻します。手順2で新しいデータページと新しいPFSページエントリが作成されているため、問題が解決することを期待しています。

誰かがこれを試みたか、古いバックアップに戻らずにPFSページの破損に対処する方法を聞いたことがありますか？

enter image description hereenter image description here

sql-servercorruptiondbcc-checkdb
3
DBA Greg14

いくつかのPFSページに損傷があります。この種の汚職は取り返しのつかないものです。

ログ末尾のバックアップを取得し（可能な場合）、フルバックアップを復元します。すべてのログバックアップに続いて、実行したログ末尾のバックアップを復元します。バックアップの適切なセットがあるので、データを失うことなく復元できるはずです。

根本原因の分析を行う必要があります。 Windowsイベントログを確認、SANログ、RAIDログなど）。これは通常、IOサブシステムの問題であり、原因またはそれが再び発生する可能性があります。

1
Benedikt Schackenberg