次の方法で共有


ゴースト クリーンアップ プロセス ガイド

ゴースト クリーンアップは、DML ステートメントによって削除対象としてマークされた行を物理的に削除するバックグラウンド プロセスです。 次の記事では、このプロセスの概要について説明します。

ゴースト行

インデックスのリーフ レベル ページから削除された行は、ページから物理的に削除されません。 代わりに、行は今後削除されるようにマークされるか、 ゴースト化されます。 つまり、行はページ上にとどまりますが、行ヘッダーで少し変更され、行がゴーストであることを示します。 これは、削除操作中のパフォーマンスを最適化するためのものです。 ゴーストは、行レベルのロックと、データベース エンジンが古い行バージョンを維持する必要があるスナップショット分離トランザクションに必要です。

ゴースト クリーンアップ タスク

削除対象としてマークされた行または ゴースト化された行は、不要になったときにバックグラウンド ゴースト クリーンアップ プロセスによってクリーンアップされます。 ゴースト クリーンアップは定期的に実行され、ページにゴースト行があるかどうかを確認します。 見つかると、これらの行が物理的に削除されます。 データベース エンジン インスタンス上のすべてのデータベースに対して 1 つのゴースト クリーンアップ スレッドがあります。

行がゴースト化されると、データベースはゴースト エントリを持つものとしてマークされます。 ゴースト クリーンアップ プロセスでは、このようなデータベースのみがスキャンされます。 また、ゴースト クリーンアップ プロセスでは、すべての非実体行が削除されると、データベースにゴースト行がないことをマークし、次回の実行時にこのデータベースをスキップします。 このプロセスでは、データベースの共有ロックを取得できない場合は、データベースもスキップされます。 次にデータベースを実行すると、データベースのロック取得が再試行されます。

次のクエリは、データベース内のゴースト化された行の概数を返します。

SELECT SUM(ghost_record_count) AS total_ghost_records,
       DB_NAME(database_id) AS database_name
FROM sys.dm_db_index_physical_stats(NULL, NULL, NULL, NULL, 'SAMPLED')
GROUP BY database_id
ORDER BY total_ghost_records DESC;

ゴースト クリーンアップを無効にする

削除が多い負荷の高いシステムでは、バッファー プール内の頻繁にアクセスされるページの多くを、ゴースト行がある他のページに置き換えた場合、ゴースト クリーンアップ プロセスによってパフォーマンスが低下する可能性があります。 その結果、頻繁にアクセスされるページをディスクから再読み取りする必要があり、追加のディスク I/O が生成され、クエリの待機時間が長くなります。 この場合は、 トレース フラグ 661 を使用してゴースト クリーンアップを無効にすることができます。

ゴースト クリーンアップを行わないと、データベースが不必要に大きくなる可能性があり、I/O とメモリの消費が増えてパフォーマンスが低下する可能性もあります。 ゴースト クリーンアップ プロセスではゴーストとしてマークされている行が削除されるため、プロセスを無効にすると、これらの行がページ上に残り、データベース エンジンがこの領域を再利用できなくなります。 これにより、データベース エンジンは新しいページにデータを強制的に追加し、データベース ファイルが肥大化し、 ページ分割が発生する可能性もあります。 ページ分割によってディスク I/O が増え、クエリのパフォーマンスが低下する可能性があります。 ゴースト クリーンアップが無効になっている場合、データベースの領域が不足する可能性があります。

Warnung

ゴースト クリーンアップ プロセスを完全に無効にすることはお勧めしません。

ゴースト クリーンアップが無効になっているときにゴースト行を削除するには、行が削除されたテーブルのインデックスを再構築します。 インデックスを再構築すると、プロセス内のゴースト行を省略して、既存のデータから新しいページが作成されます。