web-dev-qa-db-ja.com

SQL Server 2017への復元後にDBCC CHECKDBが失敗する

SQL Server 2014にDBがあり、SQL Server 2017でバックアップを復元した後、CHECKDBを実行すると整合性チェックエラーが発生します。 SQL Server 2014がインストールされた別のマシンで復元すると、CHECKDBがエラーを報告せずに機能します。データベースを新しいサーバーに移行する必要があるので、必要に応じて更新できます。

CHECKDBエラー：

Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1737) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1738) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1739) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1740) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1741) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1742) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
Msg 8948, Level 16, State 6, Line 5
Database error: Page (1:1743) is marked with the wrong type in PFS page (1:1). PFS status 0x40 expected 0x60.
CHECKDB found 7 allocation errors and 0 consistency errors not associated with any single object.
CHECKDB found 7 allocation errors and 0 consistency errors in database 'DBNAME'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (DBNAME).

Table view of errors

sql-serverbackupmigrationsql-server-2017dbcc-checkdb
1
user3790083

次のコマンドを実行すると、これらのページがどのオブジェクトに属しているかがわかります。

SELECT s.name, o.name, a.index_id
FROM sys.schemas AS s
INNER JOIN sys.objects AS o
ON s.[schema_id] = o.[schema_id]
CROSS APPLY sys.dm_db_database_page_allocations
  (DB_ID(N'DBNAME'),o.[object_id],NULL,NULL,N'LIMITED') AS a
WHERE allocated_page_page_id BETWEEN 1737 AND 1743;

そのインデックス（index_idが0またはnullの場合はテーブル）を再構築して、割り当ての問題が解決するかどうかを確認できます。残っている場合は、インデックスを削除して再作成するか、テーブルまたはヒープの場合は、すべてを新しいテーブルに選択し、そこに新しいインデックスを作成し、古いテーブルを削除して、新しいテーブルの名前を変更します。 。

それでも問題が解決しない場合は、それらのページのコンテンツを調べて、アップグレードの一環としてデータを失うことが許容できるかどうかを判断できます（そうでない場合は、アップグレードしないこともできます）。

DBCC TRACEON(3604,-1);
DBCC PAGE(N'DBNAME', 1, 1737, 2);
DBCC PAGE(N'DBNAME', 1, 1738, 2);
DBCC PAGE(N'DBNAME', 1, 1739, 2);
...

それが許容可能な損失である場合は、推奨されるデータ損失を許可して修復を実行できます（何らかの方法でこれらのページからデータをプルする必要がある場合に備えて、修復する前にバックアップのコピーを保持することをお勧めします）。

2
Aaron Bertrand