SQLServerトランザクションログの基本

トランザクションログとは何ですか？

リレーショナルデータベースシステムには、トランザクションが永続的でなければならないという要件があります。これは、トランザクションのACIDプロパティの「D」です。システムは、突然のクラッシュが発生した場合に、トランザクションを再生できることを確認する必要があります。 SQL Serverは、トランザクションログファイルと呼ばれる物理ファイルにすべてのトランザクションをキャプチャすることで、この要件を満たします。。

基本的に、トランザクションがコミットされるたびに、SQLServerはそのトランザクションによって生成された変更をトランザクションログに記録します。トランザクションがデータファイルに永続化されていない場合でも、トランザクションログで利用可能であり、突然のクラッシュが発生した場合に再生できます。

リカバリモデルとトランザクションログ

SQL Serverは、フル、バルクログ、シンプルの3つのリカバリモデルで動作します。

フルリカバリモードでは、すべてのトランザクションがログに記録されます。したがって、クラッシュが発生した場合、データベースを完全に回復できます。これは、トランザクションまたは関連するバックアップが使用可能な場合、データベースのバックアップを特定の時点に復元できることも意味します。フルログおよびバルクログリカバリモードでは、ログバックアップが実行されるたびにトランザクションログが切り捨てられます。

Simple Recoveryモードでは、すべてのトランザクションが引き続きログに記録されます。ただし、データベースがチェックポイントを実行するたびに、トランザクションログ操作は切り捨てられます。

チェックポイントは、SQLServerがダーティバッファをデータファイルに書き込むときに発生します。ダーティバッファは、メモリ内の状態がディスク内の状態と一致しないなど、トランザクションによって変更されたメモリに格納されている重要なページです。ただし、ここではこれについては説明しません。シンプルリカバリモードでは、SQL Serverはこれらすべての変更をトランザクションログにキャプチャして、永続化されるまで保持します。

トランザクションログの構造

トランザクションログは、SQLServerデータベースがホストされているサーバーのOSレイヤーに表示される物理ファイルです。各データベースには1つのトランザクションログがありますが、さらに多くのトランザクションログを構成することができます。重要なのは、複数のトランザクションSQLログがあっても、パフォーマンス上の利点はありません。 SQL Serverは、トランザクションログに順番に書き込みます。次のファイルを使用するには、1つのファイルがいっぱいである必要があります。ただし、別々のディスクにある複数のファイルは、最初のファイルがいっぱいになった場合に1日を節約できます。

内部的には、トランザクションログファイルは一連の仮想ログファイルです。これらのファイルのサイズと数は、データベースのバックアップまたはオンラインにするのにかかる時間に影響します。トランザクションログのサイズを適切に設定し、自動拡張設定が期待されるアクティビティのレベルに適合していることを確認することをお勧めします。そうすれば、ファイルの増大はあまり頻繁には起こりません。

ログを成長させるものは何ですか？

リスト1のコードを使用して小さなデータベースを作成することから始めましょう。データファイルのサイズは4MBで、ログファイルは最初は2MBです。特に事前割り当ての一般的な方法では、本番データベースがこのサイズになることはありません。。このようなサイズは、デモンストレーションの目的でのみ選択しました。

-- Listing 1: Create a Small Database

create database tranlogexperiment
on primary 
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go

そのデータベースに、追加のデータ操作言語（DML）ステートメント用の単一のテーブルを作成します（リスト2）。

-- Listing 2: Create a Table

use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)

リスト3のコードを実行することで、実行したことを確認および検証します。

-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';

select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');

ファイルサイズに注意してください桁。 INSERTとDELETEを100,000回実行して、トランザクションログの増加を呼び出します（リスト4）。

-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000

リスト4は、 txn_logに単一の行を挿入しますテーブルを作成し、同じ行を削除して、このアクションを100,000回繰り返します。

全体として、このアクティビティのためにテーブルは大きくなりませんが、トランザクションログは大幅に大きくなります。リスト4のDMLステートメントを実行した後にリスト3のクエリを繰り返すと、トランザクションログがどれだけ増加したかがわかります。

