3

2 つのデータベース間でテーブルを毎日同期する必要があります。ソースは MSSQL 2008、ターゲットは MSSQL 2005 です。UPDATE、INSERT、および DELETE ステートメントを使用すると (つまり、変更された UPDATE 行、新しい行を INSERT し、行が削除されます)、最初に DELETE ステートメントを実行するとパフォーマンスが向上しますか? つまり、更新する必要のない行は削除されるため、UPDATE ステートメントがこれらの行を参照しないようにします。

ここに私が考慮する必要がある他のいくつかのことがあります。テーブルには 100 万から 300 万以上の行があり、トランザクションの量とビジネス要件のために、ソース DB はオンラインのままにしておく必要があり、クエリは可能な限り効率的である必要があります。ジョブは、ターゲット DB の SQL サーバー エージェント ジョブで毎日実行されます。その上、私はDB新人です！

StackOverflow コミュニティに感謝します。あなたは素晴らしいです!

4

3 に答える 3

6

最初に を実行しdelete、次にupdateを実行insertすると、とにかく削除される行を更新する必要はなく、挿入されたばかりの行を更新する必要はありません。

しかし実際には、SQL Server のマージ構文を見たことがありますか? 大量のコードを節約できます。

更新MERGEINSERT/UPDATE/DELETE に対するステートメントのパフォーマンスをチェックしていません。詳細については、Aaron Bertrand による関連リンクを参照してください。

于 2013-10-02T18:51:52.687 に答える
0

ローマンの答えは、現在の状況であなたが探していたものだと思います：DELETE、UPDATE、INSERT（またはMERGE）。

現在、物事をさらに高速化できる他の可能なルートがありますが、プロセスはかなり異なります。

1. ときどきターゲットに対して実行するすべての注文をファイルに保存することを検討してください。

両方のデータベースがまったく同じであると仮定すると、2008 データベースを変更する SQL 命令ごとに、その命令を .sql ファイルに保存し、後で 2005 データベースに対して実行します。ファイルへの書き込み中にファイルをロックすることを検討する必要があり、おそらく何らかの冗長性があります。ただし、これは、2005 データベースで作業を行っている間は、2008 データベースにまったくアクセスする必要がないことを意味します。つまり、2008 年のデータベースの速度に副作用はありません。

落とし穴: ステートメントを見逃す可能性があり、目的地が完全に一致しない場合があります...

2.継続的なレプリケーション

MSSQL については、自動レプリケーションを行うための優れたツールを紹介できるほど詳しくありません ( http://technet.microsoft.com/en-us/library/ms151198.aspxを参照)。良いツールを見つけてください。MySQL ( http://dev.mysql.com/doc/refman/5.0/en/replication.html ) と PostgreSQL ( http://wiki.postgresql.org/wiki/Streaming_Replication ) にはそのようなツールがあり、それらはすべて無料です。

これが私が選択する解決策です。使用するツールによっては、ライブ システムへの影響が最小限に抑えられ、2005 の複製が数秒以内に更新されることを意味する、非常に最適化されたものになる可能性があります (長距離リモート接続であるかどうかに応じて、作業量、各サーバーのセットアップ、インターネット接続など）

落とし穴は明らかに、データベースに進行中のプロセスを追加することですが、PostgreSQL のストリーミング レプリケーションのように機能する MSSQL ツールを見つけた場合、それはジャーナルのコピーを利用します。ディスク I/O)

3. クラスター データベース (Cassandra など)

これには、データベースの変更が含まれますが、その準備ができていないと確信しています (特に、これらのシステムのほとんどが SQL を提供していないため)。

Cassandra ( http://cassandra.apache.org/ ) のようなシステムは、そのデータを多数のコンピューターに自動的に複製します。実際には、すべてのデータを 100% またはコンピューターごとに X% のデータをレプリケートするようにセットアップでき、障害が発生した場合 (コンピューターが故障した場合) に冗長性を持たせることができます。これにより、システムにいくつかのノードを追加するだけでパフォーマンスが向上するため、別のコンピューターに特定のコピーを作成する必要がなくなります。(コンピュータ 1,000 ドル未満で、それだけの価値があります! 率直に言って、5 万ドル以下で Peta Byte システムを作成し、最終的には、どの SQL データベースよりもはるかに高速なものを作成できます...)

主な問題は、これらのクラスターの使用が SQL とはまったく異なることです。しかし、これは大規模なデータベースを持ち、非常に高速である必要があり、ミニコンピューター (数ミリ秒で 1 億行を管理する Cobol と 25 万ドルのコンピューター) に投資したくない大企業にとってのソリューションになる可能性があります。 .)

Cassandra を使用すると、フロント エンド システムに影響を与えずに、バック エンド コンピューターで非常に負荷の高いバッチ プロセスを実行できます。

于 2013-10-02T20:08:50.907 に答える