執行長時間查詢 (例如 COPY 命令) 時，對資料庫的用戶端連線似乎懸置或逾時。在此情況下，您可能會發現 Amazon Redshift 主控台顯示查詢已完成，但用戶端工具本身仍似乎在執行查詢。取決於連線停止的時間，查詢的結果可能遺漏或不完整。當中繼網路元件終止閒置的連線時，會發生此影響。如需詳細資訊，請前往《Amazon Redshift 管理指南》中的防火牆逾時問題。

ODBC 發生用戶端 out-of-memory 錯誤

若您的用戶端應用程式使用 ODBC 連線，且您的查詢建立的結果集太大，無法納入記憶體中，則您可以使用資料指標將結果集串流到用戶端應用程式。如需詳細資訊，請參閱 DECLARE 及使用游標時的效能考量。

JDBC 發生用戶端 out-of-memory 錯誤

當您嘗試透過 JDBC 連線擷取大型結果集時，可能會遇到用戶端 out-of-memory 錯誤。如需詳細資訊，請參閱設定 JDBC 擷取大小參數。

可能有死鎖

如果有可能的死鎖，請嘗試下列：

檢視 STV_LOCKS 和 STL_TR_CONFLICT 系統資料表來尋找牽涉到對超過一個資料表進行更新的衝突。
使用 PG_CANCEL_BACKEND 函數來取消一或多個有衝突的查詢。
使用 PG_TERMINATE_BACKEND 函數來終止工作階段，它可強制終止的工作階段中任何目前執行中的交易釋出所有鎖定和復原交易。
排程並行寫入操作時務必謹慎。如需詳細資訊，請參閱管理並行寫入操作。

查詢耗費太長時間

您的查詢連線可能因下列原因而耗費太長時間；建議您使用下列故障排除方法。

資料表未進行優化

設定資料表的排序索引鍵、配送樣式和壓縮編碼，以善加利用平行處理。如需更多資訊，請參閱使用自動資料表最佳化

查詢正在寫入磁碟

您的查詢可能會在查詢執行的至少一部分寫入至磁碟。如需詳細資訊，請參閱改善查詢效能。

查詢必須等候其他查詢完成

您可以透過建立查詢佇列和指派不同類型的查詢至適當的佇列，來改善整體系統效能。如需詳細資訊，請參閱實作工作負載管理。

查詢未進行優化

分析解釋計畫以尋找重新寫入查詢或最佳化資料庫的機會。如需詳細資訊，請參閱查詢計劃。

查詢需要更多記憶體來執行

如果特定查詢需要更多記憶體，您可以透過增加wlm_query_slot_count來增加可用記憶體。

資料庫要求執行 VACUUM 命令

每當您新增、刪除或修改大量資料列時執行 VACUUM 命令，除非您以排序索引鍵順序載入您的資料。VACUUM 命令會重新組織您的資料以保有排序順序和還原效能。如需詳細資訊，請參閱清空資料表。

疑難排解長期執行查詢的其他資源

以下是有助於調整查詢的系統檢視主題和其他文件章節：

STV_INFLIGHT 系統檢視會顯示叢集上執行的查詢。將它與 STV_RECENTS 一起使用，以確定當前正在執行或最近完成的查詢會很有幫助。
SYS_QUERY_HISTORY對於疑難排解很有用。它顯示 DDL 和 DML 查詢以及相關屬性，例如其目前的狀態 (例如 running 或 failed)、每個查詢執行所花費的時間，以及查詢是否在並行擴展叢集上執行。
STL_QUERYTEXT 會擷取 SQL 命令的查詢文字。此外，將 STL_QUERYTEXT 聯結至 STV_INFLIGHT 的 SVV_QUERY_INFLIGHT，會顯示更多查詢中繼資料。
交易鎖定衝突可能是查詢效能問題的可能來源。如需目前在資料表上保留鎖定之交易的相關資訊，請參閱SVV_TRANSACTIONS。
識別最適合調整的查詢會提供疑難排解查詢，協助您判斷最近執行的查詢最耗時。這可以幫助您將精力集中在需要改進的查詢上。
如果您想要進一步探索查詢管理並瞭解如何管理查詢佇列，實作工作負載管理顯示如何執行此操作。工作負載管理是一項進階功能，我們建議您在大多數情況下自動化工作負載

