古いデータのアーカイブ
データベースが大きくなりすぎているため、現在パフォーマンスの問題が発生しています。過去10年間に保存されたデータがあり、2年より古いデータを新しいデータと同じテーブルに保存する必要がある理由はわかりません。
データベース管理の経験があまりないので、古いデータをアーカイブする最良の方法を探しています。
情報
データベースには合計で約310'000'000のレコードがあります。
データベースには、ハードディスク上に250 GBが必要です。
- サーバーのバージョンは互換性レベルがSQL Server 2005（90）のSQL Server 2008ですが、近日中にSQL Server 2012へのアップグレードを計画しています
私は2つの可能性について考えました。
新しいデータベース
本番サーバーと同様のデータベースを作成し、すべての古いデータを新しいデータベースに挿入します。
- 欠点：リンクサーバーは私たちの環境では許可されていないため、必要に応じて古いデータを結合することは困難です。
履歴スキーマ
新しいスキーマを作成します。 [hist]本番データベースと同じテーブル。新しいスキーマのこれらの新しいテーブルにすべての古いデータを挿入します。
- 利点：将来、古いデータが必要になる場合に簡単に参加できる
- どちらか一方を優先しますか？
- どうして？
- より良い可能性はありますか？
- このタスクを簡単に実行できる既存のツールはありますか？
- 他に何か考えはありますか？
前もって感謝します
編集する
追加の質問：
新しく作成されたアーカイブテーブルにも主/外部キーが必要ですか？
または、列はあるがキー/制約はないのでしょうか？
あなたの質問の多くに対する答えは、それは場合によって異なると思います。どのようなパフォーマンスの問題がありますか？データベースのサイズが250GBに増加するだけで、パフォーマンスの問題が発生するのは珍しいようです。
おそらく、クエリで日付範囲のごく一部（昨年など）が必要な場合でも、ファクトテーブル全体に対してテーブルスキャンを実行していますか？最適化が最も重要な特定のクエリがある場合は、スキーマ、クエリ、および実際の実行プランを別の質問に投稿して、最適化できるかどうかを確認することを検討してください。
どちらか一方のソリューションを好みますか？
私は通常、履歴データベースを好みますが、ガイはこの理由について 彼の応答 で説明していると思います。
（スキーマではなく）履歴データベースの主な欠点は、アーカイブテーブルに外部キーを使用できなくなることです。これは問題ないかもしれませんが、注意する必要があります。
このアプローチでリストした欠点は正確ではありません。同じサーバー上のデータベース間で簡単にクエリを実行でき、クエリオプティマイザーは通常、データベース間のクエリを非常に適切に処理します。
より良い可能性はありますか？
アーカイブデータを定期的にクエリする必要がある場合は、 日付でテーブルをパーティション分割する を検討します。ただし、これは大きな変更であり、多くのパフォーマンスに影響を与える可能性があります。ポジティブ（パーティションの削除、より効率的なデータロードなど）とネガティブ（たとえば、シングルトンシークが遅い、並列クエリでのスレッドスキューの可能性が高い）の両方です。そのため、データベースが頻繁に使用されている場合、この決定を軽く行うことはありません。
新しく作成されたアーカイブテーブルにも主/外部キーが必要ですか？または、列はあるがキー/制約はないのでしょうか？
それらが提供するデータ整合性の利点を得ることができるように、少なくとも主キーと一意のインデックスを用意することをお勧めします。たとえば、これにより、誤って1年分のデータを履歴テーブルに2回挿入することが防止されます。また、副次的な利点として、履歴テーブルを照会する必要がある場合は、パフォーマンスが向上する可能性があります。
他に何か考えはありますか？
Enterpriseエディションを使用していて、SQL 2008+へのアップグレードを計画しているため、このテーブルで データ圧縮 を検討する場合があります。圧縮によってディスク領域が確実に減少しますが、サーバーのディスクとCPUリソースによっては、ディスクI/Oを減らしてメモリ使用率を向上させることにより、クエリのパフォーマンスを向上させることもできます（一度により多くのデータがキャッシュに収まる）。
いつでもリンクサーバーよりも履歴スキーマまたは2番目の履歴データベースを使用することをお勧めします。ライセンスコストが節約され、管理とクエリが簡単になります。その後、より単純なスキーマを使用して、いくつかのインデックスを削除し、データベースを小さくすることもできます
ただし、Enterprise Editionを使用しているため、3番目のオプション テーブルのパーティション分割 を選択できます。これにより、データをアーカイブしやすくなり、古いデータのクエリがユーザーと透過的に行われます。アプリケーションを変更する必要はありません。
私の経験では、2つの理由で2番目のデータベースが推奨されます。
- 履歴バックアップからデータを復元してから、不要なテーブルとインデックスを削除できます。
- これをレポート目的で別のサーバーに移動できます。これには、プライマリサーバーのリソースを使用しないという利点があります。
プライマリデータベースからすべての履歴データを削除する必要がありますが、これをスケジュールすることができます。
現時点ではライセンスを無視しているのは、ここでは時間を費やしていないためです。
私見、アーカイブデータベースはsimplestを実装および維持します。これらは、個別の疎結合エンティティです。データ移動とロード/リソース制御には明確な境界があります。パフォーマンス管理を改善するために別のインスタンスまたはサーバーに簡単に移動でき、コストは大きな問題ではありません。最も単純な！=最も安く、または最も手間がかからないことに注意してください。実際にはかなり多くのタスクがありますが、これらはすべて2つの重要な例外を除いて単純なタスクです。
- 制約の適用-SQL Serverにはデータベース間の制約などはないので、それが取引ブレーカーかどうかを判断する必要があります。
- クロスデータベースクエリは、非推奨のOLEDBに依存している分散クエリを使用します。つまり、新しいデータ型の問題が発生する可能性があります。また、パフォーマンスの問題が発生した場合、修正される可能性はほとんどありません。
アーカイブスキーマまたは単にアーカイブテーブルは、実装が少し複雑ですが、はるかに使いやすくなっています。同じデータベース内のすべてのオブジェクトは、アクセス制御を複製して維持する必要がないことを意味します。クロスデータベースクエリがないため、パフォーマンスの調整、監視、トラブルシューティングなどが簡単になります。
テーブルのパーティション分割は優れたソリューションであり、アーカイブテーブル/スキーマの多くの利点を提供しますが、ユーザー/クエリに透過性を提供します。とはいえ、これは実装が最も複雑であり、初心者には容易ではない継続的なケアが必要です。
いくつかの重要な考慮事項：
- クエリは履歴/コールドデータを定期的に返しますか、それともコールドデータへのアクセス頻度は低いですか？
- 履歴データは不変ですか、それとも定期的に更新/削除されますか？
- 310mの行は、行のサイズに応じて「中程度」です（1つのテーブルですべてを想定）。行サイズのデータはありますか？その310m行は何GBですか？
- そのテーブルの成長率はどれくらいですか？
- アプリケーションコードとそのSQLクエリを変更できますか？
これらは、選択したソリューションに大きな影響を与える可能性があるか、特定のソリューションを許可しない場合もあるため、重要な考慮事項です。たとえば、履歴データが定期的（週に1回以上）に変更/更新される場合、別のデータベースを使用することは、これらのクエリにDTCを使用するか、トランザクションの安全性を手動で管理する必要があることを意味します（常に正しいことを保証するのは簡単ではありません）。コストは不変の履歴データよりも大幅に高くなります。
また、アップグレードを検討している場合は、2016と新しいStretch Database機能を検討してください。 https://msdn.Microsoft.com/en-us/library/dn935011.aspx
次の理由により、データベースを個別の論理データベースに分割することをお勧めします。
1。リソース要件
これを別のデータベースに分割することで、別のドライブに保存し、主要な本番データとは異なる速度で監視できます。
2。パフォーマンス
データを別のデータベースに分割することにより、メインの本番データベースのサイズが縮小され、全体的なパフォーマンスが向上します。
。よりシンプルなバックアップ
アーカイブされたデータのバックアップは、メインSQLデータベースの「ライブ/現在の」レコードほど重要ではないと見なされる場合があります。これは、アーカイブデータのバックアップ頻度が減ることを意味する場合があります。また、アーカイブされたデータのログ方法にはシーケンシャルな性質があるため、アーカイブされたデータベースのセクションを一度だけバックアップして、二度とバックアップすることができない場合があります。例えば。 2014年の変更アーカイブデータベースにアーカイブデータが書き込まれると、そのデータは再び変更されることはありません。
注：多くの質問への回答は、状況、データの性質、および発生していたパフォーマンスの問題にすべて依存すると思います。