「アーカイブされているが使用可能な」データのSQL Serverデータベース設計

「縮小」しようとするこの大規模なデータベース（1 TBを超える）があります。データベースは1つの主要なエンティティを中心に展開するため、「訪問」と呼びましょう。議論のために、それが医療行為のデータベースであるとしましょう。

手続き、年次、フォローアップ、予防接種など、合計30の訪問「タイプ」があり、それぞれが「visit_immuno」などの「Visit」への補助表です。

データベースには、2000年以降約12年間のデータが蓄積されています。「ライブ」バージョンに約3年間のデータを保持し、残りを「old_data」データベースに保持することを提案する人がいます。日付は正規化されているため、「Visit」テーブルにのみ保存されます。Visitテーブルには、ROWVERSION列とBIGINT疑似ID（クラスター化）列も含まれます。すべての意図と目的のために、クラスタリングキーにSEQUENCE（SQL Server 2012 Enterprise）が入力されているとしましょうcid。

visit.date医師がデータの彼の「ブリーフケース」を拡張訪問し、リターンになったとき、それはメインテーブルにマージされます例えば、クラスタリング・キーと同じ順序で常にではありません。また、「visit」テーブルにいくつかの更新があり、ROWVERSION列がcidとdate列の両方と同期しなくなります-簡単に言えば、この理由のために適切なパーティションキーを作成することもできROWVERSIONませんcid。

「ライブ」からデータを取り出すためのビジネスルールは、ということであるvisit.date36ヶ月よりも大きくなければなりませんし、子visit_paymentレコードが存在している必要があります。また、「old_data」データベースには、を除くベーステーブルは含まれていませんvisit%。

したがって、次のようになります。

Live DB（毎日使用）-すべてのテーブルOld-Data DB- visit%テーブルの古いデータ

提案では、2つのデータベースのテーブル全体でALLを結合するビュー（およびを除く）のすべてのベーステーブルに対するシノニムを含むシェルである結合DBが必要です。Live DBvisit%visit%

同じインデックスがOld-DataDBに作成されていると仮定すると、クエリはUNION-ALL ビューで適切に実行されますか？UNION-ALL ビューの実行計画をどのような種類のクエリパターンがトリップするか？

便宜上、ライブデータベースが呼び出さLiveDbれ、achiveデータベースが呼び出されると仮定します。ArchiveDb

• シノニムを介してデータベース内LiveDbのテーブルを指すUNION ALLビューを追加しArchiveDbます（シノニムと結合されたdbを行う必要はありません）
• visit.dateこの列visit_paymentsがまだ存在しない場合は、この列も「パーティション化」して非正規化します（これにより、同じ場所に配置された結合のパフォーマンスが向上します）
• 可能であれば、2つの大きなテーブルのみをアーカイブします（オプティマイザーがトリップする可能性を減らします）。UNION ALLビューと他のテーブルをLiveDb保持して、小さなテーブルへのすべての結合がローカルに保持されるようにします
• 両方のテーブルにCHECK制約を追加LiveDbし、ArchiveDb それがの範囲を説明しvisit.date、テーブルに含まれています。これにより、オプティマイザーは、列を含むシークとスキャンの両方からアーカイブテーブルを削除できますvisit.data。この制約を定期的に更新する必要があります。
• UNION ALLビューで、フィルタリングするWHERE条件を追加しvisit.dataます。これは、チェック制約ですでに提供したヒントに追加されます。これにより、フィルターがプッシュダウンされる可能性が最大になります
• EEがある場合は、アーカイブデータベースでテーブルをパーティション分割します（ただし、ライブデータベースではパーティション分割しません）。本当に空想を得たい場合は、アーカイブデータベースのファイルグループレベルのバックアップ/復元を使用して、バックアップ時間を節約してください。
• AchiveDbまだリカバリモードになっていない場合は、シンプルリカバリモードにすることを検討してください。トランザクションログのバックアップは必要ないでしょうArchiveDb
• INSERT ... WITH（TABLOCK）SELECT ... WITH（ROWLOCK）を使用して、LiveDbとの間でデータを移動するときに宛先で最小限のロギングを強制します ArchiveDb

上記のすべては、オプティマイザがシークおよびスキャンからアーカイブテーブルを削除することを保証するものではありませんが、可能性を高めます。

除去が起こらないとき。これらはあなたが見るかもしれない効果です（このリストは不完全かもしれません）。シークの場合、すべてのクエリで追加のシークを取得します（これによりIOPSが向上します）。スキャンの場合、結果としてアーカイブテーブルとライブテーブルの両方をスキャンすることになり、パフォーマンスが低下する可能性があります。オプティマイザーをトリップする一般的な方法は次のとおりです。

• visit%テーブルを結合visit.dataし、結合条件に含めない場合（これが非正規化する理由です）。このため、クエリの一部を変更することをお勧めします
• visit.data別のテーブル（たとえば、日付ディメンション）との間でハッシュ結合を取得すると、テーブルを適切に削除できない場合があります
• アーカイブされたテーブルでデータを集約しようとする場合
• ただし、visit.dataたとえば、ビューのキーで直接シークするなど、フィルタリングを行う場合。

最後のシナリオでcidは、可能であれば-に別のチェック制約を追加することにより、最悪の影響から身を守ることができます。cidテーブルの行の日付と進行に関して「クリーン」でないシーケンスに言及しました。ただし、次の情報を含むテーブルを維持できますか：「cidこれ以降、この数を超えていないvisit.data」または同様ですか？これにより、追加の制約が発生する可能性があります。

もう1つ注意が必要なのは、パーティションビューをクエリすると、並列クエリがさらに多くのスレッドを生成する可能性があることです（両方の「サブテーブル」が同じ並列最適化にさらされるため）。そのため、サーバー上のMAXDOPまたは並列クエリを制限することができます。

ちなみに、クエリをよく知っている場合は、2つのデータベースに同じインデックスさえ必要ないかもしれません（これは、テーブルを適切に削除することを100％確信していることを前提としています）。列ストアの使用を検討することもできますArchiveDb。

これまでの方法は、古いデータをバッチで新しく作成したデータベースに書き込み、ライブデータベースから古いデータを削除することです。そうすれば、両方のデータベースにアクセスできます。また、新しく作成したデータベースをバックアップし、他の場所に復元して、運用サーバーから大きなフットプリントを削除することもできます。それがあなたのニーズに受け入れられる解決策であることを願っています。