suspect_pages テーブルの管理 (SQL Server)
このトピックでは、SQL Server Management Studio または Transact-SQL を使用して、SQL Server 2014 のsuspect_pages テーブルを管理する方法について説明します。 suspect_pages テーブルは、問題があると考えられるページに関する情報を保持するためのテーブルであり、復元が必要かどうかを判断する際に使用します。 suspect_pages テーブルは、 msdb データベースにあります。
SQL Server データベース エンジン がデータ ページの読み取りを試みたときに次のエラーのいずれかを検出すると、ページは "問題あり" と見なされます。
ディスク エラー (特定のハードウェア エラー) など、オペレーティング システムによって発行された循環冗長チェック (CRC) によって発生した 823 エラー
破損ページ (論理エラー) などの 824 エラー
問題があると考えられるすべてのページのページ ID が suspect_pages テーブルに記録されます。 データベース エンジン は、次のような通常の処理中に検出された問題のあるページを記録します。
クエリがページを読み取る必要があるとき
DBCC CHECKDB 操作の実行中
バックアップ操作の実行中
suspect_pages テーブルは、復元操作、DBCC 修復操作、データベースの削除操作などの実行中にも必要に応じて更新されます。
このトピックの内容
作業を開始する準備:
suspect_pages テーブルを管理する方法:
はじめに
推奨事項
suspect_pages テーブルに記録されるエラー
suspect_pages テーブルには、824 エラーにより失敗したページごとに 1 行ずつ、上限を 1,000 行として格納されます。 次の表に、 suspect_pages テーブルの event_type 列にログ記録されるエラーを示します。
エラーの説明 event_type 値 オペレーティング システムの CRC エラーまたは 824 エラーが原因で発生した 823 エラー (不適切なチェックサムまたは破損したページ以外のエラー )(不適切なページ ID など) 1 不適切なチェックサム 2 正しくないページ 3 復元済み (ページは不適切と見なされた後で復元されました) 4 修復済み (DBCC、AlwaysOn、またはミラーリングで修復されたページ) 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 サブシステムの考えられる問題を調査することをお勧めします。
データベース管理者は、レコードの挿入や更新も行うことができます。 たとえば、問題のあるページが実際には一貫性の取れている状態であることが確かであっても、しばらくレコードを残しておきたい場合に、行を更新できると便利です。
セキュリティ
アクセス許可
msdb に対するアクセスを持つユーザー は、 suspect_pages テーブルのデータを読み取ることができます。 suspect_pages テーブルに対する UPDATE 権限を持つすべてのユーザーは、そのレコードを更新できます。 msdb の db_owner 固定データベース ロールのメンバーまたは sysadmin 固定サーバー ロールのメンバーは、レコードの挿入、更新、および削除を行うことができます。
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
参照
DROP DATABASE (Transact-SQL)
RESTORE (Transact-SQL)
BACKUP (Transact-SQL)
DBCC (Transact-SQL)
ページ復元 (SQL Server)
suspect_pages (Transact-SQL)
MSSQLSERVER_823
MSSQLSERVER_824