コピーのみによるトランザクションログの切り捨て
1日1回のみ[コピーのみ]オプションをオンにして完全バックアップを使用するように設定されたデータベースバックアップジョブがあります。私が読んだことから、可用性グループに接続されているデータベースをバックアップする唯一の方法であるため、コピーのみがオンになっています。同じAGで同じオプションを使用して、20分ごとにログバックアップを実行しています。これらのバックアップの実行後にトランザクションログを切り捨てるベストプラクティスは何ですか。フルバックアップは、ログバックアップと同じようにコピーを使用するため、切り捨てられません。彼らは制御不能に成長しています。 DBCC SHRINKFILEを使用できることはわかっていますが、DBCC SHRINKFILEについて読むほど、危険なようです。他の方法やベストプラクティスはありますか？
任意のアドバイスをいただければ幸いです。
私は、ドキュメントがこれについてあまり明確ではないことを認める最初の人になります。彼らはバックアップをセカンダリにオフロードする必要があると述べていますが、ほとんどのステートメントは一般的な意味で行われていますが、特にログバックアップ（およびcopy_onlyバックアップ（必要な場合）。
プライマリIMHOでフルバックアップを実行する必要がある場合があります。 copy_only制限は完全バックアップに関するものであり、ログバックアップではなく、セカンダリAFAIKにのみ適用されます。
現在のトランザクションログは、技術的にバックアップされていないアクティビティでいっぱいなので、shrinkfileを現在のトランザクションログに対して使用することはできません。完全に取ると（非copy_only）プライマリでバックアップし、1つのログバックアップを実行すると、ログファイルを手動で圧縮できます。現在、データベースがフルに設定されているため、ログバックアップは機能していますが、（おそらく）プライマリで適切なフルバックアップを実行したことがないため、ログのバックアップは増え続けています。
これは1回限りの操作であり、小さくしすぎないでください。プライマリを定期的にバックアップするように設定する必要があり、フルバックアップまたはログバックアップの間に発生する最大のアクティビティセットに対応する必要があります。ファイルが再び大きくなるようにファイルを縮小する方法については、何度も繰り返し説明しませんが、無駄な練習であり、パフォーマンスの低下を保証しますが、可能です。 :-)
いくつかの理由でセカンダリレプリカのバックアップを行うのはあまり好きではありません。つまり、すべてを1つにまとめる必要があり、ライセンスの影響があります。バックアップは通常、大きなオーバーヘッドではないため、ほとんどの場合、プライマリレプリカでバックアップを実行することをお勧めします。
Aaronが指摘するように、tログを適切にフラッシュするまで、tログのファイルを小さくするなどのことはできません。 COPY_ONLYは単なる完全バックアップであり、t-logが制御不能になっていないことを確認する必要があります。これは、一般的にプライマリレプリカでバックアップを作成することを好むもう1つの理由です。
BACKUP LOGを使用してCOPY_ONLYを実行できることはわかっていますが、上記の理由から、私は大ファンではありません。
MSには2つのブログ記事があります。