SQL Server FILESTREAMを使用する場合の(部分的な)バックアップを小さく保つ


12

FILESTREAMバックアップが不要な1TB近くのデータを含むデータベースがあります(データが削除された場合、数時間で自動的に再作成されるため、重要ではありません)。ほとんどのデータは数日ごとに変更されるため、差分バックアップではサイズを抑えることはできません。

私は、私はリカバリモードを設定することにより、必要な方法で作業のバックアップを持っていたFull別の作成、FILEGROUPためにFILESTREAMのみ「プライマリ」のバックアップを取って、FILEGROUP。これが原因で発生した問題は、ログファイル(バックアップされる)にFILESTREAMデータが含まれるために不必要に大きくなることでした。

SIMPLEリカバリモードは特定FILEGROUPのsのバックアップを実行する私の能力を奪うので、私もそれがオプションになるとは思わない。

私の考えは、FILESTREAMデータを別のデータベースに移動するだけですが、今では参照整合性を失い、他の多くの問題も確実に継承しています。

Simpleリカバリモードで部分的なバックアップを作成する方法はありますか(FILESTREAMテーブルを読み取り専用に設定せずに)?そうでない場合、私の問題に対する他の健全な解決策はありますか?

回答:


3

これが引き起こした問題は、FILESTREAMデータが含まれているため、ログファイル(これもバックアップされる)が不必要に大きくなることです。

ログファイル自体が大きすぎるのか、ログファイルのバックアップが大きすぎるのかはわかりません。

前者の場合、どのくらいの頻度でログをバックアップしましたか?アプリケーションの設計によっては、より頻繁にバックアップすることでサイズを削減できる場合があります(5分ごとはあまり頻繁ではありません)。ただし、すでにそれを行っていて、まだ膨らんでいる場合は、おそらく運が悪いでしょう。大きなログファイルが再び問題になるのはなぜですか?

後者の場合-単純な復旧モデルを継続して使用することに満足しているように見えますが、バックアップを小さくすることができればポイントインタイムリストアはありません。この場合、フルモードのままにしてログバックアップを破棄します。


しばしば珍しいことではないログのバックアップを認識していませんでした!「なぜ大きなログファイルが再び問題になるのですか?」質問は実際に私にそれについて考えさせ、私には答えがありませんでした。だから、あなたに+100!
デビッドマードック

3

リカバリモードSIMPLEに設定されたデータベースの解決策は、FILESTREAMデータを読み取り専用ファイルグループ(これは理想的なオプションではありません)にして、次のようにDIFFERENTIALで読み取り/書き込みファイルグループのみをバックアップすることです。

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

読み取り/書き込みファイルグループで変更されたデータを取得します。これは、FILESTREAMデータを取得せずに部分バックアップを管理可能な状態に保つことができる、最も簡単な、すぐに使用できる方法です。ただし、前述のデータの読み込みプロセスでは、ファイルグループを読み取り/書き込みに変更し、追加のデータを読み込み、再度読み取り専用に設定する必要があります。確かに理想的ではありません。


これは、FILESTREAMが読み取り専用である場合に対処するように自動システムが設計されていれば完璧でした。残念なことに、すべてのサービスをリファクタリングするのに時間がかかりすぎていました。特に、今すぐ問題にハードドライブを投げることができるためです。今後、すべての新しいサービスはこれを念頭に置いて設計され、時間の経過とともに古いサービスを更新する計画が実施されます。(私はあなたに報奨金の半分に報いることができることを望みます!
デビッドマードック

2

これをオプションとして提供するのは汚い気がしますが、FILESTREAMデータを独自のデータベースに分離することを選択した場合、トリガーを使用して個別のdbのテーブル間のRIを維持できます

トリガー->備考->制限:
トリガーは現在のデータベースでのみ作成されます。ただし、トリガーは現在のデータベース外のオブジェクトを参照できます。

頭の毛の房を欲求不満で抜いた後、パフォーマンスの問題と頭皮の一部が無毛になると予想されますが、理論的にはこれを行うことができます。どのレベルでもこの​​アプローチはお勧めしませんが、代わりに、tlogバックアップの頻度を増やすか、または一括ログ復旧モデルに切り替えることを強くお勧めします。本当に、このデータを分離してフランケンシュタインのデータベース設計に対処することの利点を比較検討する必要がありますが、これはオプションです。

...今シャワーを浴びに行かなければならない...


1

この質問にはすでに答えられていますが、他の人を助けるかもしれない別の解決策があります。最近、ブレント・オザーのブログから学んだ、ログバックアップをすぐに破棄するオプションがあることた。

BACKUP LOG MyDb TO DISK='NUL:'

そのため、データベースをFull回復モードのままにして、ファイルグループのバックアップを実行できます。トランザクションログが大きくなりすぎたら、バックアップログコマンドを発行するだけで完了です。


予期しないアクティビティによってログファイルのサイズが不当に大きくならないように、ログバックアップをスケジュールされたジョブとして実行することをお勧めします。
RDFozz
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.