バックアップする必要のない1TB近くのFILESTREAM
データを含むデータベースがあります(データが削除された場合、数時間で自動的に再作成されるため、重要ではありません)。ほとんどのデータは数日ごとに変更されるため、差分バックアップを行ってもサイズを小さくすることはできません。
リカバリモードをFull
に設定し、FILEGROUP
用に別のFILESTREAM
を作成して、「プライマリ」のみのバックアップを取得することで、必要な方法でバックアップを実行しましたFILEGROUP
。これが原因で発生した問題は、ログファイル(これもバックアップされます)にFILESTREAM
データが含まれているため、不必要に大きくなることです。
SIMPLE
リカバリモードは、特定のFILEGROUP
sのバックアップを実行する私の能力を奪うため、それもオプションではないと思います。
私の考えは、FILESTREAM
データを別のデータベースに移動することですが、今は参照整合性が失われており、他の多くの問題も確実に継承しています。
Simple
リカバリモードで部分バックアップを作成する方法はありますか(FILESTREAM
テーブルを読み取り専用に設定せずに)?そうでない場合、私の問題に対する他の健全な解決策はありますか?
これが原因で発生した問題は、ログファイル(これもバックアップされます)に、FILESTREAMデータが含まれているために不必要に大きくなることです。
ログファイル自体が大きすぎるのか、ログファイルのバックアップが大きくなりすぎるのかはわかりません。
前者の場合、どのくらいの頻度でログをバックアップしましたか?アプリケーションの設計によっては、より頻繁にバックアップすることでサイズを削減できる場合があります(5分ごとにそれほど頻繁ではありません)。しかし、すでにそれを行っていて、それがまだ膨らんでいる場合は、おそらく運が悪いでしょう。大きなログファイルが再び問題になるのはなぜですか?
後者の場合-単純な復旧モデルを続行してよかったように思えますが、バックアップのサイズを小さくすると、特定の時点での復元ができなくなります。その場合は、フルモードのままにして、ログバックアップを破棄してください。
回復モードSIMPLEに設定されたデータベースの解決策は、読み取り専用のファイルグループにFILESTREAMデータを持ち(これは理想的なオプションではありません)、次のようなDIFFERENTIALで読み取り/書き込みファイルグループのみをバックアップします。
BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;
読み取り/書き込みファイルグループで変更されたデータを取得します。 FILESTREAMデータを取得せずに、部分的なバックアップを管理しやすい状態に保つことができることは、箱から出してすぐに最も簡単です。ただし、前述のデータの読み込みプロセスでは、ファイルグループを読み取り/書き込み可能に変更し、追加のデータを読み込み、再度読み取り専用に設定する必要があります。確かに理想的ではありません。
これをオプションとして提供するのは不愉快ですが、FILESTREAMデータを独自のデータベースに分離することを選択した場合、 triggers を使用して、別のdbのテーブル間のRIを維持できます。
トリガー->備考->制限:
トリガーは現在のデータベースでのみ作成されます。ただし、トリガーは現在のデータベース外のオブジェクトを参照できます。
欲求不満で頭の毛皮の房を引き抜いた後、パフォーマンスの問題と頭皮の一部が無毛になることを期待しますが、理論的にはあなたがこれを行うことができました。このアプローチはどのレベルでもお勧めしません。代わりに、tlogバックアップの頻度を増やすか、一括ログ復旧モデル節約できるスペースを確認してください。ただし、これは可能な解決策です。実際には、このデータを分離してフランケンシュタインデータベースの設計を処理することの利点を比較検討する必要がありますが、これはオプションです。
...シャワーを浴びに行かなければならない...
この質問はすでに回答済みですが、他の人を助ける別の解決策があります。最近、Brent Ozarの blog から、ログバックアップをすぐに破棄するオプションがあることがわかりました。
BACKUP LOG MyDb TO DISK='NUL:'
したがって、データベースをFull
リカバリモードのままにして、ファイルグループのバックアップを実行できます。トランザクションログが大きくなりすぎたら、backup logコマンドを発行するだけで完了です。