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