LATCH_EX 等待資源 METADATA_SEQUENCE_GENERATOR
我們有一個生成庫存報告的流程。在客戶端，程序拆分可配置數量的工作執行緒，為報告建構一大塊數據，該數據對應於許多儲存中的一個（可能是數千個，通常是幾十個）。每個工作執行緒呼叫一個執行儲存過程的 Web 服務。
處理每個塊的數據庫程序將一堆數據收集到#Temporary 表中。在每個處理塊結束時，將數據寫入 tempdb 中的永久表。最後，在程序結束時，客戶端的一個執行緒從永久 tempdb 表中請求所有數據。
執行此報告的使用者越多，它的速度就越慢。我分析了數據庫中的活動。在某一時刻，我看到 35 個單獨的請求都在程序中的某一時刻被阻塞。
LATCH_EX所有這些 SPID在資源上都有大約 50 毫秒的等待類型METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)。一個 SPID 擁有此資源，而所有其他 SPID 都處於阻塞狀態。我在網路搜尋中沒有找到有關此等待資源的任何資訊。我們正在使用的 tempdb 中的表確實有一
IDENTITY(1,1)列。這些 SPID 是否在等待 IDENTITY 列？我們可以使用哪些方法來減少或消除阻塞？伺服器是集群的一部分。伺服器在 64 位 Windows 2008 R2 Enterprise 上執行 64 位 SQL Server 2012 Standard Edition SP1。伺服器有 64 GB RAM 和 48 個處理器，但數據庫只能使用 16 個，因為它是標準版。
（請注意，我對在 tempdb 中使用永久表來保存所有這些數據的設計並不感到興奮。改變這將是一個有趣的技術和政治挑戰，但我願意接受建議。）
2013 年 4 月 23 日更新
我們已經與 Microsoft 建立了支持案例。隨著我們了解更多資訊，我會不斷更新這個問題。
2013 年 5 月 10 日更新
SQL Server 支持工程師同意等待是由 IDENTITY 列引起的。刪除 IDENTITY 消除了等待。我們無法在 SQL 2008 R2 上複製該問題；它只發生在 SQL 2012 上。
假設您可以將問題隔離到標識值的生成（嘗試刪除該列作為測試），我建議這樣做：
IDENTITY從最終表格的列中刪除屬性。- 在每個 #Temporary 表中生成標識值。
- 載入最終表時，將特定商店的數字標識符與步驟 2 中的標識值結合起來。
因此，如果您有商店 id 3 和 4，您最終會得到如下的最終 id 值：
3000000001 3000000002 3000000003 ... 4000000001 4000000002 ...或者類似的東西。你明白了。
這將消除
IDENTITY生成序列化的需要，同時保留最終結果的唯一性。或者，根據流程的工作方式，將最終計算出的 id 值插入到 #Temporary 表中。然後，您可以創建一個將
UNION ALL它們組合在一起的視圖，完全無需複制數據。