データベースが大きくなりすぎているため、現在いくつかのパフォーマンスの問題に直面しています。過去10年間のデータが保存されており、2年以上前のデータを新しいデータと同じテーブルに保存する必要がある理由はわかりません。

現在、私はデータベースの管理にあまり深い経験がないので、古いデータをアーカイブする最良の方法を探しています。

情報

• データベースには合計で約310'000'000レコードがあります。

• データベースには、ハードディスクに250 GBが必要です。

• サーバーのバージョンは、互換性レベルがSQL Server 2005（90）のSQL Server 2008ですが、SQL Server 2012へのアップグレードを近日中に計画しています

私は2つの可能性について考えました：

新しいデータベース

実動サーバー上のデータベースと同様のデータベースを作成し、すべての古いデータを新しいデータベースに挿入します。

• 欠点：リンクサーバーは環境で許可されていないため、必要に応じて古いデータを結合することは困難です。

履歴スキーマ

本番データベースと同じテーブルで新しいスキーマfe [hist]を作成します。新しいスキーマのこれらの新しいテーブルにすべての古いデータを挿入します。

• 利点：将来的に古いデータが必要になる場合、簡単に参加できます

• 解決策の1つを他よりも優先しますか？
  • どうして？
• より良い可能性はありますか？
• このタスクを簡単に実行できる既存のツールはありますか？
• 他に考えはありますか？

前もって感謝します

編集

追加の質問：

新しく作成されたアーカイブテーブルもプライマリ/外部キーを必要としますか？

または、キー/制約のない列だけが必要ですか？

あなたの質問の多くに対する答えは、それが依存するということだと思います。どのようなパフォーマンスの問題がありますか？データベースのサイズが250GBに拡大しただけでパフォーマンスの問題が発生することは珍しいようです。

おそらく、日付範囲のごく一部（たとえば、昨年）だけが必要な場合でも、クエリはファクトテーブル全体でテーブルスキャンを実行していますか？最適化が最も重要な特定のクエリがある場合は、スキーマ、クエリ、および実際の実行計画を別の質問に投稿して、最適化できるかどうかを検討してください。

他のソリューションよりもソリューションの1つを好みますか？

私は一般的に履歴データベースを好む、と私はガイが彼の応答でこの理由を説明すると思います。

（スキーマではなく）履歴データベースで見られる主な欠点は、アーカイブテーブルに外部キーを使用できないことです。これはあなたには問題ないかもしれませんが、注意する必要があります。

このアプローチで挙げた欠点は正確ではありません。同じサーバー上のデータベース間で簡単にクエリを実行でき、クエリオプティマイザーは通常、データベース間のクエリを非常にうまく処理します。

より良い可能性はありますか？

アーカイブデータを定期的にクエリする必要がある場合は、日付でテーブルをパーティション分割することを検討できます。ただし、これは大きな変化であり、肯定的なもの（パーティションの削除、より効率的なデータ読み込みなど）と否定的なもの（シングルトンシークの低速化、並列クエリでのスレッドスキューの可能性など）の両方に大きな影響を及ぼします。したがって、データベースが頻繁に使用される場合、この決定を簡単に行うことはありません。

新しく作成されたアーカイブテーブルもプライマリ/外部キーを必要としますか？または、キー/制約のない列だけが必要ですか？

少なくとも主キーと一意のインデックスを用意することをお勧めします。これにより、それらが提供するデータ整合性のメリットを得ることができます。たとえば、これにより、1年分のデータを誤って履歴テーブルに2回挿入することを防ぎます。副次的な利点として、履歴テーブルを照会する必要がある場合、パフォーマンスが向上する可能性があります。

他に考えはありますか？

Enterprise Editionを使用しており、SQL 2008+へのアップグレードを計画しているため、このテーブルのデータ圧縮を検討する場合があります。圧縮は確かにディスク容量を削減しますが、サーバーのディスクおよびCPUリソースによっては、ディスクI / Oを削減し、メモリ使用率を向上させることで、読み取りのクエリパフォーマンスも向上する場合があります（一度により多くのデータがキャッシュに収まります）。

いつでも、リンクサーバーよりも履歴スキーマまたは2番目の履歴データベースを使用することをお勧めします。ライセンスコストを節約し、管理とクエリが簡単になります。その後、より単純なスキーマを使用して、データベースのサイズを小さくするインデックスの一部を削除することもできます

