1
設定データを格納しているデータベースがあります。アプリケーションが実行されると、基本的に多くの計算が行われ、データがファイルに書き込まれます。通常のインストールとは異なり、実際にはトランザクションログは必要ありません。ここで意味するのは、データベースをバックアップしてトランザクションログを適用せずにデータベースを使用して最新の状態にすることができるということです。データ復旧が重要でない場合のトランザクションログバックアップ
トランザクションログはそれほど重要ではないので、最適なバックアップ戦略は何ですか。現在のところ、トランザクションログは膨大です（データベースが約50 MBの場合は10 GBですが、これは数か月以上です）。
データベースの初期バックアップを実行して、トランザクションログを数日以内にバックアップして、現在のログを上書きできますか？または、トランザクションログを一括して削除して、新しいトランザクションログを開始することはできますか？
JD。
ありがとうございます。簡単に要約すると、シンプルに行く方法です。ただし、データベースにデータを書き込むことはできますが、このデータはバックアップされたデータベースから計算できます（リンクには、データが変更されていないデータベースの場合はSimpleが良いと記載されています）。 私は、構成データを変更したときに完全なデータベースバックアップが必要だと思っています。これを自動化して、トランザクションログを縮小するような何かをする必要がありますか？ JD。 –
もう少し読んだだけです。 SQL Serverインスタンスの回復間隔は0分です。私が理解しているところでは、自動チェックポイントが実行されます。つまり、トランザクションログが切り詰められ（再利用のためにスペースが解放されます）。これは正しいです？もしそうなら、私は実際にはスクリプトを実行する必要はありません（完全なデータベースバックアップを持っているだけです）。 –
@JD：シンプルリカバリモデルを使用すると、必要に応じて特定の時点にデータベースをリカバリすることはできません（トランザクションログのバックアップが必要なため）。提供されたポイント・イン・タイム・リカバリは必須ではなく、おそらくデータは比較的静的であるか、別の手段、例えば、あなたは完全なデータベースバックアップを持っているか、データフィードを再インポートすることからデータを回復することができます。その後、シンプルリカバリモデルがあなたのニーズに合っています。シンプル・リカバリー・モデルが自動的にトランザクション・ログ・ファイルの切り捨てを管理する点も正しいです。 –