SQL Serverトランザクションログの圧縮

私は現在、制御不能になったSQL Serverトランザクションログを処理する必要があります。免責事項：私はdbaではなく、これは私の専門分野ではないので、ご容赦ください。

現在、500 MBのデータベース用に115 GBのトランザクションログファイルがあり、この状態になるには（明らかに）しばらく管理が不十分でした。

最優先事項は、実行する前に、このファイルによって占有されているディスク上のスペースを再利用することです。ドライブのサイズを増やすことは一時的であってもオプションではないと言われています。過去の成長に基づいて、我々はすぐに行動する必要があります。

私が理解しているように、最良のアプローチは、dbを完全復旧モードに保ちながら、ログファイルの定期的なバックアップをとり、一定期間監視し、初期サイズと増分を適切に調整することです。大丈夫。

午前0時に定期的にフルデータベースバックアップを実行しているときに、データベースを一時的にシンプルリカバリモードにして（これらのバックアップの1つが実行された後）、ログファイルを圧縮して（事実上すべての）領域を解放し、次に、上記のバックアップ戦略でそれを完全復旧に戻しますか？

私の考えでは、この時期に何かが起こった場合、ログを使用せずに完全なバックアップを復元することができます。

更新

いくつかの回答とコメントへの返信におけるいくつかの追加詳細：

• データベースを完全復旧モードのままにしておくために、ポイントインタイムリストアを実行する機能を保持したいと思います。

• t-logファイルが非常に大きくなった理由は、バックアップされたことがないためです。log_reuse_wait_descが「LOG_BACKUP」を返すことを確認。

そのデータベースのトランザクションログには、最後のトランザクションログバックアップ以降、または前回のシンプルリカバリモードからの切り替え以降のすべてのトランザクションが含まれます。次のコマンドを実行して、SQL Serverがログを切り捨てられない理由と、その後ログが増大する理由についての明確な回答を取得します。

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

ポイントインタイムリカバリが必要な場合は、DBを完全復旧モデルのままにして、ログバックアップを頻繁に実行します。各ログバックアップには、最後のログバックアップ以降のすべてのトランザクションが含まれます。ログのバックアッププロセスは、ログをクリアし、再利用するスペースをマークする役割も果たします。つまり、DBで行われた次のトランザクションは、切り捨てられたログの先頭に循環的に書き込まれます。このログのバックアップと再利用が、ログファイルの増大を防ぎます。

ポイント・イン・タイム・リカバリーに関心がなく、データベースの管理を単純化したい場合。次に、データベースを単純復旧モデルに設定し、t-logバックアップを取得しません。SQL Serverは、各トランザクションがコミットされると、トランザクションログを自動的に切り捨てます。トランザクションがログにコミットされると、次のトランザクションなどによってレコードが上書きされることを意味します。

どちらの方法でも、これら2つの決定のいずれかを行ったら、ログファイルをより適切なサイズに圧縮できます。理想的には、大きくならないように十分に大きくしたいが、再度縮小する必要があるほど大きくないようにする必要があります。また、ログのアクティブな部分を縮小できないことに注意してください。

https://ola.hallengren.com/をダウンロードしてデプロイしますデータベース管理ソリューションを、バックアップ、インデックスの断片化、統計、CHECKDBをカバーします。

オブジェクトエクスプローラー>レポート>標準レポート> 'ディスク使用量'でDBを右クリックして返される 'ディスク使用量'レポートは、tログの空き領域を返すのに便利です。

また、DRの観点からログチェーンを完全な状態に保つことが非常に重要である理由、および完全から単純への切り替えによってチェーンが切断され、データが失われる可能性があることをGoogleに推奨します。

午前0時に定期的にフルデータベースバックアップを実行しているときに、データベースを一時的にシンプルリカバリモードにして（これらのバックアップの1つが実行された後）、ログファイルを圧縮して（事実上すべての）領域を解放し、次に、上記のバックアップ戦略でそれを完全復旧に戻しますか？

はい、深夜の負荷など、トランザクションを妨害しない場合は安全です。一般に、データベースを完全復旧モードにする必要がある場合は、定期的なT-Logバックアップが必要です。これにより、直面している問題が軽減されます。「一般的に」と書いているのは、場合によっては、なぜデータベースをフルに設定したのか、その理由が分からないことがあるからです。これはそうではないと仮定しましょう。

ただし、ログがデータベースサイズに対してこのサイズである理由を検討する必要がある場合があります。ログが116GBの500MBのデータベースは、1回限りのイベントでは非常に不均衡に見えます。データベースで何が起こっているのかを監視して、そもそもそのサイズに到達した方法を確認することをお勧めします。