トランザクションログの監視

昨年、私はSQLPerformance.comでトランザクションログのパフォーマンスの問題について何度かブログを書き（ここを参照）、トランザクションログの監視について話し合うことを約束しました。これについてはこの投稿で行います。追跡できるいくつかの指標、気にする必要がある理由、および示された問題に対処するためのアドバイスを紹介します。

DMV

トランザクションログのI/Oレイテンシを監視する最も簡単な方法は、sys.dm_io_virtual_file_statsを使用することです。 DMV。有用な結果を得るには、いくつかの計算を実行する必要があります。このデモzipファイルのVirtualFileStats.sqlスクリプトでサンプルコードを取得できます。トランザクションログの書き込みレイテンシが5ミリ秒未満であることを本当に確認したいのです。

11月の初めに、世界中の25,000を超えるデータベースのトランザクションログとtempdbデータファイルのレイテンシを示す調査結果をブログに書きました（ここを参照）。データベースの80％がトランザクションログの書き込みレイテンシの5ミリ秒以下のマークに達しました。

書き込みレイテンシが5ミリ秒を超える場合は、次のことができます。

• 以前の投稿で説明したように、生成されるログの量や小さなトランザクションから発生するログフラッシュの量を減らすように努めます。
• 上記の調査ブログ投稿で説明したトラブルシューティング手順のいくつかに従ってください。
• より高速なI/Oサブシステムに移行します。SSDを使用する場合は、RAID-1構成で2つ使用する必要があることに注意してください。

もう1つできることは、2008 R2以前（SQL Server 2012以降から2012年に引き上げられた）の各データベースのトランザクションログに対して、32の未処理の書き込みI/Oのハード制限に達していないことを確認することです。物理ディスク/平均を確認することで、これを試すことができます。ディスク書き込みキューの長さですが、これはファイルごとではなくボリューム全体の長さであるため、関心のあるログファイル以外にボリューム上に何かがある場合、有効な数は得られません。より良い方法は、sys.dm_io_pending_io_requestsの結果を集約することです。 DMV。すべての未処理のI/Oが一覧表示されます。これを行うためのコードは次のとおりです。

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

これを簡単に変更して、ログファイルの結果のみを表示することができます（type_desc ='LOG'のフィルター ）そしてあなたが興味を持っているデータベースIDのためだけに。

特定のデータベースの32の制限に達していることがわかった場合は、次のことができます。

• 小さなトランザクションの数を減らし、データ変更操作中に変更されるページ分割や未使用/重複インデックスなどに注意することで、発生するログフラッシュの量を減らします。ログフラッシュの最適化について詳しくは、このブログ投稿をご覧ください。
• より高速なI/Oサブシステムを使用してみてください
• SQLServer2012以降にアップグレードします。制限は112です。
• delayed durability featureをお試しください SQLServer2014で追加されたDMV
• 最後の手段として、ワークロードを複数のデータベースまたはサーバーに分割します

トランザクションによって生成されているトランザクションログの量を確認したい場合は、sys.dm_tran_database_transactionsを使用できます。 DMV、以下のようなコードで：

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

特に一時オブジェクトを使用するコードのtempdbで、生成されるログの量に非常に驚かれるかもしれません。そしてもちろん、tempdbのトランザクションログは、ユーザーデータベースの場合と同じようにボトルネックになる可能性があります。

パフォーマンスモニターカウンター

ログ関連のパフォーマンスカウンターはすべてデータベースパフォーマンスオブジェクトにあります。注目すべき主なもののいくつかを次に示します（パフォーマンスモニター自体、SQLエージェントアラートの使用、sys.dm_os_performance_counters DMVの使用、またはお気に入りのサードパーティの監視ツールのいずれかを使用）：

ログの増加

データベースで何かが発生し、現在のスペースよりも多くのトランザクションログが生成されていることを示しているため、このカウンターが増加することは望ましくありません。これは、トランザクションログをクリアできないことを意味するため、sys.databasesのlog_reuse_wait_descフィールドにクエリを実行して原因を調査し、必要なアクションを実行する必要があります（詳細については、Books Onlineのトピック「ログの切り捨てを遅らせる可能性のある要因」を参照してください）。いくつかのサンプルコードは次のようになります：

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

ログの増加が発生するたびに、トランザクションログの新しく割り当てられた部分をゼロにする必要があり、さらに仮想ログファイルを追加する必要があります。どちらも、以前ブログで書いたように問題を引き起こす可能性があります。

ログの縮小

制御不能なトランザクションログを制御下に戻すために縮小操作を実行している人でない限り、このカウンターが増加するのを見たくありません。誰かが正当な理由もなくトランザクションログを縮小した場合、それは再び大きくなる可能性があり、以前にブログで書いたように問題を引き起こします。

使用されたログの割合

このカウンターを監視し、値が90％を超えるかどうかを心配する必要があります。これは、前述のように、ログの増加が差し迫っていて、トランザクションログを正しくクリアできないことを示しているためです。

ログフラッシュ待機/秒

この値を同じままにするか、減らす必要があります。増加する場合は、ログの多くの小さな部分をフラッシュしているため、I/Oサブシステムのボトルネックまたはログフラッシュメカニズム内のボトルネックがあることを意味します。ここでの増加は、ログの32個の未処理のI/Oにヒットすることとも相関している可能性があります。 sys.dm_io_pending_io_requestsの説明を参照してください 詳細については上記をご覧ください。

Log Bytes Flushed/secおよびLogFlushes/ sec

これらの2つのカウンターを使用すると、最初のカウンターを2番目のカウンターで割ることにより、平均ログフラッシュサイズを計算できます。結果は、512から61440の間の値になります（それぞれ、ログフラッシュの最小サイズと最大サイズ）。値が低いほど、ログフラッシュ待機/秒の増加と相関する可能性が高くなります。繰り返しになりますが、sys.dm_io_pending_io_requestsの説明を参照してください。 詳細については上記をご覧ください。

拡張イベント

上級者向けに、ログで何が起こっているかを監視するために使用できる拡張イベントがいくつかあります。 SQL Server2012SSMSのデータベースログファイルIOトラッキングテンプレートを使用することから始めることをお勧めします。これを行うには、オブジェクトエクスプローラーに移動し、インスタンス->管理->拡張イベントに移動し、[セッション]を右クリックして[新しいセッションウィザード]を選択します。表示されるウィンドウで、セッション名を入力し、ドロップダウンからトラッキングテンプレートを選択します。次に、Ctrl + Shift + Nを押すと、セッションがクエリウィンドウにスクリプト化されます。残念ながら、そこにあるすべての詳細はこの投稿の範囲を超えていますが、テンプレートの説明はかなり説明的です：

SQL Server 2012には、transaction_logと呼ばれる新しい拡張イベントもあります。これを使用して、生成されているログレコードのあらゆる種類の興味深い分析を実行できます。これは間違いなく、今後の投稿で取り上げるテーマです。

概要

上記のすべての情報があれば、かなり優れたトランザクションログ監視システムを思い付くことができるはずです。トランザクションログの状態は、ワークロードが正常に実行されていることを確認するために最も重要です。このシリーズの4つの投稿（および他のすべてのリンク）が、SQLServer環境の全体的なパフォーマンスの向上に役立つことを願っています。