ただし、エンタープライズエディションを使用しているため、テーブルをパーティション化する 3番目のオプションがあります。これにより、データをアーカイブしやすくなり、古いデータのクエリがユーザーに対して透過的になり、アプリケーションを変更する必要がなくなります。 。

私の経験では、2つの理由から2番目のデータベースが好ましい選択肢です。

1. 履歴バックアップからデータを復元し、不要なテーブルとインデックスを削除できます。
2. これをレポート目的で別のサーバーに移動できます。これには、プライマリサーバーのリソースを使用しないという利点があります。

プライマリデータベースからすべての履歴データを削除する必要がありますが、これをスケジュールすることもできます。

私が時間を費やす場所ではないので、今のところライセンスを無視します。

私見、アーカイブデータベースは実装と保守が最も簡単です。それらは明確で疎結合のエンティティです。データの移動と負荷/リソースの制御には明確な境界があります。パフォーマンス管理とコストを改善するために別のインスタンスまたはサーバーに簡単に移動できるため、大きな問題ではありません。最も単純な！=最も安価または最小限の労力であることに注意してください。実際にはかなり多くのタスクがありますが、それらはすべて2つの重要な例外がある単純なタスクです。

1. 制約の強制-SQL Serverにはデータベース間の制約のようなものはないため、これが取引を中断するかどうかを判断する必要があります。
2. クロスデータベースクエリは、廃止されたOLEDBに依然として依存している分散クエリを使用します。つまり、新しいデータ型で問題が発生する可能性があることに加えて、パフォーマンスの問題が発生した場合、それらが修正されることはほとんどありません

アーカイブスキーマまたは単なるアーカイブテーブルは、実装がもう少し複雑ですが、はるかに使いやすいです。同じデータベース内のすべてのオブジェクトは、アクセス制御を複製および維持する必要がないことを意味します。簡単なパフォーマンスチューニング、監視、トラブルシューティングなどを行うクロスデータベースクエリなし

テーブルパーティションは優れたソリューションであり、アーカイブテーブル/スキーマの多くの利点を提供しますが、ユーザー/クエリに対して透過性を提供します。とはいえ、それは実装するのが最も複雑であり、初心者にとっては容易ではない継続的なケアが必要です。

いくつかの重要な考慮事項：

• クエリは履歴/コールドデータを定期的に返しますか、またはコールドデータはめったにアクセスされませんか？
• 履歴データは不変ですか、それとも定期的に更新/削除されますか？
• 310mの行は、行サイズに応じて「中程度」です（1つのテーブルにすべてを想定）。行サイズのデータ​​はありますか？310mの行は何GBですか？
• そのテーブルの成長率はどのくらいですか？
• アプリケーションコードとそのSQLクエリを変更できますか？

これらは、選択したソリューションに大きな影響を与える可能性があるため、または特定のソリューションを許可しない場合があるため、重要な考慮事項です。たとえば、履歴データが定期的に（週に1回以上）変更/更新される場合、別のデータベースを使用すると、それらのクエリにDTCを使用するか、トランザクションの安全性を手動で管理する必要があります（常に正しいことを保証するために重要です）。コストは、不変の履歴データよりも大幅に高くなります。

また、アップグレードを検討している場合は、2016および新しいStretch Database機能を検討してください：https : //msdn.microsoft.com/en-us/library/dn935011.aspx

次の理由から、データベースを個別の論理データベースに分割することをお勧めします。

1.リソース要件

これを個別のデータベースに分割することにより、別のドライブに保存し、メインの本番データとは異なるレートで監視できます。

2.パフォーマンス

データを個別のデータベースに分割することにより、メインの実稼働データベースのサイズが縮小され、全体的なパフォーマンスが向上します。

3.シンプルなバックアップ

アーカイブされたデータのバックアップは、メインSQLデータベースの「ライブ/現在の」レコードほど重要とは見なされない場合があります。これは、アーカイブされたデータのバックアップ頻度が低くなる可能性があることを意味します。また、アーカイブされたデータがログに記録される方法のシーケンシャルな性質により、アーカイブされたデータベースのセクションを一度だけバックアップし、その後二度とバックアップすることができない場合があります。たとえば、2014年のアーカイブデータが変更アーカイブデータベースに書き込まれると、そのデータに再び変更が加えられることはありません。

注：あなたの質問の多くに対する答えはすべて、あなたの状況、データの性質、そしてあなたが抱えていたパフォーマンスの問題に依存していると思います。