載入失敗

您的資料載入可能因下列原因而失敗；建議您使用下列故障排除方法。

資料來源位於不同的 AWS 區域

根據預設，複製命令中指定的 Amazon S3 儲存貯體或 Amazon DynamoDB 表必須與叢集位於相同的 AWS 區域。如果您的資料和您的叢集位於不同的區域，您會收到類似以下的錯誤：


The bucket you are attempting to access must be addressed using the specified endpoint.

如果有可能，請確定您的叢集和您的資料來源位於相同區域。您可以使用 REGION 選項搭配 COPY 命令來指定不同的區域。

注意

如果叢集和資料來源位於不同的 AWS 區域，則會產生資料傳輸費用。您的延遲也會更高。

COPY 命令失敗

查詢 STL_LOAD_ERRORS 以探索特定載入期間發生的錯誤。如需詳細資訊，請參閱 STL_LOAD_ERRORS。

載入耗費太長時間

您的載入操作可能因下列原因而耗費太長時間；建議您使用下列故障排除方法。

從單一檔案 COPY 載入資料

將您的載入資料分割至多個檔案。當您從多個檔案載入所有資料時，Amazon Redshift 將被迫執行序列化載入，其速度非常慢。檔案的數量應該是您的叢集中配量數量的倍數，而檔案應該是大約相等的大小，壓縮後介於 1 MB 與 1 GB 之間。如需詳細資訊，請參閱設計查詢的 Amazon Redshift 最佳實務。

載入操作使用多個 COPY 命令

如果您同時使用多個 COPY 命令從多個檔案載入一個資料表，Amazon Redshift 將被迫執行序列化載入，其速度非常慢。在此情況下，請使用單一 COPY 命令。

載入資料不正確

您的 COPY 操作可能以下列方式載入不正確的資料；建議您使用下列故障排除方法。

載入錯誤的檔案

使用物件字首來指定資料檔案可能導致讀取不需要的檔案。相反地，請使用資訊清單檔案來指定要載入的確切檔案。如需詳細資訊，請參閱 COPY 命令的 copy_from_s3_manifest_file 選項和 COPY 範例中的 Example: COPY from Amazon S3 using a manifest。

設定 JDBC 擷取大小參數

依預設，JDBC 驅動程式會一次收集查詢的所有結果。因此，當您嘗試透過 JDBC 連線擷取大型結果集時，可能會遇到用戶端 out-of-memory 錯誤。若要讓用戶端能夠以批次方式擷取結果集，而非單一 all-or-nothing 擷取，請在用戶端應用程式中設定 JDBC fetch size 參數。

注意

ODBC 不支援擷取大小。

為求最佳效能，請將擷取大小設定為不會導致記憶體不足錯誤的最高值。較低的擷取大小值會造成更多伺服器來回行程，進而延長執行時間。伺服器會預留資源，包括 WLM 查詢位置和關聯的記憶體，直到用戶端擷取整個結果集或查詢取消為止。適當地調校擷取大小時，那些資源會更快速釋出，使得它們可供其他查詢使用。

注意

如果您需要擷取大型資料集，建議您使用 UNLOAD 陳述式將資料傳輸到 Amazon S3。使用 UNLOAD 時，運算節點會平行運作，以加速資料的傳輸。

如需設定 JDBC 擷取大小參數的相關資訊，請前往 PostgreSQL 文件中的根據游標取得結果。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

診斷查詢以進行查詢調校

實作工作負載管理