SQL Server 2008でバックアップからインデックスを除外する方法
主にテーブルのインデックスの量が原因で、夜間のフル（および定期的な差分）バックアップが非常に大きくなっています。バックアップサイズの約半分はインデックスで構成されます。
バックアップにはSimple復旧モデルを使用しています。
FileGroupsまたは他のファイル分割方法を使用して、バックアップからexcludeインデックスを作成する方法はありますか？
これをフルテキストカタログにも拡張できるといいですね。
完全復旧モードに切り替えると、ファイルグループを使用してこれを実行できますが、これは実際には非常に不便です。データをプライマリファイルグループに残し、インデックスを別の（デフォルトではない、それが重要な）ファイルグループに配置します。
次に、バックアップをずらして、プライマリのファイルグループバックアップを毎晩、トランザクションログのバックアップをX分ごとに実行します。
災害が発生した場合、プライマリファイルグループを単独で復元します。データは突然オンラインになりますが、インデックスはオンラインではありません。ただし、正常に戻るには、そのデータを新しいクリーンなデータベースにエクスポートし、そこからインデックスを追加する必要があります。すべてのファイルグループを復元せずにデータベースを完全にオンラインにすることはできません。また、「とにかく、他のファイルグループはもう必要ありません」とは言えません。
これがどのように機能するかについて詳しくは、ファイルグループの復元に関する私の ビデオチュートリアルをご覧ください。
正直なところ、他の人がここで提起する他の問題を克服したとしても、あなたは本当にこれをしたくありません。
緊急時にバックアップを復元する場合、インデックスが再構築されるのを待つ必要はありません。そうするまで、パフォーマンスに悪影響を及ぼすことになります。
インデックスなしでバックアップを復元したい状況は考えられないので、すべてのケースで同時に同時にバックアップする必要があります。
この問題の他の解決策を探す必要があるでしょう...
-アダム
これはサポートされていないようです。これから バグレポート情報 ：
これには多くの関心があったので、裏で何が起こっているのか、そしてこの機能を実装することの意味についてもう少し詳しく説明します。一部のタイプのインデックスページは、個別のアロケーションユニットに分離されていますが、他のタイプはデータページと混在しています。現在、割り当てビットマップを見てエクステントが割り当てられているかどうかを確認しているだけの場合は、各割り当てユニットに何が格納されているかを調べて解釈する必要があります。さらに、データをコピーするデータファイルの線形スキャンだけを実行することはできなくなり、ファイル内をスキップすることになります。このデータ構造の解釈はすべて、バックアップの速度を大幅に低下させます。バックアップの穴を考慮して修正する必要のある構造がたくさんあるので、復元はさらに興味深いものになります。それ以外の場合は、バックアップされていないページを指す割り当てマップがあり、ガベージなどが含まれます。したがって、これを実装すると、保存するデータが少なくなり、実行に時間がかかり、時間がかかります。より長くそれを復元します。考慮すべきもう1つの側面は、これを正しく行うために大量のエンジニアリング作業が必要になることです。これは表面的には問題ではありませんが、見たいと思う他の機能が構築されないことを意味することを考慮してください。
クレイジーなアイデアかもしれませんが、ここに行きます。
- 大量のスペースを占める非クラスター化インデックスを削除する
- バックアップをとる
- 削除したインデックスを再作成します
もちろん、実際にこれを実行できるのは、データベースで1日のダウンタイムが許容される場合のみです。
また、SQL Serverはこれらをヒープに変換するのに多くの時間を浪費するため、クラスター化インデックスを削除しないでください。
その余分なディスク容量を購入することは、もっと簡単な解決策のように思えますか？
圧縮バックアップ の実行を検討しましたか？これは2008年の新機能であり、オプションになる可能性があります。