データファイルのサイズは変更されていませんが、このアクティビティにより、トランザクションログは4MBから40MBに増加しました。これは、トランザクションログのサイズがデータサイズとはほとんど関係がないことを明確に示しています。サイズへの影響は、データベースで発生するアクティビティ（DML）によるものです。

トランザクションログを管理するにはどうすればよいですか？

IaaSインストールのSQLServerのオンプレミスインスタンスを管理するデータベース管理者は、トランザクションログのバックアップを定期的にバックアップする必要があります。 LogShippingやAlwaysOnAGなどのディザスタリカバリ構成があると便利です。。このような構成では、バックアップが自動的に実行されます。

フルリカバリモードでは、SQL Serverログバックアップは、リカバリに不要になったトランザクションログ部分を切り捨てます。ログの切り捨てにより、非アクティブな仮想ログファイルが削除されます。このようにして、トランザクションログのスペースをクリアして再利用します。

リスト6のコードは、トランザクションログのサイズとその中にある空き領域の量を示しています。

-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name], 
    name AS [Logical File Name], 
    type_desc,
    size/128.0 AS [Current Size (MB)],  
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);

リスト7のコードを使用して、物理トランザクションログを縮小することもできます。縮小する前に、トランザクションログのバックアップを作成してください。本番環境では、ログバックアップをスケジュールして、制御されていない物理ログファイルの増大を回避し、データが確実に保持されるようにするのが最善です。 LogShippingやAlwaysOnAGなどのディザスタリカバリオプションを使用する構成済みで、これはすでに許可されています。

log_reuse_wait_descをクエリできます sys.databasesの列カタログビューを使用して、トランザクションログの縮小を妨げる条件を特定します。リスト3のこの列にクエリを実行したことに注意してください。

このような状態は、保留中のチェックポイント、保留中のログバックアップ、進行中のバックアップまたは復元、アクティブな長時間実行トランザクション、およびデータベース内の同様のアクティビティである可能性があります。

-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO

リスト8のコードを使用して、データベースをバックアップします。特定のケースでは、ログバックアップは常に完全バックアップを参照するため、最初に完全バックアップを作成する必要があります。「最後の」完全バックアップは、ポイントインタイムリカバリを処理するときにチェーンを開始します。

-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';

シンプルリカバリモードでデータベースを実行している場合、トランザクションログはチェックポイントごとに切り捨てられます。。このモードでは、ログのバックアップはできません。

トランザクションログファイルの場所は、時折発生する長時間のトランザクションに対応できるように適切なサイズにする必要があります。そうしないと、トランザクションログがディスク領域をいっぱいにする可能性があります。図4は、バックアップが作成されたときにログが内部的にどうなるかを示しています。物理ファイルはまだ40MBですが、約37MBの空き容量があることに注意してください。

シンプルリカバリモードではどうなりますか？

それでは、 tranlogexperimentを設定しましょう。データベースをシンプルリカバリモードにします。

-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;

リスト4で前述したコードを実行すると、動作が少し異なります。

図6は、リスト4のコードを実行したときのシンプルリカバリモードでのトランザクションログの増加を示しています。物理ログファイルのサイズはわずか15MBです。これは、以前の完全復旧モデルの場合よりも半分少なくなっています。また、11.5MBの空き容量にも注意してください。

対数関数的成長が少なかったことを意味しますか？

いいえ。図7は、セッションの実行中に、SQLServerがいくつかのチェックポイントも実行したことを示しています。 これによりログが切り捨てられ、トランザクションが定期的にログの増加を再開する余地が生まれました。

結論

トランザクションログは、SQLServerデータベースの非常に重要なコンポーネントです。これは、バックアップ、復元、障害復旧など、リカバリを必要とする、またはリカバリに依存するすべてのものに影響を与えます。 dbアクティビティをログに記録することもできます。

この記事では、トランザクションログの性質、適切な管理の側面について説明し、完全リカバリモードまたは単純リカバリモードが設定されているデータベースでのDMLの動作を示しました。ただし、トランザクションログについて学ぶことはまだまだたくさんあります。参照のエントリは、あなたにとって良い出発点になります。

参照 s

トランザクションログ
SQLServerデータベースとストレージ

また読む

SQLServerでのトランザクションログの重要性