私は最近、サイズが20〜25 GBのSQLサーバーに2つのデータベースがある新しい会社に移動しました。データベースのログファイルを圧縮できません。
データベースのトランザクションログバックアップは、午前6時から午後7時まで30分ごとに実行されるように設定されています。
サイズはそれぞれ10 Gbおよび2 Gbです。
昨夜8-9頃に縮小しようとしましたが、PM昨夜はできませんでした。
Log_reuse_wait列には、log_backupで待機していると記載されています。
助けにならないログのバックアップをいくつか取得してみました。
DBCC OPENTRANを実行しましたが、開いているトランザクションがありません。
また、今朝、Tlogバックアップが午前6:00から現在(10:30)まで開始された後も、log_reuse_wait列にLOG_BACKUPが表示されます。
そしてOPEN TRANもありません。
これについて調べたところ、Paul Randalからこの記事を見つけました: http://www.sqlskills.com/blogs/paul/why-is-log_reuse_wait_desc-saying-log_backup-after-doing- a-log-backup /
DBが小さく、tlogファイルのすべてのコンテンツが同じである場合、VLFは切り捨てられなかったと述べています。
データベースに300〜400個のVLFがあります。
そのため、ここでも意味がありません。
毎朝午前6時のtlogが他のtlogよりも少し大きいことに気付いたことが1つあります。
それで、24時間体制でtlogを実行するようにリードDBAに確認することを考えています。
それ以外に、なぜこれが起こっているのか、また何か不足しているのかを確認したいと思います。
以下のコマンドで縮小しようとしました:
Use DB1
go
DBCC SHRINKFILE(2,10)
GO
注:0n 2012互換性を実行するSQL 2012インスタンスです。
プロセスが機能していない理由は、トランザクションログバックアップを使用してログの非アクティブな部分を解放するのを待っているためです。単純復旧モデルに切り替えると、この問題は回避されます。
トランザクションログを縮小して本当に再成長させる必要がある場合(たとえば、VLFの数を減らすため)、これはプロセスです。
1)単純復旧モデルに切り替える
2)CHECKPOINTとDBCC DROPCLEANBUFFERSを実行します(念のため)
3)ログファイルを圧縮する
4)完全復旧モデルに切り替えます
5)ログを適切な増分で拡張します(私は4000MBの増分を使用します)
6)I/Oサブシステムが処理できる値に自動拡張を設定します
7)完全バックアップまたは差分バックアップを実行して、ログバックアップチェーンを再開します。
トランザクションログのバックアップを一晩実行し続ける必要があるだけの状況に聞こえます。日中のように30分ごとではないかもしれませんが、トランザクションログのバックアップがない11時間のウィンドウが問題である可能性があります。
実際のserアクティビティが少ない場合でも、他のアクティビティが夜間に発生すると、トランザクションログが増大します。例:データベースのメンテナンス(インデックスの再作成など)、ETLプロセス(新しいデータのインポート、データのアーカイブ/削除、他のシステムからの更新、夜間の計算など)。
個人的には、20〜25 GBのデータベースの場合、アクティビティのレベルに応じて、トランザクションログを1〜10 GBの範囲で完全に快適に使用できます。 2GBがこれほど大きいと思う理由がわかりません。それはworking SQLエンジンのためのスペースであり、無駄ではありません。
大きい方を削減したい場合は、完全復旧モードでログを圧縮することをお勧めします。
SHRINKFILE (name='mylog',size=4000)
を実行します。SHRINKFILE
を繰り返します。非常に長時間実行中のオープントランザクションを持つデータベースを除いて、ファイルを縮小することができました。
復旧モデルをシンプルに変更した後でも、ログファイルを圧縮したいデータベースによってオブジェクト自体にロックがあったかどうかを確認した後でも、復旧モデルをシンプルに変更した後でも、ログファイルを縮小できないという同様の問題が発生します。ロックを解除して、ログファイルを圧縮できました。