アーカイブ目的でデータベースをデフラグ/圧縮する最良の方法

電子メールのアーカイブに使用されるSQL Serverインスタンスがあります（サードパーティのアーカイブパッケージによる）。多くの場合、ソフトウェアは新しい空のデータベースにロールオーバーされます。これまでは四半期ごとに行ってきましたが、今は毎月行う予定です。アーカイブされるデータの量は1か月あたり約15〜20 GBで、データの大部分は少数のテーブル（通常は2〜4）にのみ存在します。

新しいデータベースにロールオーバーすると、古いデータベースは完全に読み取り専用で使用されます。私がしたいことは、すべてのテーブル/インデックスが隣接しており、非常に高いFILL FACTORを持ち、データファイルの最後に多くの空スペースがない、タイトなデータファイルに最適化することです。また、このサーバーではStandard Editionを使用していますが、暗黙の制限がすべてあります（それ以外の場合は、既にデータ圧縮を使用しています）。

私が考えることができるいくつかの可能性：

1. REBUILD / REORGANIZEインデックス、DBCC SHRINKFILE（わかりました、これは賢明なオプションではありません。DBCCSHRINKFILEは触れたものから小便を断片化するためですが、完全を期すために含めています。）
2. 自動統計をオフにして新しいデータベースを作成します。ソースデータベースからすべてのテーブルをスクリプト化して再作成します。bcpを使用して、データをクラスターキーの順序で新しいデータベースにエクスポート/インポートします。すべてのインデックスをスクリプト化して再作成します。フルスキャンですべての統計を再計算します。
3. 自動統計をオフにして新しいデータベースを作成します。ソースデータベースからすべてのテーブルをスクリプト化して再作成します。SSISまたはT-SQLを使用して、新しいデータベースにデータを転送します。すべてのインデックスをスクリプト化して再作成します。フルスキャンですべての統計を再計算します。

いずれの場合も、最後の手順はデータベースを読み取り専用モードに設定することです。

これを行うには他にどのような良い/良いオプションがありますか？私の懸念は、高いFILL FACTORを維持するような方法で、論理的に連続した方法でデータを移動することです。

編集：

データの約75％がイメージ（LOB）列に格納されているようです。

ファイルの物理的な断片化を解消するには、ドロップが存在するクラスター化インデックスを新しいファイルグループに移動します。それらはROになるため、更新によって引き起こされる挿入、ページ分割に必要なスペースがないため、それらすべてを100％フィルファクターにします。

これにより、エンタープライズに行くことを決定した場合に、段階的な復元を実行してデータベースを非常に迅速にオンラインにすることもできます。Enterpriseでは、列ストアインデックスに加えて、この読み取り専用データのクエリ時間を大幅に削減できます。これは、巨大なフィレットです。

必要に応じて、ファイルの最後のスペースを削除するために、断片化の深刻な問題なしに読み取り専用に切り替える前に、shrinkfileオプションを1回使用できます。

余談ですが、LOBSに最新のデータ型を使用していることを確認するだけです。つまり、ntextまたはtextの代わりにnvarchar（max）またはvarchar（max）、imageの代わりにvarbinary（max）？

構造化されていないデータを格納するのにも画像データ型を使用していたサードパーティツールで同様の問題に直面し、filestreamを使用するように列を変換することで解決しました。アプリが期待どおりに機能することを確認するためにいくつかのテストを行う必要がありますが、これにより、効率的な方法でデータをアーカイブデータベースに移動する独自のアーカイブプロセスを作成できるようになります。