web-dev-qa-db-ja.com

最後に成功したDBCCCHECKDB

DBCC PAGEを見ると、最後に確認された正常なDBCC CHECKDBが表示されるはずですが、この動作が正しく表示されていません。

破損していることがわかっているデータベースがあります。 DBCC CHECKDBを実行すると、エラーが期待どおりに表示されます（以下を参照）。

CHECKDB found 0 allocation errors and 1 consistency errors in table 'Blah'
   (object ID 251147940).
Msg 2508, Level 16, State 3, Line 1

以下を実行してdbi_dbccLastKnownGoodを評価すると、CHECKDBがちょうど秒単位で実行された時間がわかります。

DBCC PAGE ('Blah', 1, 9, 3) WITH TABLERESULTS;

Paul Randalの情報を読みましたが、それから、これを正しく行っている/読んでいるように見えます。誰かがこれを以前に見たことがありますか？もしそうなら、それを回避することについて何か考えはありますか？

これがエラーの完全なサンプルです。さまざまなテーブルでこれらのうち12個を取得しています。

    Msg 2508, Level 16, State 3, Line 1
The In-row data RSVD page count for object "Mailings", index ID 0, partition ID 16459231395840, alloc unit ID 16459231395840 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
CHECKDB found 0 allocation errors and 1 consistency errors in table Mailings' (object ID 251147940).
sql-serversql-server-2008dbcc-checkdb
3
PseudoToad

コミュニティウィキの回答 ：

From CHECKDB From Every Angle：DBCC CHECKDBが最後に正常に実行されたのはいつですか？ by Paul Randal：

SQL Server 2005に導入した新機能の1つは、DBCC CHECKDBが正常に完了した最後の時刻（last-known good time）。 DBCC CHECKDBが開始され、完了しなかった時間です。

successfullyはどういう意味ですか？これが問題です–DBCC CHECKDBが最後まで実行されると、実行が成功したと見なされます–破損が見つかった場合でも。ただし、最後に認識された適切な時間は、破損が見つからなかった場合にのみ更新されます。私が知っている少し混乱します。

多少矛盾しているように見えますが、エラーが報告された場合にそのフィールドが更新されると予想される動作ではないように思われることに同意します。

一方、例は非常に小さな問題であり、DBCC UPDATEUSAGEを実行することで簡単に修正できるため、SQLServerはそれを成功した実行と見なす可能性があります。

2
user126897