suspect_pages テーブルの管理 (SQL Server)
このトピックでは、SQL Server Management Studio または Transact-SQL を使用して、SQL Server 2012 で suspect_pages テーブルを管理する方法について説明します。 suspect_pages テーブルは、問題があると考えられるページに関する情報を保持するためのテーブルであり、復元が必要かどうかを判断する際に使用します。 SQL Server 2005 で導入された suspect_pages テーブルは、msdb データベースに保存されます。
SQL Server データベース エンジンがデータ ページの読み取りを試みたときに次のエラーのいずれかを検出すると、ページは "問題あり" と見なされます。
823 エラー。ディスク エラー (特定のハードウェア エラー) など、オペレーティング システムで実行された巡回冗長検査 (CRC) によって発生したエラーです。
824 エラー。破損ページ (すべての論理エラー) などです。
問題があると考えられるすべてのページのページ ID が suspect_pages テーブルに記録されます。 データベース エンジンは、次のような通常の処理中に検出された問題のあるページを記録します。
クエリがページを読み取る必要があるとき
DBCC CHECKDB 操作の実行中
バックアップ操作の実行中
suspect_pages テーブルは、復元操作、DBCC 修復操作、データベースの削除操作などの実行中にも必要に応じて更新されます。
このトピックの内容
作業を開始する準備:
推奨事項
セキュリティ
suspect_pages テーブルを管理する方法:
SQL Server Management Studio
Transact-SQL
作業を開始する準備
推奨事項
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 テーブルに対する自動更新
次のいずれかの理由によりデータ ファイルのページの読み取りに失敗すると、データベース ミラーリング パートナーまたは AlwaysOn 可用性レプリカは suspect_pages テーブルを更新します。
オペレーティング システムの CRC エラーによって発生した 823 エラー
824 エラー (破損ページなどの論理破損)
次に示す操作を行うと、suspect_pages テーブルの行も自動的に更新されます。
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS を実行すると、割り当て解除または修復を行った各ページを示すために、suspect_pages テーブルが更新されます。
完全復元、ファイル復元、またはページ復元を行うと、復元されたページのエントリが復元済みとしてマークされます。
次に示す操作を行うと、suspect_pages テーブルの行が自動的に削除されます。
ALTER DATABASE REMOVE FILE。
DROP DATABASE
データベース管理者が担う管理の役割
suspect_pages テーブルの管理は、主に古い行を削除することで、データベース管理者が行います。 suspect_pages テーブルのサイズには制限があり、このテーブルに空き領域がなくなると新しいエラーはログに記録されません。 このテーブルがいっぱいになるのを防ぐには、データベース管理者またはシステム管理者が、手動でこのテーブルから行を削除することによって古いエントリを削除する必要があります。 そのため、復元済みまたは修復済みの event_type を含む行や、古い last_update 値を含む行を定期的に削除またはアーカイブすることをお勧めします。
suspect_pages テーブルの処理を監視するには、Database Suspect Data Page イベント クラスを使用します。 一時的なエラーが原因で、suspect_pages テーブルに行が追加されることがあります。 このテーブルに多数の行が追加されている場合、I/O サブシステムに問題がある可能性があります。 テーブルに追加されている行数が急激に増加している場合は、I/O サブシステムの考えられる問題を調査することをお勧めします。
データベース管理者は、レコードの挿入や更新も行うことができます。 たとえば、問題のあるページが実際には一貫性の取れている状態であることが確かであっても、しばらくレコードを残しておきたい場合に、行を更新できると便利です。
セキュリティ
権限
suspect_pages テーブル内のデータは、msdb へのアクセス権を持つユーザーであれば、だれでも読み取ることができます。 suspect_pages テーブルに対する UPDATE 権限を持つすべてのユーザーは、そのレコードを更新できます。 msdb の db_owner 固定データベース ロールのメンバーまたは sysadmin 固定サーバー ロールのメンバーは、レコードの挿入、更新、および削除を行うことができます。
![[トップに戻る] リンクで使用される矢印アイコン](images/ms175817.uparrow16x16(sql.110).gif "[トップに戻る] リンクで使用される矢印アイコン")
[先頭に戻る]
SQL Server Management Studio の使用
suspect_pages テーブルを管理するには
オブジェクト エクスプローラーで、SQL Server データベース エンジンのインスタンスに接続して、そのインスタンスを展開します。次に、[データベース] を展開します。
[システム データベース]、[msdb]、[テーブル]、[システム テーブル] の順に展開します。
[dbo.suspect_pages] を展開し、[上位 200 行を編集] を右クリックします。
クエリ ウィンドウで、目的の行を編集、更新、または削除します。
[先頭に戻る]
Transact-SQL の使用
suspect_pages テーブルを管理するには
データベース エンジンに接続します。
[標準] ツール バーの [新しいクエリ] をクリックします。
次の例をコピーしてクエリ ウィンドウに貼り付け、[実行] をクリックします。 次の例は、suspect_pages テーブルからいくつかの行を削除します。
-- Delete 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
[先頭に戻る]