為什麼我的 Amazon Redshift 查詢超過我設定的 WLM 逾時？

簡短說明

WLM 逾時僅適用於查詢執行階段內的查詢。如果 WLM 未在預期時間終止查詢，通常是因為查詢在執行階段以外的階段耗費了時間。例如，查詢可能會等待剖析或重寫、等待鎖定，或等待 WLM 佇列中的某個位置。或者，查詢可能會到達傳回階段或快速移動到其他佇列。

解決方法

查詢 STV_RECENTS 時，starttime 指的是查詢進入叢集的時間，而不是查詢開始執行的時間。當查詢在 STV_RECENTS 中處於執行中狀態時，它就是系統中的即時查詢。但是，在進入 STV_INFLIGHT 狀態之前，該查詢不會使用運算節點資源。如需查詢規劃的相關資訊，請參閱查詢規劃與執行工作流程。

若要檢視執行中查詢的狀態，請查詢 STV_INFLIGHT，而不是 STV_RECENTS：

select \* from STV\_INFLIGHT where query = your\_query\_id;

如需有關查詢階段的詳細資訊，請執行下列查詢：

select \* from SVL\_QUERY\_REPORT where query = your\_query\_id ORDER BY segment, step, slice;

使用 STV_EXEC_STATE 資料表來尋找運算節點上正在主動執行任何查詢的目前狀態：

select \* from STV\_EXEC\_STATE where query = your\_query\_id ORDER BY segment, step, slice;

以下是查詢執行時間長於 WLM 逾時期間的一些常見原因。

查詢處於「傳回」階段

有兩個「傳回」步驟。檢查 STV_EXEC_STATE，以查看查詢是否已進入下列其中一個傳回階段：

• 從運算節點傳回引導節點
• 從引導節點返回用戶端

正在進行回復

資料操作語言 (DML) 操作可能會遇到錯誤並回復。此操作可能不會顯示為「已停止」，因為它已在回復過程中。您可以查詢 STV_EXEC_STATE 以檢視回復，並在 STL_UNDONE 中尋找更多資訊。

查詢在執行之前需要一些時間才能排入佇列

查詢 STV_WLM_QUERY_STATE 以查看排入佇列時間：

select \* from STV\_WLM\_QUERY\_STATE where query = your\_query\_id;

查詢正在等待鎖定

如果查詢在 STV_RECENTS 中可見，但在 STV_WLM_QUERY_STATE 中不可見，則查詢可能正在等待鎖定，而且尚未進入佇列。如需詳細資訊，請參閱如何在 Amazon Redshift 中偵測和釋放鎖定？

查詢快速移動到另一個佇列

如果讀取查詢達到其目前 WLM 佇列的逾時限制，則該查詢會推送到下一個 WLM 佇列。或者，如果有指定躍點動作的查詢監控規則，則該查詢會推送到下一個 WLM 佇列。若要確認查詢是否快速移動到下一個佇列，請根據您的案例完成下列查詢：

• 如果查詢目前正在執行中，請查詢 STV_WLM_QUERY_STATE。
• 如果查詢已完成，請查詢 STL_WLM_QUERY

若要防止查詢快速移動到另一個佇列，請設定 WLM 佇列或 WLM 查詢監控規則。如需有關查詢快速移動的詳細資訊，請參閱 WLM 查詢佇列快速移動。

網路或防火牆問題

如果 Amazon Redshift 伺服器與用戶端通訊時發生問題，則伺服器可能會卡在「返回用戶端」狀態。檢查與網路元件是否有衝突，例如傳入內部部署防火牆設定、傳出安全群組規則或傳出網路存取控制清單 (network ACL) 規則。如需詳細資訊，請參閱從 Amazon EC2 外部連線 – 防火牆逾時問題。

叢集的問題

叢集本身的問題 (例如硬體問題) 可能會導致查詢凍結。當查詢因叢集問題而凍結時，叢集處於「硬體故障」狀態。若要復原單一節點叢集，請還原快照。在多節點叢集中，系統會自動取代故障的節點。

相關資訊

調校查詢效能

分析和改善查詢