SQL Server 2012の_AlwaysOn Availability Group
_機能を使用しています。セカンダリデータベースでは、定期的なフルデータベースバックアップとトランザクションログバックアップが毎日行われます。
私は読んだ ここ プライマリレプリカまたはセカンダリレプリカのいずれかでトランザクションログバックアップを実行すると、両方のレプリカのトランザクションログが再利用可能としてマークされます。とにかく、トランザクションログのバックアップサイズは大きく、縮小ファイルを使用して減らすことができます。
データベースをローカルに復元し、縮小操作を実行しました。ログファイルのサイズは160 MBに減少しました。
私の質問は、トランザクションログファイル(プライマリ、セカンダリ、またはその両方)に対してどのデータベースで圧縮操作を実行する必要があるかです。
過去数年間は、ログファイルのバックアップが作成されていないため、非常に巨大になると思います。 DBCC SQLPERF (LOGSPACE)
を実行すると、ファイルの_0.06%
_のみが使用されていることがわかります。このような巨大なログファイルを保持する意味はありません。 _[sys].[database_files]
_で、その_max_size
_が_-1
_にgrowth
から_65536
_に設定されていることを確認します。とにかく、将来の成長を防ぐために、たとえば5%に縮小できます。私はそうすることは悪い考えではないといういくつかの確認を見つけようとしています。
実際、(データベースとログファイルの)バックアップはセカンダリデータベースでのみ実行されるため、それらのファイルで圧縮ファイルを実行する方が簡単ですが、プライマリログファイルのサイズも縮小されますか?
AGでは、書き込みはプライマリでのみ発生します。縮小操作は書き込みです。したがって、プライマリで縮小する必要があります。縮小が期待したほど縮小しない場合があることに注意してください。復元されたDBでのテストでは、おそらく単純な復旧モデルが利用されていました。詳細については、 SQL Serverログを圧縮する方法 を参照してください。
160MBに縮小しないでください。決定理由ログが121Gbに増加したため、繰り返されません(疑わしい点があります。可能であれば確認するとよいでしょう)。運用上のニーズに適したサイズにログのサイズを設定します。ログの増大は深刻な問題であり、ファイルの即時初期化を使用できず、ログが増大して0で初期化されている間、すべてのデータベースアクティビティがフリーズします。それが発生すると、ユーザーとアプリはそれを嫌います。 If影響を理解し、ユーザーに問題がない場合は、onceを小さく(ただし、160MBはおそらく小さすぎます)して、安定するまで大きくすることができます。
あなたが試すことができます:
このスクリプトを試してください:
-ジョブステップまたはスクリプト内に現在のデータベースを設定します -プライマリでのみ実行を確認します if(SELECT role FROM sys.dm_hadr_availability_replica_states AS a JOIN sys.availability_replicas AS b ON b.replica_id = a.replica_id WHERE b.replica_server_name = @@ SERVERNAME)= 1 BEGIN - -[test_db]を使用-MS SQL 2014では機能しません。この行をコメントにして、ジョブステップまたはスクリプト内に現在のデータベースを設定してください -1)Bakup Trn バックアップログ[test_db] TO DISK = N'D:\ MSSQL\Backup\test_db.trn 'WITH NOFORMAT、INIT、NAME = N' Trn Backup '、SKIP、NOREWIND、NOUNLOAD、COMPRESSION、STATS = 10 -2)使用済みページを移動 DBCC SHRINKFILE(N'test_db_log '、3000、NOTRUNCATE) -3)SHRINKFILEログ DBCC SHRINKFILE(N'test_db_log'、3000) END