はアイデアがある</p> <p>など、私は（いくつかのサーバー上に分散）複数の同一のデータベースを持っている

Question

（複数のデータベースの）一つのテーブルに複数のテーブルをコピーし、データマイニングを行うために1つのポイントにそれらを収集する必要がありそれぞれのデータベースからTable1、Table2、...、TableNを取り込み、それらをマージして1つの大きなデータベースに結果を入れます。

問合せを作成し、各行がどのデータベースから来たのかを知るために、行がどこから来たのかを記述する単一の列DatabaseIDをターゲット表に追加します。 ソーステーブルの編集はオプションではなく、独自のソフトウェアに属しています。

私たちは~40台のサーバーと170台のデータベースを持ち、〜40台のテーブルをコピーする必要があります。

さて、どのように我々はそれがあるべきことを考えると、これを実装する必要があります。

• 簡単なセットアップ
• 簡単にデータベーススキーマが
• 信頼性の高い、ログを/変更した場合に調整することが好ましく簡単
• を維持するために、何かが失敗した場合のアラーム
• コピーするテーブルを追加するのがあまりにも難しくない

SSISを調べましたが、各テーブルをソース/変換/宛先として追加する必要があるようでした。私はそれがデータベーススキーマと結びついていると推測しています。右？

また、SQL Serverレプリケーションを使用することもできますが、各テーブルにDatabaseID列を追加する方法はわかりません。データを変更するのではなくコピーすることは可能です。 多分、すべてのデータを別々のデータベースにコピーして、ターゲットサーバ上でローカルジョブを実行してテーブルをマージすることは可能でしょうか？ コピーするテーブルを増やす必要がある場合は、各データベースの新しい出版物を再配布する必要があるため、作業が多いようです。

最後のオプション（？）は、私たちのニーズに合わせてカスタムアプリケーションを作成することです。投資時間が長引いても、少なくとも私たちが望むものを正確に行うでしょう。

私たちはMicrosoft SQL Server 2000を使用しています。 6ヶ月以内にSQL Server 2008 R2にアップグレードしますが、プロジェクトをより早く使用したいと考えています。

あなたの意見を教えてください。

UPDATE 20110721

我々は集計データベースをご希望のSQL Serverへの接続を開くF＃のプログラムになってしまいました。そこから、いくつかのテーブルからすべての行（ただしすべての列ではない）をフェッチし、各テーブルに追加の行を追加して、その行がどのDatabaseIDであるかを示す40のリンクSQLサーバーを照会します。 フェッチ元のサーバーの構成、どのテーブルとどの列がテキストファイル構成とハードコード値（heh：D）の組み合わせであるか。 超高速（これまでのシーケンシャルフェッチ）ではありませんが、それは絶対に管理可能で、後で行うデータ処理には非常に時間がかかります。

今後の改善点は次のとおりです。

• 問題が発生した場合（サーバーがオンラインでない場合など）、エラー処理が改善されます。
• は、フェッチを完了するための合計時間を短縮するために、並列フェッチを実装します。
• 追加/更新されたものだけのように、一部の行のみを取得するだけで十分であるかどうかを判断します。

全く単純であり、他の製品に依存しないことが実証されており、実際にはうまく機能します。

Answer 1

空想何もいますが、

簡単にを調整する

簡単に維持するために簡単

セットアップに

DROP TABLE dbo.Merged 

INSERT INTO dbo.Merged 
SELECT [DatabaseID] = "Database1", * FROM ServerA.dbo.Table 
UNION ALL SELECT [DatabaseID] = "Database2", * FROM ServerB.dbo.Table 
... 
UNION ALL SELECT [DatabaseID] = "DatabaseX", * FROM ServerX.dbo.Table 

利点

• 簡単のような何かを行うことができませんでしたテーブルを追加する

デメリット

• パフォーマンス
• 信頼性の高いログ

Answer 2

我々は異なるアプローチを取った同様の要件を持っていました。最初に中央データベースを作成してデータを収集しました。次に、ターゲットサーバー/データベースのリストを格納するインベントリテーブルを作成しました。次に、SQLクエリ、ターゲットSQLインスタンス名、およびデータを格納するターゲットテーブルのパスを取る小さなvb.netベースのCLRプロシージャ（これにより、新しいターゲットが追加されたときにリンクされたサーバーの設定が削除されます）。これは結果セットに2つの追加の列も追加します。ターゲットサーバー名と、データがキャプチャされたときのタイムスタンプ。

次に、サービスブローカのキュー/サービスとターゲットサーバのプッシュされたリストを設定して相互に関連付けます。

上記のCLRプロシージャは、メッセージをデキューする別のプロシージャでラップされ、提供されたターゲット・サーバーでSQLを実行します。ラッパー・プロシージャーは、キューのアクティブ化されたプロシージャーとして構成されます。

これにより、データをキャプチャするために少しの並列性を達成することができます。

利点：セットアップ簡単に

• 簡単に（ターゲットを追加/削除）を管理する
• 同じフレームワーク
• ログテーブルが失敗したクエリをチェックするために複数のクエリのために動作します。
• 各ターゲットとは独立して動作するため、ターゲットの1つが に応答しなかった場合でも、他のターゲットは応答を続行します。
• ワークフローは、キューを無効にして（セントラルサーバーで メンテナンスのために）正常に一時停止してから、コレクションを再開して を再度有効にすることができます。

欠点：

• は、サービスブローカーの十分な理解が必要です。
• は、毒メッセージを適切に処理する必要があります。

それは試してみる価値