トランザクションログ構成の問題

最後の2つの投稿では、生成されるトランザクションログの量を減らす方法と、トランザクションログを常に適切にクリアできるようにする方法について説明しました。この投稿では、トランザクションログのパフォーマンスのテーマを継続し、問題を引き起こす可能性のあるトランザクションログの構成の問題について説明します。

VLFが多すぎます

トランザクションログは仮想ログファイル（VLF）と呼ばれるチャンクに分割されるため、ログ管理システムは、トランザクションログのどの部分を再利用できるかを簡単に追跡できます。トランザクションログを作成するとき、手動で拡張するとき、または自動拡張するときに取得するVLFの数の式があります。

たとえば、トランザクションログを8 GBに作成すると、16個のVLFが得られ、それぞれが約512MBになります。その後、ログをさらに4 GB増やすと、さらに16個のVLFが得られ、それぞれが約256 MB、合計32個のVLFになります。

注：このアルゴリズムは、VLFフラグメンテーションの問題を軽減するために、SQL Server 2014でわずかに変更されました。詳細については、このブログ投稿を参照してください

一般的なベストプラクティスは、ログの自動拡張をデフォルトの10％以外に設定することです。これにより、新しいトランザクションログスペースをゼロで初期化するときに必要な一時停止を制御できます。 256MBのトランザクションログを作成し、自動拡張を32MBに設定すると、ログは16GBの定常状態のサイズに拡張するとします。上記の式を考えると、これにより、トランザクションログに2,000を超えるVLFが含まれるようになります。

この多くのVLFにより、トランザクションログを処理する操作（クラッシュリカバリ、ログクリア、ログバックアップ、トランザクションレプリケーション、データベースの復元など）でパフォーマンスの問題が発生する可能性があります。この状況は、VLFフラグメンテーションがあると呼ばれます。一般に、1,000を超えるVLFの数は問題があり、対処する必要があります（私が今まで聞いた中で最も多いのは、サイズが1TBを超えるトランザクションログの154万のVLFです！）。

持っているVLFの数を知る方法は、文書化されていない（そして完全に安全な）DBCC LOGINFOを使用することです。 指図。出力の行数は、トランザクションログ内のVLFの数です。数が多すぎると思われる場合、それらを減らす方法は次のとおりです。

1. ログのクリアを許可する
2. ログを手動で縮小する
3. ログが小さいサイズに達するまで手順1と2を繰り返します（これは、ビジー状態の本番システムでは扱いにくい場合があります）。
4. ログを必要なサイズに手動で最大8GBのステップで拡大し、各VLFが約0.5GBを超えないようにします

VLFフラグメンテーションの問題とそれらを修正するプロセスの詳細については、次のURLを参照してください。

• VLF数の削減をアドバイスするMicrosoftKBの記事
• ログファイルの増加はDMLに影響しますか？
• トランザクションログのスループットを向上させるための8つのステップ

Tempdb

Tempdbは、他のデータベースと同じようにトランザクションログを構成する必要があり、他のデータベースと同じように大きくなる可能性があります。ただし、問題を引き起こす可能性のある陰湿な動作もあります。
SQL Serverインスタンスが何らかの理由で再起動すると、tempdbのデータとログファイルは最後に設定されたサイズに戻ります。これは、インスタンスの再起動後も現在のサイズのままである他のすべてのデータベースとは異なります。

この動作は、tempdbトランザクションログが通常のワークロードに対応するように増大した場合、ALTER DATABASEを実行する必要があることを意味します。 ログファイルのサイズを設定します。そうしないと、インスタンスの再起動後にサイズが低下し、再度大きくする必要があります。ログファイルが拡大または自動拡大するたびに、新しいスペースをゼロで初期化する必要があり、それが行われている間、ログアクティビティは一時停止します。したがって、tempdbログファイルのサイズを正しく管理しないと、インスタンスを再起動するたびにサイズが大きくなるため、パフォーマンスが低下します。

通常のログファイルの縮小

データベースのトランザクションログが通常の操作（たとえば、毎週のデータインポート）から大きくなった後、通常どのように縮小するかをよく耳にします。これは良いことではありません。

上で説明したように、トランザクションログが拡大または自動拡大するたびに、ログファイルの新しい部分がゼロで初期化されるまで一時停止します。サイズXに拡大するためにトランザクションログを定期的に縮小している場合は、トランザクションログが再びサイズXに自動拡大するため、定期的にパフォーマンスの問題が発生していることを意味します。

トランザクションログがサイズXまで増え続ける場合は、そのままにしておきます。事前にサイズXに設定し、上記で説明したようにVLFを管理し、通常のワークロードに必要なサイズとしてサイズXを受け入れます。トランザクションログが大きくても問題はありません。

複数のログファイル

データベース用に複数のログファイルを作成しても、パフォーマンスは向上しません。ただし、既存のログファイルの容量が不足していて、単純なリカバリモデルに切り替えてチェックポイントを実行することでトランザクションログを強制的にクリアしたくない場合は、2つ目のログファイルを追加する必要があります（これにより、ログのバックアップが中断されます）チェーン）。

2番目のログファイルを削除する差し迫った理由があるのか​​、それともそのままにしておいてよいのかとよく聞かれます。答えは、できるだけ早く削除する必要があるということです。

2番目のログファイルはワークロードのパフォーマンスの問題を引き起こしませんが、ディザスタリカバリには影響します。データベースが何らかの理由で破壊された場合は、データベースを最初から復元する必要があります。復元シーケンスの最初のフェーズは、データとログファイルが存在しない場合はそれらを作成することです。

ゼロ初期化をスキップするインスタントファイル初期化を有効にすることで、データファイルの作成をほぼ瞬時に行うことができますが、これはログファイルには適用されません。つまり、復元では、完全バックアップが作成されたときに存在していた（またはトランザクションログバックアップの対象期間中に作成された）すべてのログファイルを作成し、それらをゼロ初期化する必要があります。 2番目のログファイルを作成して再度ドロップするのを忘れた場合、ディザスタリカバリ操作中にゼロで初期化すると、合計ダウンタイムが増加します。これはワークロードのパフォーマンスの問題ではありませんが、サーバー全体の可用性に影響します。

データベーススナップショットからの復帰

私のリストの最後の問題は、実際にはSQLServerのバグです。バックアップを復元せずに（スナップショットからの復帰と呼ばれる）既知の時点にすばやく回復する方法としてデータベーススナップショットを使用すると、時間を大幅に節約できます。ただし、大きな欠点があります。

データベースがデータベーススナップショットから復帰すると、トランザクションログは2つの0.25MBVLFで再作成されます。つまり、トランザクションログを最適なサイズと数のVLFに戻す必要があります（または、自動的に増加します）。これまでに説明したすべてのゼロ初期化とワークロードの一時停止を伴います。明らかに望ましい動作ではありません。

概要

この投稿と以前の2つの投稿からわかるように、トランザクションログのパフォーマンスの低下につながる可能性のあることが多くあり、それが全体的なワークロードのパフォーマンスに影響を及ぼします。

これらすべてを処理できれば、健全なトランザクションログが得られます。ただし、トランザクションログを監視していることを確認する必要があるため、これで終わりではありません。自動拡張や過度の読み取りおよび書き込みI/Oレイテンシなどのアラートが表示されます。これを行う方法については、今後の投稿で説明します。