大きいデータベースのテーブルと変更をアーカイブ/バックアップする最も良い方法

Question

大きなマルチスキーマデータベースには興味深い問題と要件があります。

- データベースのサイズは約130Gbです。

- マルチスキーマデータベースで、各顧客にスキーマがあります。

- 現在、システムに102,247個の表があります。

-Microsoft SQL Serverの2K8 R2

これはすべて、単一の定義されたフロントエンドを使用して、顧客のカスタマイズ要件によるものです。 私たちが持っている問題は、データベースのバックアップが天文学になり、失われた/見つからない/間違ったデータを取得するためにデータベースを復元することが悪夢であるということです。最初の製品には監査証跡が定義されておらず、データの保存に「変更」はありません。単純に1バージョンのデータしかありません。

失われたデータを元に戻すとは、基本的に130GBの完全バックアップを復元し、差分/トランザクションファイルをロードしてデータを取得することを意味します。

各スキーマ内の重要なテーブルごとに「チェンジセット」を導入したいと考えています。基本的に一連のデータを保持し、変更された/異なるデータが保存されたときにはそれをX分ごとに格納します。これは最初はSQLジョブでなければなりませんが、何が最善の方法であるかを知りたいのです。

本質的に私は、バックアップするテーブルの各スキーマに 'バックアップ'テーブルを挿入するスクリプトを実行します。

次に、X分ごとにジョブを実行して、各スキーマを順番に調べて、現在のものを挿入してから変更したデータを挿入します。 （行のmodifiedDateに基づいて）それは、自己上書きの前にこの変更ログを約1ヶ月間保持します。

さらに大きなバックアップがありますが、保持期間を長くする必要はありません。私の要点は、変更されたデータをチェックして挿入を実行する最も効率的な方法です。

私の直感では、次のようになります。

INSERT INTO BACKUP_table (UNIQUE ID, col1,col2,col3) 
select col1,col2,col3 from table where and ModifiedDate < DATEADD(mi,+90,Current_TimeStamp) 

*ラフSQL

これは、すべてのスキーマを通過し、これを実行するために、ループ内でなければならないであろう。多くのテーブルはデータを変更しませんでした。

これは良い方法ですか？

どう思いますか？

Answer 1

私の最初の応答は、大規模なデータベース内で独自のスキーマではなく、それぞれの顧客を独自のデータベースに保存することです。これを実行する主な利点は以下のとおりです。

1. 特定の顧客が高活性あなたを持っているとき、あなたは
2. を好きなスケジュールで各顧客のためにバックアップを実行することができ、単一のデータベース
3. のメタデータにはるかに少ないストレス

前回の仕事でこのようなシステムを管理していましたが、500個のデータベースを管理するのは複雑ではありませんでした。アプリケーションとの唯一の違いは、接続文字列のデータベース部分です実際には簡単ですスキーマ接頭辞よりも照会を適応させるため）。

すべての人を単一のデータベースに保つことを本当に約束しているなら、自分の重要なテーブルを自分のファイルグループ内の各スキーマ内に格納し、すべてをプライマリファイルグループから移動することが考えられます。これで、これらのファイルグループを個別にバックアップすることができます。完全なプライマリバックアップと個々のファイルグループバックアップの断片的なリストアだけに基づいて、その顧客のスキーマをオンラインで別の場所に持ち込み、インポート/エクスポート、BCP、またはシンプルなDMLクエリを使用してプライマリデータベースに上書きする）、データベース全体を完全に復元する必要はありません。すべてのユーザーデータをプライマリファイルグループから移動すると、最初のバックアップを復元して特定の顧客のファイルグループを復元するのにかかる時間が最小限に抑えられます。これにより、バックアップ/リカバリ戦略はもう少し複雑になりますが、それはあなたが信じた後のものを達成します。

別のオプションは、意図的な遅延を伴うカスタムログ配布の実装を使用することです。ログをレポートサーバーに送信して、ログを適用する前に12時間待つことで、これをしばらく行っていました。これは、足を踏んだ後に復旧を要求する顧客からの保護を与えてくれました。彼らが間違って12時間以内に連絡を取った場合は、レポートサーバー上でオンライン上のデータが既にオンラインになっていて、それをプライマリサーバで修正します。また、12時間以上経過したデータを参照するレポートのレポートサーバーとしては、プライマリサーバーからかなりの負荷をかけて倍増しました。

また、change data captureと考えることもできますが、パフォーマンスと他の作業負荷への影響をテストする必要があります。このソリューションは、標準、Web、ワークグループなどでは使用できないため、使用しているSQL Serverのエディションによっても異なります。