大規模なSQL Serverデータベース設計の提案

MSSQL 2008 R2 Standardでデータベースを作成し、そこに多数のレコードを格納します。毎年1つのテーブルで2億件以上のレコードを見積もり、主にデータのUPDATEまたはDELETEをほとんど行わずにINSERTを実行しています。これは、履歴レコードを毎日挿入するデータアーカイブシステムです。ユーザーの要求に応じて、この履歴レコードに関するさまざまな種類のレポートを生成するため、いくつかの懸念があり、技術的な入力とアドバイスが必要です。

• この種のアーカイブテーブルとデータベースを管理する最良の方法は何ですか？

これが私の意見です：

1. 更新/削除がほとんどない場合は、ページフィル係数を95％に増やすことができます。これはスペースと読み取りを節約します。いくつかのテストを行います。
2. 年などの幅広いカテゴリに基づいてテーブルを分割します。
3. これらのパーティションを異なるファイルグループに配置します。

年間2億行は特に大きくありません（行が異常に大きい場合を除く）。適切なデータベース設計原則（正規化）に注意を払い、インデックス作成やパーティション分割などの標準機能を利用する必要があります。もちろん、適切なハードウェアも重要です。

ここには具体的なアドバイスをするのに十分な情報がありません。詳細な設計と実装についてサポートが必要な場合は、誰かを雇うことを検討してください。

• 設計によって、挿入が常にテーブルの最後になるようにしてください。ヒントクラスタ化インデックス。

• 最小限のメンテナンスを維持するために必要なレポートをサポートする非クラスター化インデックスはほとんどありません。これらのレポートは事前に生成されていますか？はいの場合は、この質問を検討してください。レポートの生成に2時間かかる場合は問題ありませんか（インデックスなし）または1分（インデックスあり）。たぶん、レポートのインデックスが1つ少なくなるまで2時間かかることは問題ありませんか？またはそうでないかもしれません？レポートが適切に事前生成されていない場合、これは別の問題です。ユーザーが待つのが好きではないため、レポートをサポートするためにさらに多くのインデックスを実装する必要がある場合があるためです。

• このデータベースの記述方法から、多くの行を期待しているように聞こえ、データは追加されて大きくなります。このシステムをバックアップする方法を検討しましたか？ほとんどのデータは同じで新しいものを追加するだけだと思いますか？このシステムのビジネス要件はわかりませんが、1〜2年でこれはかなりのサイズのデータ​​ベースになり、多くの完全バックアップを作成できない場合があるようです。定期的に（毎週？）、差分（毎日？）、トランザクションログ（毎時？）で1つのフルバックアップを作成することを検討してください。アーカイブシステムでは、サイズが問題になることがあります。