[IT168 Server Academy] トランザクション ログは非常に重要ですが、データベース構造の一部として無視されがちです。トランザクション ログはデータベース内のスキーマほどアクティブではないため、トランザクション ログに注目する人はほとんどいません。
トランザクション ログはデータベースの変更の記録であり、データベースに対するあらゆる操作を記録し、記録結果を別のファイルに保存できます。すべてのトランザクション プロセスについて、トランザクション ログには非常に包括的な記録があり、これらの記録に基づいてデータ ファイルをトランザクション前の状態に復元できます。トランザクション アクションの開始時から、トランザクション ログは記録状態になります。トランザクション中のデータベースに対する操作はすべて、ユーザーが送信または戻るをクリックするまで記録は完了しません。各データベースには、少なくとも 1 つのトランザクション ログと 1 つのデータ ファイルがあります。
パフォーマンス上の理由から、SQL Server はユーザーの変更をキャッシュに保存します。これらの変更はデータ ファイルではなく、トランザクション ログに直ちに書き込まれます。トランザクション ログは、マーキング ポイントを使用して、トランザクションがキャッシュからデータ ファイルにデータを書き込んだかどうかを判断します。 SQL Server が再起動すると、ログ内の最新のマーク ポイントがチェックされ、このマーク ポイント以降のトランザクション レコードが消去されます。これらのトランザクション レコードは実際にキャッシュ内のデータをデータ ファイルに書き込むわけではないためです。これにより、中断されたトランザクションによるデータ ファイルの変更が防止されます。
トランザクション ログを維持する
多くの人がトランザクション ログを忘れることが多いため、システムに問題が発生する可能性もあります。システムの実行が続くと、記録されるログ レコードの数が増え、ログ ファイルのサイズも大きくなり、最終的には使用可能なディスク領域が不足します。日々の作業でログを頻繁にクリーンアップしないと、最終的にログ ファイルがパーティション内の使用可能な領域をすべて占有してしまいます。ログのデフォルト構成は無制限の容量です。この構成で作業すると、ログは拡張し続け、最終的には使用可能なスペースをすべて占有します。どちらの状況でも、データベースの動作が停止する可能性があります。
トランザクション ログを定期的にバックアップすると、ログ ファイルが過剰なディスク領域を消費するのを効果的に防ぐことができます。バックアップ プロセスでは、不要になったログの部分が切り捨てられます。切り捨ての方法は、最初に古いレコードを非アクティブとしてマークし、次に古いログの場所に新しいログを上書きすることで、トランザクション ログのサイズが大きくなるのを防ぎます。ログの定期的なバックアップを実行できない場合は、データベースを「単純復旧モデル」に設定することをお勧めします。このモードでは、システムはマーク ポイントが記録されるたびにトランザクション ログを強制的に自動的に切り捨て、古いログを新しいログで上書きします。
切り捨てプロセスは、古いポイントをバックアップするとき、または古いポイントを非アクティブとしてマークするときに発生します。これにより、古いトランザクション レコードは上書きされますが、トランザクション ログが占有する実際のディスク領域は減少しません。ログは使用されなくなった場合でも、一定の容量を占有します。したがって、メンテナンス中はトランザクション ログも圧縮する必要があります。トランザクション ログは、非アクティブなレコードを削除することによって圧縮されるため、ログ ファイルが占有する物理ハード ドライブの容量が削減されます。
現在のデータベースのトランザクション ログ ファイルは、DBCC SHRINKDATABASE ステートメントを使用して圧縮できます。また、DBCC SHRINKFILE ステートメントを使用して、データベースで自動圧縮操作をアクティブにすることもできます。ログが圧縮されると、古いレコードが最初に非アクティブとしてマークされ、次に非アクティブとしてマークされたレコードが完全に削除されます。使用した圧縮方法によっては、結果がすぐに表示されない場合があります。理想的には、圧縮作業はシステムがそれほどビジーではない時間帯に実行する必要があります。そうしないと、データベースのパフォーマンスに影響を与える可能性があります。
データベース
トランザクション レコードのバックアップの復元を使用すると、データベースを指定した状態に復元できますが、トランザクション レコードのバックアップだけではデータベースの復元タスクを完了するのに十分ではなく、バックアップされたデータ ファイルもリカバリ作業に参加する必要があります。データベースを復元する場合、最初のステップはデータ ファイルを復元することです。データ ファイル全体が復元されるまでは、データ ファイル全体を完了状態に設定しないでください。完了状態に設定しないと、トランザクション ログが復元されません。データ ファイルの回復が完了すると、システムはトランザクション ログのバックアップを通じてデータベースをユーザーが希望する状態に復元します。データベースの最後のバックアップ後に複数のログ ファイルのバックアップがある場合、バックアップ プログラムは作成時刻に従ってそれらを順番に復元します。
ログ配布と呼ばれる別のプロセスにより、より強力なデータベース バックアップ機能を提供できます。ログ配布が構成されている場合、データベース全体を別のサーバーにコピーできます。この場合、データ回復のためにトランザクション ログも定期的にバックアップ サーバーに送信されます。これにより、サーバーがホット バックアップ状態に保たれ、データの変更に応じてサーバーが更新されます。もう 1 つのサーバーはモニター サーバーと呼ばれ、指定された間隔で送信される出荷信号を監視するために使用できます。指定された時間内に信号が受信されなかった場合、監視サーバーはこのイベントをイベント ログに記録します。このメカニズムにより、ログ配布は災害復旧計画でよく使用されます。
パフォーマンスの最適化
トランザクション ログはデータベースで重要な役割を果たし、システム全体のパフォーマンスにも一定の影響を与えます。いくつかのオプションを通じて、トランザクション ログのパフォーマンスを最適化できます。トランザクション ログは継続的なディスク書き込みプロセスであるため、このプロセス中に読み取りは発生しません。したがって、ログ ファイルを独立したディスクに配置すると、パフォーマンスの最適化に一定の役割を果たします。
もう 1 つの最適化手段は、ログ ファイルのサイズに関係します。ログ ファイルのサイズをハード ディスク容量の数パーセントを超えないように設定することも、そのサイズを決定することもできます。この値の設定が高すぎるとディスク領域が無駄になり、設定が小さすぎるとログ ファイルが継続的に拡張しようとするため、データベースのパフォーマンスが低下します。
トランザクション ログ ファイル トランザクション ログ ファイルは、データベースの更新を記録するために使用されるファイルで、拡張子は ldf です。
SQL Server 7.0 および SQL Server 2000 では、自動拡張機能が設定されている場合、トランザクション ログ ファイルは自動的に拡張されます。
一般に、トランザクション ログのサイズは、チェックポイントまたはトランザクション ログのバックアップによってトリガーされるトランザクション ログの切り捨ての間に発生するトランザクションの最大数を収容できる場合に安定します。
ただし、場合によっては、トランザクション ログが大きくなりすぎて、領域が不足したり、いっぱいになったりすることがあります。通常、トランザクション ログ ファイルが利用可能なディスク領域をいっぱいにして拡張できなくなると、次のようなエラー メッセージが表示されます。
エラー:9002、重大度:17、状態:2
データベース '%.*ls' のログ ファイルがいっぱいです。
このエラー メッセージに加えて、トランザクション ログ拡張領域の不足により、SQL Server がデータベースを SUSPECT としてマークする場合があります。この状況から回復する方法の詳細については、SQL Server オンライン ヘルプの「ディスク容量不足」のトピックを参照してください。
さらに、トランザクション ログの拡張により、次の状況が発生する可能性があります。
· 非常に大きなトランザクション ログ ファイル。
· トランザクションが失敗し、ロールバックが開始される可能性があります。
・お取引完了までに時間がかかる場合がございます。
· パフォーマンスの問題が発生する可能性があります。
・詰まりが発生する場合があります。
原因 トランザクション ログの拡張は、次の理由または状況によって発生する可能性があります。
· コミットされていないトランザクション · 非常に大規模なトランザクション · 操作: DBCC DBREINDEX および CREATE INDEX
· トランザクション ログ バックアップから復元する場合 · クライアント アプリケーションがすべての結果を処理しない · トランザクション ログの拡張が完了する前にクエリがタイムアウトになり、誤った「ログがいっぱいです」エラー メッセージが表示される · ログ ファイルが複製されていないことが原因でトランザクションが解決されないfull SQL データベースがファイルに書き込めない場合は、次の 2 つの方法が使用できます。
1 つの方法: ログをクリアします。
1.クエリ アナライザーを開き、コマンド DUMP TRANSACTION データベース名 WITH NO_LOG を入力します。
2. Enterprise Manager を再度開きます -- 圧縮するデータベースを右クリックします -- すべてのタスク -- データベースを圧縮します -- ファイルを圧縮します -- ログ ファイルを選択します -- 縮小モードで [XXM に縮小] を選択し、最小数 M に達するには、この数値を直接入力して確認します。
もう 1 つの方法には、SQL SERVER のログ ファイルがすぐにメイン データベース ファイルに書き込まれないため、適切に処理しないとデータ損失が発生するため、一定のリスクがあります。
1: ログを削除する
データベースの切り離し Enterprise Manager -> サーバー -> データベース -> 右クリック -> データベースの切り離し 2: LOG ファイルの削除 データベースの接続 Enterprise Manager -> サーバー -> データベース -> 右クリック -> データベースの接続 この方法では、新しい LOG が生成されます。 500Kを超えるだけです。
注: 最初の方法を使用することをお勧めします。
将来的には、それが大きくなるのを望まない場合。
SQL2000 で使用される場合:
データベースを右クリックし、[プロパティ] -> [オプション] -> [障害復旧] - [モデル] - [単純なモデル] を選択します。
または、SQL ステートメントを使用します。
データベースの変更 データベース名セットの回復 シンプル
さらに、上の図に示すように、データベース プロパティには、トランザクション ログの増大に関連する 2 つのオプションがあります。
チェックポイントでログを切り捨てる
(このオプションはSQL7.0で使用されます。SQL2000では簡易モデルとして障害回復モデルが選択されます)
CHECKPOINT コマンドを実行すると、トランザクション ログ ファイルのサイズが 70% を超えると、その内容が消去されます。データベースの開発時には、このオプションを常に True に設定してください。
自動縮小
データベースを定期的にチェックし、データベース ファイルまたはログ ファイルの未使用領域がそのサイズの 25% を超えると、ファイル サイズが初期サイズを超えない限り、システムは自動的にファイルを縮小します。トランザクション ログ ファイルの縮小は、バックアップ時またはチェックポイントでのログの切り捨てオプションが True に設定されている場合にのみ実行できます。
注: 通常、Li Cheng によって作成されたデータベースのプロパティはデフォルトで設定されていますが、予期せぬ状況が発生した場合は、データベースのプロパティが変更されるため、トランザクション ログが記録されないように、ログをクリアしてからデータベースの上記のプロパティを確認してください。再び満たされます。