バックグラウンド：
最近、50以上のSQL Serverと450以上のデータベースを継承しました。毎晩のバックアップは約8 TBであり、言うまでもなく、必要以上のディスク領域を使用しています。すべてのデータベースが完全復旧に設定されており、トランザクションログがバックアップされたことがない。私はすべてのSQL Serverを調べ、夜間のバックアップのみが必要で、1日のデータ損失が許容される優先度の低いサーバーを特定しました。
質問：
多くの優先度の低いデータベースをからSIMPLEリカバリモードに切り替えていFULLます。既存のトランザクションログは切り捨てられますか（チェックポイントが作成されるとき）？既存のトランザクションログの一部は50〜100 GBです。前進するためにそれらを縮小する必要があるものを決定する上で最良のアプローチは何ですか？そんなに大きくしたくないのは明らかです。または、時間の経過とともに自然に縮小しますか（そうなるとは思いません）？
回答:
切り替える前FULLにSIMPLE復旧モデル、あなたが失うわけにはいかことができますどのくらいのデータ自問してみてください。災害発生時にデータベースの最後のバックアップを復元してSIMPLEも問題ないデータベースの場合、問題はありません。そうでない場合は、そのままにしFULLます。
LDFファイルを可能な限り小さいサイズに縮小するには、Kimberly Trippが提供する手順に従ってください。トランザクションログのスループットを向上させるための8つの手順
データベースのアクティビティが少ない時間を待ちます
SSMSで実行：
DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)トランザクションログファイルのサイズを変更します。
ALTER DATABASE db_name
MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)多くのデータベースを完全復旧モードから単純復旧モードに切り替えています（T-Logとポイントインタイム復旧は必要ありません）。既存のトランザクションログは切り捨てられますか（チェックポイントが作成されるとき）？
単純な復旧モデルでは、データベースエンジンが自動チェックポイントを発行し、その頻度は復旧間隔（高度なサーバー構成設定）によって、またはログが70％いっぱいになった場合に決定されます。
ログの切り捨てを遅らせるトランザクションが長時間実行されていない限り、自動チェックポイントはTログの未使用部分を切り捨てます。
既存のトランザクションログの一部は50〜100 GBです。これを進めるために何に縮小する必要があるかを判断するための最良の方法は何ですか。そんなに大きくしたくないのは明らかです。
50〜100GBのTログを持つデータベースのデータベース復旧モデルをFULLに設定している場合は、Tログのバックアップを頻繁に開始する必要があります。完全復旧モデルでは、ログバックアップチェーンが確立されると、自動チェックポイントでもログが切り捨てられないことに注意してください。
最後の手段として、ログファイルを切り捨て、すぐに完全バックアップを作成し、Tログバックアップの作成を開始して、災害が発生した場合のポイントインタイムリカバリを実行できます。
または、時間の経過とともに自然に縮小しますか？
@TomTomが指摘したように、これは手動操作です。
読んで：
質問の多くは私たちが答えることができません。文字列の長さはどれくらいですか？
既存のトランザクションログの一部は50〜100 GBです。これを進めるために何に縮小する必要があるかを判断するための最良の方法は何ですか。
彼らがする必要がある限り。縮小しないことをお勧めします。ログをトゥルナケートし、1週間後に戻って、使用されているスペースの量を確認してください。しかし、あなたはこれに答えなければなりません。
毎晩のバックアップは約8 TBであり、言うまでもなく、必要以上のディスク領域を使用しています。
では、なぜそれらを単純なものに変えるのでしょうか？つまり、真剣に。
すべてのデータベースが完全復旧に設定されており、トランザクションログがバックアップされたことがない。
小さなロジックは、IGFで一度切り捨てることを通知します。それなら、とにかくバックアップに使用するスペースがかなり少なくなるでしょう。その結果、それらを完全復旧モードに保つことができる場合があります。まず試してみてください。回復が少ないなどの場合、ログバックアップは将来的にLOTが小さくなります。
私はすべてのSQLサーバーを調べましたが、夜間のバックアップのみが必要であり、災害が発生した場合でも1日分のデータ損失が問題にならない優先度の低いサーバーを特定しました（Faxデータベースなど）。
はい。それはあなたが法廷に行き、重要な法的文書がないためにあなたのお尻を渡されるまでです。FAXログがビジネス関連情報として何年もの間保持する必要があるものの一部である可能性があることを知っていますか？それは私の管轄（10年）でも同じです。あなたがU株の会社であれば、同様の驚き（SOX）があるかもしれません。そうしないと、ファックスを受け取っていないことを証明したい場合、法廷で非常に悪いことになります。または送信しました。これが毎月発生したかどうかは誰も気にせず、より最近のログがある-あなたは法律の要件を満たしていない。重要でないビジネスがあなたの発砲の理由かもしれないので、これは非常に高い誰かによってサインオフされていることを確認してください。
または、時間の経過とともに自然に縮小しますか？
いいえ。彼らはそれをすべきではありません。ログのサイズ変更は、少量のデータベースを除き、手動操作です。