ほとんどの場合、ユーザーはニュースを読むためにデータベースにアクセスします。トランザクションで実行されるクエリの数はほとんどありません。データベース ヒットの 95% は読み取り専用です。
データベース ログ ファイルのサイズが 1 日あたり 1 GB 増えています。データベースを圧縮しても、ログ ファイルのサイズは減少しません。ログ ファイルのサイズがますます大きくなる理由は何ですか? どうすればこれを制御できますか? 私の知識によると、テーブルからデータを読み取ってもログファイルは増加しません。
ログファイルの増大に対処する方法について何か提案はありますか? どうすれば扱いやすい、または妥当なサイズに保つことができますか? これは何らかの形でパフォーマンスに影響しますか?
考慮すべきことがいくつかあります。どのタイプのバックアップを実行し、どのタイプのバックアップが必要か。この質問に対する答えが得られる場合は、リカバリモードをシンプルに切り替えるか、完全のままにすることができますが、その後、毎日（またはログサイズに満足できるものなら何でも）増分バックアップを作成する必要があります。
データベースのログを単純に設定します（ただし、データベースの完全バックアップを実行する場合のみ）。
これは機能し、バックアップスケジュールが毎日フルバックアップである場合に最適です。このようなシナリオでは、ログはトリミングされず、急上昇するためです（あなたの場合と同じように）。
Grandfather＆Father＆Sonバックアップ手法を使用する場合、これは、月次完全バックアップ、週次完全バックアップ、そして毎日の増分バックアップを意味します。そのためには、完全復旧モードが必要です。1日あたり1GBのログがまだ多すぎる場合は、1時間または15分ごとの増分バックアップを有効にできます。これにより、ログがますます大きくなる問題が修正されるはずです。
フルバックアップを毎日実行する場合は、単純なリカバリモードに切り替えることができ、データを危険にさらすことなく問題がないはずです（1日分のデータが失われる可能性がある場合）。インクリメンタルを使用する場合は、リカバリモードをフルのままにします。
完全バックアップは役に立ちません。トランザクションログを空にするには、トランザクションログ（および通常のデータベースの完全バックアップと差分バックアップ）を定期的にバックアップする必要があります。ログをバックアップしておらず、単純リカバリモードでない場合は、データベースが設定されてから、トランザクションログにすべてのトランザクションが含まれます。1日のギグで成長するのに十分なアクションがある場合は、一度に多くのレコードに影響を与える大量のインポートまたは更新が発生する可能性もあります。トランザクションが個別に記録されない単純なリカバリモードである必要がある可能性があります。ただし、インポートとユーザーからのデータが混在している場合は、これを行わないでください。その場合、サイズを管理しやすく、ある時点に保つことができるように、トランザクションログを頻繁にバックアップする必要があります。トランザクションログは15分ごとにバックアップされます。
BOLでのトランザクションログのバックアップについて読んで、現在の混乱を修正する方法を確認してください。次に、バックアップを正しく設定して実行します。修正を試みる前に、これらをよく読んで理解する必要があります。今のところ、サーバーに障害が発生し、データベースを回復しなければならなかった場合、おそらくあなたは傷ついた世界にいるでしょう。トランザクションログのバックアップは、障害から適切に回復できるようにするために重要です。
データベースを頻繁にバックアップしますか? SQL Server がログ ファイルの圧縮を検討するためには、フル バックアップまたはトランザクション ログ バックアップを実行する必要があります。