適用於：Azure Synapse Analytics
在專用 SQL 集區上，tempdb 資料庫會用於臨時表和數據移動的中繼空間（例如：隨機移動、修剪移動）、排序、載入、記憶體溢出和其他作業。 此外，與 tempdb 資料庫互動的一個會話中未認可的交易，會防止記錄檔排清所有其他會話，導致記錄檔填滿。 因為 tempdb 資料庫是共用資源，因此大量耗用 tempdb 空間可能會導致其他使用者的查詢失敗，而且可能會呈報以防止建立新的連線。
如果我無法連線到專用 SQL 集區，該怎麼辦？
如果您沒有現有連線來識別任何有問題的連線或查詢，則解決無法建立新連線 的唯一方法是暫停 和 繼續，或 調整 專用 SQL 集區。 此動作將會終止導致此問題的使用者交易，並在服務重新啟動時重新建立tempdb資料庫。
注意： 請務必為服務提供額外的時間來復原所有執行中的交易，因為暫停和調整作業可能需要比正常時間更久才能完成此案例。
針對完整的tempdb資料檔進行疑難解答
步驟 1：識別填滿 tempdb 資料庫的查詢
除非您已將記錄元件實作到 ETL 架構或稽核專用 SQL 集區語句，否則請確定您在執行查詢時，識別填滿 tempdb 資料庫的查詢。 在大部分情況下，不一定是發生問題的時間範圍內執行最長的查詢，是tempdb空間不足錯誤的原因。 執行下列查詢以取得長時間執行的查詢清單：
SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;
一旦您有相當可疑的查詢，請嘗試下列其中一個選項：
- 終止 語句。
- 嘗試防止任何其他工作負載進一步取用tempdb空間，讓長跑者可以完成。
步驟 2：防止週期性
識別並針對負責任查詢採取動作之後，請考慮實作風險降低措施，以防止問題週期性發生。 下表顯示 tempdb 完整錯誤最常見原因的風險降低：
| 原因 | 描述 | 降低 |
|---|---|---|
| 分散式方案不佳 | 針對指定查詢產生的分散式計劃，可能會因為數據表統計數據維護不佳而意外地導入高頻率數據移動。 | 更新相關數據表的統計數據 ，並確保它們會定期維護。 |
| 叢集資料行存放區索引 (CCI) 健康情況不佳 | 它會因為記憶體溢出而耗用tempdb空間。 | 重建CCI ，並確保其會定期維護。 |
| 大型交易 | CREATE TABLE AS SELECT (CTAS)大量的或 INSERT SELECT 語句會在數據移動作業期間填滿 tempdb。 |
將您的 CTAS 或 INSERT SELECT 陳述式細分為多個較小的交易。 |
| 記憶體配置不足 | 設定記憶體不足的查詢（透過資源類別或工作負載群組）可能會溢出到 tempdb。 |
使用較大的資源類別或具有更多資源的工作負載群組來執行查詢。 |
| 終端使用者外部資料表查詢 | 對外部數據表的查詢對於用戶查詢而言並非最佳，因為引擎必須先將整個檔案讀入 tempdb ，才能處理數據。 |
載入資料至永久資料表，然後將使用者查詢導向至該處。 |
| 整體資源不足 | 您可能會發現專用 SQL 集區在高活動期間接近其 tempdb 容量上限。 | 請考慮將專用 SQL 集區相應增加，並結合上述任何風險降低措施。 |
針對完整的tempdb事務歷史記錄檔進行疑難解答
tempdb 事務歷史記錄通常只會在用戶端/使用者時填滿：
- 開啟明確的交易，但絕不會發出
COMMIT或ROLLBACK。 - 設定
IMPLICIT_TRANSACTION = ON（特別是針對使用 AutoCommit 功能的 JDBC 用戶端和工具）。
步驟 1：識別開啟的交易
有問題的連線可能是來自具有開啟交易但處於「閑置」狀態的用戶端。 執行下列查詢以協助識別此案例：
SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';
注意：並非所有因為此查詢而傳回的連接都一定有問題。 在執行之間至少執行兩次，且執行時間超過15分鐘，並查看哪些聯機會持續處於此狀態。
步驟 2：減輕並防止問題
識別要持有開啟交易的客戶端之後，請與使用者合作以變更其中一項或兩者：
- 驅動程式組態 （例如：JDBC AutoCommit 設定為
off，這會設定IMPLICIT_TRANSACTIONS = ON） - 臨機操作查詢行為（例如：未正確執行
BEGIN TRANCOMMIT/ROLLBACK）
或者，您可以考慮建立自動化程式來定期偵測此案例，並 終止 任何潛在的問題會話。
資源
- 查詢 DMV sys.dm_pdw_errors 以尋找錯誤。