為什麼我的 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 佇列。若要確認查詢是否快速移動到下一個佇列，請執行下列動作：

• **正在執行查詢時：**查詢 STV_WLM_QUERY_STATE
• **查詢執行後：**查詢 STL_WLM_QUERY

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

網路或防火牆問題

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

叢集的問題

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

---

相關資訊

調校查詢效能

分析和改善查詢