ログの切り捨てが遅れる原因となる要因

ログの切り捨てによりログ ファイルの領域が解放され、トランザクション ログで再利用できるようになります。ログのアクティブな部分は、切り捨てたり削除したりできません。そのため、ログ レコードが長い間アクティブなままになると、切り捨てが遅れる場合があります。

注意

ログを切り捨てるしくみについては、「トランザクション ログの切り捨て」を参照してください。

このトピックで示すさまざまな状況では、ログ レコードがアクティブなままになることもあります。ログの切り捨てを妨げている原因は、sys.databases カタログ ビューの log_reuse_wait 列と log_reuse_wait_desc 列を使用して見つけることができます。

注意

非常に実行時間の長いトランザクションや、一時停止中のデータベース ミラーリング セッションなど、これらの要因のいくつかが原因で、トランザクション ログがいっぱいになることがあります。トランザクション ログがいっぱいになった場合の対処方法については、「満杯になったトランザクション ログのトラブルシューティング (エラー 9002)」を参照してください。

次の表では、sys.database カタログ ビューの log_reuse_wait 列と log_reuse_wait_desc 列の値について説明します。

log_reuse_wait value

log_reuse_wait_desc value

説明

0

NOTHING

現在 1 つ以上の再利用可能な仮想ログ ファイルがある。

1

CHECKPOINT

最後にログの切り捨てを行ってからチェックポイントが発生していないか、ログの先頭が仮想ログ ファイルを超えて移動していない (すべての復旧モデル)。

これは、ログの切り捨てが遅れる一般的な原因です。詳細については、「チェックポイントとログのアクティブな部分」を参照してください。

2

LOG_BACKUP

ログの先頭を前方に移動するためにログ バックアップが必要である (完全復旧モデルまたは一括ログ復旧モデルのみ)。

注意
ログ バックアップにより切り捨てが妨げられることはありません。

ログ バックアップが完了した時点で、ログの先頭が前方に移動され、ログ領域の一部が再利用可能になります。

3

ACTIVE_BACKUP_OR_RESTORE

データ バックアップまたは復元が実行中である (すべての復旧モデル)。

データ バックアップはアクティブなトランザクションと同様の影響があり、バックアップの実行中には、切り捨てが行われません。詳細については、このトピックの「データのバックアップ操作と復元操作」を参照してください。

4

ACTIVE_TRANSACTION

トランザクションがアクティブである (すべての復旧モデル)。

  • 実行時間の長いトランザクションがログ バックアップの先頭に存在する可能性がある。この場合、領域を解放するには再度ログ バックアップが必要になります。詳細については、このトピックの「実行時間の長いアクティブなトランザクション」を参照してください。

  • トランザクションが遅延 (SQL Server 2005 Enterprise Edition 以降のバージョンのみ)。遅延トランザクションは、一部リソースが確保できないためにロールバックがブロックされている、実質的にはアクティブなトランザクションです。遅延トランザクションの原因、およびトランザクションの遅延を解決する方法については、「遅延トランザクション」を参照してください。

5

DATABASE_MIRRORING

データベース ミラーリングが一時中断されるか、高パフォーマンス モードでは、ミラー データベースがプリンシパル データベースに大幅に遅れる (完全復旧モデルのみ)。

詳細については、このトピックの「データベース ミラーリングとトランザクション ログ」を参照してください。

6

REPLICATION

トランザクション レプリケーション中、パブリケーションに関連するトランザクションがディストリビューション データベースにまだ配信されていない (完全復旧モデルのみ)。

詳細については、このトピックの「トランザクション レプリケーションとトランザクション ログ」を参照してください。

7

DATABASE_SNAPSHOT_CREATION

データベース スナップショットが作成されている (すべての復旧モデル)。

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。

8

LOG_SCAN

ログ スキャンが行われている (すべての復旧モデル)。

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。

9

OTHER_TRANSIENT

この値は現在使用されていません。

データのバックアップ操作と復元操作

バックアップ操作や復元操作の間は、ログの切り捨ては行われません。SQL Server 2005 以降のバージョンでは、ログ バックアップはデータ バックアップ中に実行できます。ただし、データ バックアップ操作からすべてのトランザクション ログが使用できる必要があるため、そのようなログ バックアップ中にログの切り捨てを実行することはできません。データ バックアップによってログの切り捨てが妨げられる場合、バックアップをキャンセルすると、当面の問題には対処できます。

ログの切り捨ての詳細については、「トランザクション ログの切り捨て」を参照してください。

実行時間の長いアクティブなトランザクション

アクティブなトランザクションでは、トランザクションの開始が格納されているログ レコード以降のログがアクティブなままになっている必要があります。たとえば、トランザクションの開始と終了をユーザーが制御する場合、トランザクションの実行時間が長くなる一般的な原因は、トランザクションを開始したユーザーが、トランザクションがユーザーからの応答を待っているにもかかわらず、席を外してしまうことです。このような場合、待機状態のトランザクション自体によって生成されるログ量はわずかですが、ログの切り捨てが停止されるため、ログが大きくなります。

注意

実行時間の長いトランザクションを回避する方法については、「効率的なトランザクションのコーディング」を参照してください。

データベース ミラーリングとトランザクション ログ

データベース ミラーリングでは、プリンシパル サーバー インスタンスが、ミラー サーバー上のディスクにレコードが書き込まれたという通知をミラー サーバー インスタンスから受け取るまで、各ログ レコードがアクティブなままであることが必要です。ミラー サーバー インスタンスがプリンシパル サーバー インスタンスから遅れると、それに応じてアクティブなログ領域の量が増えます。その場合、データベース ミラーリングを停止し、ログのバックアップを行ってログを切り捨て、ログのバックアップをミラー データベースに適用し (WITH NORECOVERY を使用)、ミラーリングを再開する必要があります。

重要な注意事項重要

さらに、必要なログ バックアップの後に作成された追加のログ バックアップがある場合は、ミラーリングを開始する前に、それらすべてを手動で適用する必要もあります (毎回 WITH NORECOVERY を使用します)。最新のログ バックアップの適用が完了した後に、ミラーリングを開始できます。

詳細については、「データベース ミラーリングの削除」および「データベース ミラーリングの設定」を参照してください。

トランザクション レプリケーションとトランザクション ログ

マージ レプリケーションとスナップショット レプリケーションではトランザクション ログのサイズに影響はありませんが、トランザクション レプリケーションでは影響があります。データベースに 1 つ以上のトランザクション パブリケーションが含まれていると、パブリケーションに関係するすべてのトランザクションがディストリビューション データベースに配信されるまで、ログは切り捨てられません。トランザクション ログが大きくなりすぎ、ログ リーダー エージェントをスケジュールによって実行している場合は、実行間隔を短くするか、連続モードで実行することを検討してください。連続モードで実行するように設定されている場合は (既定値)、実行中であることを確認してください。ログ リーダー エージェントの状態を確認する方法の詳細については、「パブリケーションに関連付けられているエージェントの情報を表示したりタスクを実行する方法 (レプリケーション モニタ)」を参照してください。

また、パブリケーション データベースまたはディストリビューション データベース上で "sync with backup" オプションを設定している場合は、すべてのトランザクションのバックアップが完了するまではトランザクション ログが切り捨てられません。トランザクション ログが大きくなりすぎ、かつ、このオプションを設定している場合は、トランザクション ログのバックアップ間隔を短くしてください。トランザクション レプリケーションに関連するデータベースのバックアップと復元の方法の詳細については、「スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式」を参照してください。

レプリケーションを管理するには

レプリケーションを監視するには