非常に大きなデータ セット (最大 300 万レコード) があり、毎日のスケジュールで更新と新しいレコードをマージする必要があります。レコード セットを実際に 1000 個のレコード チャンクに分割し、MERGE一時テーブルでコマンドを使用して、データの更新中にライブ テーブルがロックされないようにするストアド プロシージャがあります。問題は、それがまったく役に立たないことです。テーブルは依然として「ロックアップ」しており、データにアクセスしようとすると、データを使用する Web サイトがタイムアウトを受け取ります。私はそれを 100 個のレコード チャンクに分割してみましたWAITFOR DELAY '000:00:5'。それはまだかなり鈍いです。
テーブルをロックせずに大量のデータをマージする方法に関する提案、ベスト プラクティス、または例を探しています。
ありがとう
select を実行する際に NOLOCK または READ UNCOMMITTED を使用するようにフロント エンドを変更します。
更新を実行するにはレコードをロックする必要があるため、NOLOCK MERGE、INSERT、または UPDATE は実行できません。ただし、SELECTS を NOLOCK することはできます。
これは注意して使用する必要があることに注意してください。ダーティ リードが問題ない場合は、先に進みます。ただし、読み取りに更新されたデータが必要な場合は、別の道をたどって、3M レコードのマージが問題を引き起こしている理由を正確に把握する必要があります。
ほとんどの時間は、マージ コマンド中のディスクからのデータの読み取りや、メモリ不足の状況での作業に費やされていることは間違いありません。データベース サーバーにより多くの RAM を詰め込んだほうがよいかもしれません。
理想的な量は、必要に応じてデータベース全体をメモリに取り込むのに十分な RAM を持つことです。たとえば、4 GB のデータベースがある場合は、8 GB の RAM があることを確認してください。もちろん、x64 サーバーでは。
私はまったく逆の経験をしているのではないかと心配しています。ソース テーブルの行数がターゲット テーブルの何百万行にも満たない場合に、更新と挿入を実行していました。
運用ウィンドウ全体でソース テーブル レコードを結合し、MERGE を 1 回だけ実行したところ、パフォーマンスが 500% 向上しました。これについての私の説明は、タイトなループで何度も何度も MERGE コマンドを分析するのではなく、一度だけ前もって分析することにお金を払っているということです。
さらに、160 万行 (ソース) を 700 万行 (ターゲット) にマージすることは、4000 行を 700 万行にマージするのとは対照的に (私たちの場合)、4,000 の異なる操作で SQL サーバー エンジンの機能をはるかに活用できると確信しています。繰り返しますが、かなりの量の作業が 2 つのデータ セットの分析にあり、これは 1 回だけ行われます。
私が尋ねなければならないもう 1 つの質問は、MERGE コマンドがソース テーブルとターゲット テーブルの両方でインデックスを使用すると、はるかに優れたパフォーマンスを発揮することを認識しているかどうかです。次のリンクを参照していただければ幸いです。
http://msdn.microsoft.com/en-us/library/cc879317(v=SQL.100).aspx