MERGE INTO 広告掲載オーダー

何もならないので、質問者がここで何を求めているかについて話すことはできません

別の問題を想定してみましょう:

代わりに、Identity-Field のない Heap-Table がありますが、"Visited " 日付フィールド。
Heap-Table は Person WebPage Visits をログに記録し、それをデータウェアハウスにロードしています。
このデータウェアハウスでは、Surrogate-Key "WebHitID を使用したいと考えています。
Merge を使用してテーブルの初期ロードを行い、それから呼び出しを続けてテーブルの同期を維持しましょう。

レコードを挿入していれば、次に、ID (Identify-Field によって生成される) が、選択した Order-By に基づいて連続することを望みます (「Visited としましょう」
テーブル内の残りのレコードと比較して、整数 ID がいつ作成されたかに関連付けられることを期待することは珍しくありません。
これが常に 100% 当てはまるとは限らないことはわかっています。、しかしちょっとユーモアを交えて。

これは Merge で可能です。

使用 (ハックのように感じるもの) ) TOP は、挿入での並べ替えを可能にします:

MERGE DW.dbo.WebHit AS Target --This table as an Identity Field called WebHitID.
USING
(
    SELECT TOP 9223372036854775807 --Biggest BigInt (to be safe).
           PWV.PersonID, PWV.WebPageID, PWV.Visited
      FROM ProdDB.dbo.Person_WebPage_Visit AS PWV
     ORDER BY PWV.Visited --Works only with TOP when inside a MERGE statement.
) AS Source
  ON Source.PersonID  = Target.PersonID
 AND Source.WebPageID = Target.WebPageID
 AND Source.Visited   = Target.Visited
WHEN NOT MATCHED BY Target THEN --Not in Target-Table, but in Source-Table.
    INSERT (PersonID, WebPageID, Visited) --This Insert populates our WebHitID.
    VALUES (Source.PersonID, Source.WebPageID, Source.Visited)
WHEN NOT MATCHED BY Source THEN --In Target-Table, but not in Source-Table.
    DELETE --In case our WebHit log in Prod is archived/trimmed to save space.
;
  
 
TOP 9223372036854775807 (存在する最大の整数) を使用してすべてをプルしたことがわかります。
それ以上をマージするリソースがある場合は、チャンクアウトする必要があります。
これは「ハッキーな回避策」と叫びますが、  

小さなサンプル セットでこれをテストし、動作することを確認しました。より大規模な複雑なセットでのパフォーマンスへの影響については調査していません。ただし、データなので、TOP の有無にかかわらず YMMV です。