複数のトランザクションログファイルとパフォーマンスへの影響
そのため、特定のデータベースに必要なトランザクションログファイルの数について、何人かの人々と議論しました。私は、データベースごとに1つのトランザクションログファイルのみが必要で、Microsoftのホワイトペーパーには何もないという投稿をいくつか見ました。ただし、多くの場合、特定のデータベースのトランザクションログファイルの数を増やすと、データベースへの書き込みパフォーマンスが実際に向上することがわかりました。これらのデータベースはすべて完全復旧モデルであり、I/Oサブシステムに大きなSANフレームを使用していることに注意してください。多くの投稿がトランザクションの書き込みがすべてシリアルで発生すると言っている場合ファイルの終わりに到達するまで1つのファイルに書き込み、その後書き込みが次のログファイルに移動しますが、ログファイルの数を増やすと、ディスクへの書き込み速度が大幅に向上するのはなぜですか？最新のIO 700からジャンプKb/sログファイルの数を1から8に増やすことで60 Mb/s以上にジャンプした場合感謝します。
トランザクションログの書き込みはシーケンシャルです。ログファイルの1つだけがeverに一度に書き込まれるため、複数のファイルを（それ自体で）変更しても、そのデータベースのI/Oパターン。
あなたが幸運になっていない限り。たとえば、2番目のログファイルをSSDまたはその他の高速またはビジーでないディスクに追加したか、ログファイルを複数のディスクに分割し、複数のデータベースに対してそれを行った場合、ログがより高速なディスク上のそのファイルに切り替えたか、他のデータ/ログファイルからより隔離されています。言い換えると、観察されたI/Oの違いは、完全に他の要因によるものであり、単なる偶然によるものであり、ログファイルのみを追加したという事実によるものではないと私は考えています。 SQL Serverは、一度に1つのログファイルのみを使用するように明示的に設計されています。つまり、現在のログファイルがより高速で分離されたディスク上にない限り、複数のログファイルがログの書き込みパフォーマンスをどのように改善できるでしょうか。私はあなたがより良い経験的証拠を提供する必要があると思います（そうすることで、パフォーマンス向上の真の原因を自分で発見することができます）。
これらの投稿をすべてお読みください。これらの投稿は、SQL Serverストレージチームで長い間働いていた非常に賢い人によって書かれたもので、私は彼がこのようなことを面白くしていないと思います。
また、キンバリー・トリップはこれについて価値ある記事で触れています：
8つの手順のいずれにもトランザクションログファイルの追加が含まれていないことに注意してください。実際、彼女はそれに反対することを勧めています。
特にそれらが大きい場合（RTOを考える）、複数のログファイルを使用することには他にも危険があり、実際に何も得ることができません。
トランザクションログファイルは、順次書き込まれて使用されます。これは、DBCC LOGINFOを使用してログファイル内の仮想ログファイル（VLF）の使用を調べることで確認できます。たとえば、データベースとテーブルがあり、そこに1000行を挿入する場合、DBCC LOGINFOは以下を提供します。
RecoveryUnitId FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
-------------- ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
0 2 3866624 8192 32 2 64 0
0 2 3866624 3874816 33 2 64 0
0 2 3866624 7741440 34 2 64 0
0 2 4120576 11608064 0 0 0 0
注意すべき重要な列は次のとおりです。
- FSeqNo-これはVLFが使用される順番です
- Status-VLFの現在のステータス。 2はアクティブ、0は再利用の準備ができていることを意味します
エンジンは一度に1つのVLFのみを使用でき、ファイルの最後に到達するまで使用可能なVLFを順番に使用します。一度実行すると、ファイル内で最初に使用可能なVLFに戻ろうとします。利用できない場合、ログファイルは大きくなります。
複数のファイルがある場合、この順序は維持されます。前のファイルのすべてのVLFが使用されるまで、2番目（または3番目または4番目）のVLFは使用できません。たとえば、2つのログファイルを持つデータベースからのDBCC LOGINFOは次のとおりです。
RecoveryUnitId FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
-------------- ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
0 2 3866624 8192 32 0 64 0
0 2 3866624 3874816 33 0 64 0
0 2 3866624 7741440 34 0 64 0
0 2 4120576 11608064 35 0 64 0
0 3 3866624 8192 36 2 64 0
0 3 3866624 3874816 37 2 64 0
0 3 3866624 7741440 38 2 64 0
0 3 4120576 11608064 39 2 64 0
FSeqNo列とStatus列をFileId（これはsys.database_filesにあるのと同じFileIDです）と関連付けることができます。 FSeqNoは、ファイル全体にまたがって順序を維持していることに注意してください。
これが、複数のログファイルが役に立たない理由です。複数のデータファイルを使用する理由は、IOストリームをこれらのファイルに配布できるためです。ただし、ログファイルへの処理はすべてラウンドロビン方式で行われるため、ログファイルからそのようなメリットを得ることはできません。
あなたの最初の考えは正しかった：複数のトランザクションログファイルを持つことには利点がありません。 SQL Serverは、トランザクションログを同時にではなく順次使用します。
ログファイルの数を増やすと、ディスクへの書き込み速度が大幅に向上するのはなぜですか。
そうではない。単に考慮されていない他の要因が含まれている必要があります（つまり、より高いスループットのためにログに記録されたトランザクションを単にプッシュして、実際に高いスループットを引き起こしていますか？ ？追加されたトランザクションログファイルは単一のログファイルよりも高速のストレージ上にあり、複数のテストの現在のトランザクションログファイルが最初のテストの単一のトランザクションログよりも優れたパフォーマンスを発揮しますか？）。
複数のトランザクションログファイルが必要なのは、より多くのトランザクションログスペースが必要で、現在の単一のトランザクションログが大きくならない（ボリューム不足など）緊急時の場合のみです。この場合は、平文で説明されますが、複数のトランザクションログがあるとvery一時的な状態になります。そのような状況では、できるだけ早くそれをクリーンアップして、単一のトランザクションログに戻すことをお勧めします。