suspect_pages テーブルの理解と管理
SQL Server 2005 で導入された suspect_pages テーブルは、msdb データベースに保存されています。suspect_pages テーブルは、問題があると考えられるページに関する情報を保持するためのテーブルで、復元が必要かどうかを判断する際に使用します。
SQL Server データベース エンジンがデータ ページの読み取りを試みたときに次のエラーのいずれかを検出すると、ページは "問題あり" と見なされます。
823 エラー。ディスク エラー (特定のハードウェア エラー) など、オペレーティング システムで実行された巡回冗長検査 (CRC) によって発生したエラーです。
824 エラー。破損ページ (すべての論理エラー) などです。
問題があると考えられるすべてのページのページ ID が suspect_pages テーブルに記録されます。データベース エンジンは、次のような通常の処理中に検出された問題のあるページを記録します。
クエリがページを読み取る必要があるとき
DBCC CHECKDB 操作の実行中
バックアップ操作の実行中
suspect_pages テーブルは、復元操作、DBCC 修復操作、データベースの削除操作などの実行中にも必要に応じて更新されます。
suspect_pages テーブルに記録されるエラー
suspect_pages テーブルには、824 エラーにより失敗したページごとに 1 行ずつ、上限を 1,000 行として格納されます。次の表に、suspect_pages テーブルの event_type 列にログ記録されるエラーを示します。
エラーの説明 |
event_type 値 |
|---|---|
オペレーティング システムの CRC エラーによって発生した 823 エラー、または、不適切なチェックサムまたは破損ページ (不適切なページ ID) 以外の 824 エラー |
1 |
不適切なチェックサム |
2 |
正しくないページ |
3 |
復元済み (ページは不適切と見なされた後で復元されました) |
4 |
修復済み (DBCC によってページが修復されました) |
5 |
DBCC による割り当て解除 |
7 |
suspect_pages テーブルには、一時的なエラーも記録されます。一時的なエラーの原因としては、I/O エラー (たとえば、ケーブルが取り外された場合) や、反復的なチェックサム テストで一時的にエラーになったページなどがあります。
データベース エンジンによる suspect_pages テーブルの更新方法
データベース エンジンは、suspect_pages テーブルに対して次のアクションを行います。
テーブルに空き容量がある場合は、エラーの発生を示す 824 エラーをすべて記録し、エラー カウンタの値を増やします。
修復、復元、または割り当て解除による修正の後に、ページにエラーがある場合は、number_of_errors カウントの値を増やし、last_update 列を更新します。
リストされているページが復元や修復操作によって修正された場合は、そのページが修復 (event_type = 5) または復元 (event_type = 4) されたことを示すために suspect_pages の行を更新します。
DBCC チェックを実行すると、エラーのないページは修復済み (event_type = 5) または割り当て解除済み (event_type = 7) としてマークされます。
suspect_pages テーブルに対する自動更新
次のいずれかの理由によりデータ ファイルのページの読み取りに失敗すると、データベース ミラーリング パートナーは suspect_pages テーブルを更新します。
オペレーティング システムの CRC エラーによって発生した 823 エラー
824 エラー (破損ページなどの論理破損)
次に示す操作を行うと、suspect_pages テーブルの行が自動的に削除されます。
ALTER DATABASE REMOVE FILE。
DROP DATABASE
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS を実行すると、割り当て解除または修復を行った各ページを示すため suspect_pages テーブルが更新されます。
RESTORE でも、一覧が更新されます。完全復元、ファイル復元、またはページ復元を行うと、復元されたページのエントリが復元済みとしてマークされます。
データベース管理者が担う管理の役割
suspect_pages テーブルの管理は、主に古い行を削除することで、データベース管理者が行います。suspect_pages テーブルのサイズには制限があり、このテーブルに空き領域がなくなると新しいエラーはログに記録されません。このテーブルがいっぱいになるのを防ぐには、データベース管理者またはシステム管理者が、手動でこのテーブルから行を削除することによって古いエントリを削除する必要があります。そのため、復元済みまたは修復済みの event_type を含む行や、古い last_update 値を含む行を定期的に削除またはアーカイブすることをお勧めします。
suspect_pages テーブルの処理を監視するには、Database Suspect Data Page イベント クラスを使用します。一時的なエラーが原因で、suspect_pages テーブルに行が追加されることがあります。このテーブルに多数の行が追加されている場合、I/O サブシステムに問題がある可能性があります。テーブルに追加されている行数が急激に増加している場合は、I/O サブシステムの考えられる問題を調査することをお勧めします。
データベース管理者は、レコードの挿入や更新も行うことができます。たとえば、問題のあるページが実際には一貫性の取れている状態であることが確かであっても、しばらくレコードを残しておきたい場合に、行を更新できると便利です。
例
次の例は、suspect_pages テーブルの行の一部を削除します。
' Select restored, repaired, or deallocated pages.
DELETE FROM msdb..suspect_pages
WHERE (event_type = 4 OR event_type = 5 OR event_type = 7);
GO
次の例は、suspect_pages テーブルにある不適切なページを選択します。
' Select nonspecific 824, bad checksum, and torn page errors.
SELECT * FROM msdb..suspect_pages
WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);
GO