0

現在、あるSQL 20008マシンから別のマシンにデータを移動するために実行されるSSISジョブがあります。このジョブは、約 6 つのテーブルから約 200 万件のレコードを移動します。サーバーの負荷にもよりますが、これには約 5 ～ 10 分かかりますが、問題ありません。データは一時テーブルに移動されるため、サーバーへの負担以外に影響はありません。

しかし、私の問題は、そのデータをそれぞれのライブテーブルとマージしたいときです。これには、テーブルが空になってから再設定されるまでに約 15 分かかる場合があります。私が疑問に思っているのは、そのデータをテーブル間で移動する最も効率的な方法は何かということです。

現在のところ、その方法は次のとおりです。

drop tables
インデックスと制約を使用してテーブルを再構築します
insert into select データを移動し、
必要な計算を
実行します 次のコマンドを実行して、データの移動後にすべてのインデックスを再構築します。

sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?')"

ユーザーのダウンタイムを最小限に抑えるには、もっと良い方法が必要だと思います。私が考えていたのは、2番目のテーブルセットを作成し、準備ができたらそれらの名前を変更することでしたが、それが最善の方法であるかどうかもわかりません.

また、テーブルを削除して再作成する必要がないため、より良いマージコマンドについて読んだところです。これは、すべてのデータが利用可能なままであることを意味しますが、ほぼすべての列を見ないとレコードが変更されたかどうかを知るのは難しいです.

助けていただければ幸いです。

4

4 に答える 4

3

空にして再投入する場合、現在のテーブルと同じ名前のビューを作成し (既存のコードが壊れないようにするため)、同じ構造とすべてのデータを持つ tablenameA と tablenameB という 2 つのテーブルを作成することがよくあります。ビューを tablenameA にポイントします。TableNameB を切り捨てます。インデックスを削除します。プロセスを実行して tablenameB を埋めてインデックスを再作成し、スクリプトを実行してビューが tablenameB を指すようにします。ユーザーのダウンタイムは？ミリ秒。次回は、TableNameA を切り替えて切り捨てて入力し、ビューを TableNameA にやり直します。

于 2011-03-10T19:18:03.723 に答える
2

テーブルの分割を見てください。あなたのユースケースは、テーブルのパーティション分割が存在する理由の 1 つだと思います。

ここに要約があります

これはあなたの質問でより適切です

この機能は、Enterprise SKU と Developer SKU でのみ利用できることに注意してください。

于 2011-03-10T19:36:15.933 に答える
0

テーブルのパーティション分割に関する上記のポイントに加えて、一時テーブルへのステップを回避できます。宛先サーバーでパッケージを実行している SQL Server 宛先を使用して、空のパーティションに読み込みます。パーティション化されたインデックスを使用し、その空のパーティションに対してのみインデックスを再構築します。新しいパーティションにマージします。

于 2011-03-15T13:23:11.557 に答える
0

さまざまな基礎となるテーブルを持つビューのオプションを検討した後、複雑さと混乱を招く可能性を避けることにしました。パーティショニングを検討しましたが、ソース マシンをあまり制御できないため、適切なソリューションとは思えませんでした。そのため、最終的には、SQL MERGE ステートメントを使用し、BINARY_CHECKSUM を使用して行を比較し、違いがあるかどうかを判断することにしました。私はそれでロックに問題はありませんが。しかし、私はそのために別の質問を開きました。

SQL MERGE ステートメントのパフォーマンスを向上させる方法

于 2011-04-14T18:09:05.443 に答える