ミラーリングされたデータベースのログファイルを切り捨てます
SQL Server 2008では、ミラーリングされたデータベースにログファイルが80 GBに増えましたが、これは通常ではなく、深刻な問題があります。切り捨ててログファイルのサイズを小さくしたいのですが。
いくつかの情報：
私のデータベースは完全復旧モデルです。毎日行われるデータベースとログファイルの両方のバックアップ。データベースがミラーSQL Serverにミラーリングされています。データベースにはアクティブな接続があります。たくさんの記事や意見を読みましたが、結果なしにログファイルを切り捨てるために何をすべきかを決定することはできません。
単純な復旧モデルを使用して切り捨てるべきですか？
ミラーリングを停止し、プリンシパルデータベースに対して何を実行してからミラーリングを有効にする必要がありますか？
別のディスクに新しいログファイルを作成する必要がありますか？
私はたくさんのことを読みましたが、私は本当に混乱しています。誰かが私にこの問題にどのように対処すべきかというヒントを教えてもらえますか？
単純な復旧モデルを使用して切り捨てるべきですか？
これは、ミラーリングを壊してしまう最悪の事態であり、大きなデータベースがある場合は、ミラーリングを再度作成するプロセス全体を再度実行する必要があり、退屈な作業になる可能性があります。
ミラーリングを停止し、プリンシパルデータベースに対して何を実行してからミラーリングを有効にする必要がありますか？
ミラーリングを停止することは、ここでの解決策ではなく、あなたを助けにはなりません。データベースログファイルが大きくなった理由を見つける必要があります。私の推測では、巨大なDML操作がスケジュールされているか、ETLプロセスが実行されているか、すべてのインデックスが再構築されてから統計が更新されています。
別のディスクに新しいログファイルを作成する必要がありますか？
私はあなたがこれをどこで読んだか分かりませんが、これはあなたの問題に関連する場所ではありません。ログファイルへの書き込みはシーケンシャルであり、最初のログファイルを完全に使用した後にのみ、SQL Serverは2番目に移動するため、これは再び役に立ちません。
私のデータベースは完全復旧モデルです。毎日行われるデータベースとログファイルの両方のバックアップ
ログのバックアップを取る頻度は、1日1回だけです。完全復旧モデルでは、トランザクションログバックアップのみがログを切り捨て、他のトランザクションがログファイルを使用できるようにし、ログのサイズを制限するため、最初にトランザクションログバックアップの頻度を増やすことをお勧めします。
最後に、あなたは読む必要があります トランザクションログが増え続け、スペースが不足する理由