0

これは、SQL Server 2008 R2 と SSIS に関するものです。

あるサーバー上の多数の履歴テーブルを、別のサーバー上の運用テーブルからの新しいデータで更新する必要があります。

2 つのサーバーはリンクされておらず、今後もリンクされません。

一部の履歴テーブルには数億の行があり、一部の運用テーブルには数千万の行があります。

現在、次のデータ フロー コンポーネントを使用する各テーブルのプロセスを用意しています。

  1. OLEDB Source タスクを使用して、適切な生産データを取得します。
  2. 本番データのキーが履歴テーブルに既に存在するかどうかを確認するルックアップ タスクと、「エラー出力にリダイレクト」を使用する -
  3. 不足しているデータを OLEDB 宛先履歴テーブルに転送します。

大きなテーブルの場合、プロセスは遅すぎます。もっと良い方法があるはずです。誰か助けてくれませんか？

サーバーがリンクされていれば、単一のセットベースのクエリでタスクを簡単かつ効率的に実行できることはわかっていますが、サーバーはリンクされていません。

4

2 に答える 2

1

問題をより小さな問題に分割します。それがあなたがこれを解決しようとしている唯一の方法です。

問題を調べてみましょう。

  1. 既存のデータを挿入および/または更新しています。データベース レベルでは、行はページにパックされます。ぴったり合うことはめったになく、通常はページにある程度の空き領域が残っています。行を更新するとき、Name フィールドが "bob" から "Robert Michael Stuckenschneider III" になったとします。その行には、より多くのスペースが必要であり、ページにいくらかのスペースが残っていますが、十分ではありません。他の行が次のページにシャッフルされて、このページに余裕を持たせる場合があります。これにより、多くのディスク アクティビティが発生します。はい、データを追加していることを考えると避けられませんが、その方法を理解することが重要ですデータが増大し、データベース自体がその増大に対応できるようにします。おそらく、ターゲット テーブルにいくつかの非クラスター化インデックスがあります。それらを無効化/ドロップすると、挿入/更新のパフォーマンスが向上します。データベースとログが 10% または 1MB または既定値のいずれかで拡大するように設定されている場合、ストレージ エンジンはすべての時間をファイルの拡大に費やし、実際にデータを書き込む時間がありません。要点: システムが大量のデータを受信する準備ができていることを確認してください。DBA、LAN、および SAN チームと協力する

  2. OLTP システムには数千万の行があり、アーカイブ システムには数億の行があります。OLTP データから始めて、履歴システムに存在しないものを特定する必要があります。あなたのデータ量を考えると、私はこのパッケージの処理に問題があり、「再起動可能」である必要があると考えています。ターゲット テーブルとの照合に使用される OLTP から選択されたビジネス キーのみを含むデータ フローを持つパッケージがあります。これらのキーを OLTP サーバー (ToBeTransfered) に存在するテーブルに書き込みます。これらのキーのサブセット (N 行) を使用する 2 番目のパッケージをソースとして元のテーブルに結合します。宛先に直接配線されているため、ルックアップは必要ありません。その太いデータ行は、ネットワーク上で 1 回だけ流れます。次に、SQL 実行タスクを実行して、アーカイブ サーバーに送信したばかりのバッチを削除します。このバッチ処理方法により、複数のサーバーで 2 番目のパッケージを実行できます。SSIS チームは、論文でより適切に説明しています。30 分で 1 TB をロードしました

  3. ルックアップが次の形式のクエリであることを確認してください。ルックアップSELECT key1, key2 FROM MyTableにフィルターを提供できますか? WHERE ProcessingYear = 2013OLTP に 2013 年のデータしか含まれていない場合は、2012 のキャッシュを無駄にする必要がないためです。

  4. Connection Manager でPacketSizeを変更し、ネットワーク担当者にジャンボ フレームをセットアップしてもらう必要がある場合があります。

  5. クエリを見てください。良い計画を立てていますか？テーブルのインデックスが過剰に作成されていませんか? 各インデックスは、実行される書き込み数の増加につながることを覚えておいてください。それらをダンプして、処理が完了した後に再作成できれば、SAN 管理者が FusionIO ドライブをいくつか購入したと考えることができます。全部で 10 列しかない 10 億行のテーブルから 14 個の NC インデックスを削除したときのことを私は知っています。

それでもパフォーマンスの問題が発生する場合は、理論的なベースラインを確立し (現実の世界では決して発生しない理想的な条件下では、N 単位の時間で A から B に 1 GB をプッシュできます)、そこから実際のは。制限要因 (IO、CPU、メモリ、またはネットワーク) が必要です。犯人を見つけて、より多くのお金を投入するか、それが遅れている指標でなくなるまでソリューションを再構築します.

于 2013-07-18T03:28:58.543 に答える
0

ステップ 1. 新しいサーバーへの適切な誇りデータの増分一括インポート。参照: 単一のクライアント (またはストリーム) から空でないテーブルへのデータのインポート http://msdn.microsoft.com/en-us/library/ms177445(v=sql.105).aspx

ステップ 2. Merge ステートメントを使用して、新規/既存のレコードを識別し、それらを操作します。

新しいサーバーではかなりの量のディスク容量が必要になることはわかっていますが、プロセスはより高速に実行されます。

于 2013-07-17T22:06:17.570 に答える