web-dev-qa-db-ja.com

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

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

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

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

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

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

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

[〜＃〜]更新[〜＃〜]

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

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

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

sql-serversql-server-2012backuprestore
8
Kraig Walker

そのデータベースのトランザクションログには、最後のトランザクションログバックアップ以降、または前回のシンプルリカバリモードからの切り替え時以降のすべてのトランザクションが含まれます。次のコマンドを実行して、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に推奨します。

4
Pixelated

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

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

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

3
user541852587