Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# WLM 動態和靜態組態屬性
WLM 屬性分為動態和靜態兩種。您可在不重新啟動叢集的情形下，將動態屬性套用至資料庫，但靜態屬性需要重新啟動叢集才能讓變更生效。但假如您同時變更了動態與靜態屬性，則必須重新啟動叢集，所有屬性變更才會生效。無論變更的屬性是動態或是靜態，都是如此。
套用動態屬性時，叢集狀態為 `modifying`。在自動 WLM 與手動 WLM 之間切換為靜態變更，需叢集重新啟動以生效。
下表指出使用自動 WLM 或手動 WLM 時，哪些 WLM 屬性是動態的，哪些是靜態的。
****
| WLM 屬性 | 自動 WLM | 手動 WLM |
| --- | --- | --- |
| 查詢群組 | 動態 | 靜態 |
| 查詢群組萬用字元 | 動態 | 靜態 |
| 使用者群組 | 動態 | 靜態 |
| 使用者群組萬用字元 | 動態 | 靜態 |
| 使用者角色 | 動態 | 靜態 |
| 使用者角色萬用字元 | 動態 | 靜態 |
| 主要叢集的並行 | 不適用 | 動態 |
| 並行擴展模式 | 動態 | 動態 |
| 啟用短期查詢加速 | 不適用 | 動態 |
| 短期查詢最長執行時間 | 動態 | 動態 |
| 要使用的記憶體百分比 | 不適用 | 動態 |
| Timeout (逾時) | 不適用 | 動態 |
| Priority | 動態 | 不適用 |
| 新增或移除佇列 | 動態 | 靜態 |
如果您新增查詢監控規則 (QMR)，或是修改或刪除現有 QMR，則變更會自動生效，而不需要重新啟動叢集。
**注意**
使用手動 WLM 時，如果變更逾時值，新值將套用至變更值之後才開始執行的任何查詢。如果變更要使用的記憶體並行或百分比，Amazon Redshift 將動態變更至新組態。如此，目前執行中的查詢將不會受變更影響。如需詳細資訊，請參閱 [WLM 動態記憶體配置](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html)。
**Topics**
+ [WLM 動態記憶體配置](cm-c-wlm-dynamic-memory-allocation.md)
+ [動態 WLM 範例](cm-c-wlm-dynamic-example.md)
# WLM 動態記憶體配置
在每一個佇列中，WLM 會建立一些適合佇列並行層級的查詢槽。配置給查詢槽的記憶體數量等於配置給佇列的記憶體百分比除以槽計數。如果您變更記憶體配置或並行，Amazon Redshift 會動態設法轉移至新的 WLM 組態。因此，作用中查詢可以使用目前配置的記憶體數量，執行到完成為止。同時，Amazon Redshift 會確保記憶體總用量絕不超過 100% 可用的記憶體。
工作負載管理員使用下列程序來管理轉移：
1. WLM 會重新計算每個新查詢槽的記憶體配置。
1. 如果執行中的查詢並沒有主動使用某個查詢槽，WLM 會移除此槽，而該記憶體就可以給新的槽使用。
1. 如果查詢槽目前在使用中，WLM 會等待查詢完成。
1. 當作用中查詢完成時，就會移除空的槽，並釋放相關的記憶體。
1. 只要有足夠的記憶體可供新增一或多個槽，就會新增新的槽。
1. 當變更時執行的所有查詢都完成時，槽計數就等於新的並行層級，而轉移至新的 WLM 組態也就完成。
事實上，變更生效時正在執行的查詢會繼續使用原始的記憶體配置。變更生效時已排入佇列的查詢會在有新的槽可用時，路由傳送至新的槽。
如果 WLM 動態屬性在轉移過程中變更，WLM 會從目前狀態開始，立即開始轉移至新的組態。若要檢視轉移的狀態，請查詢 [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md) 系統資料表。
# 動態 WLM 範例
透過 Amazon Redshift 即可使用動態 WLM (工作負載管理) 來自動管理 Amazon Redshift 叢集中的工作負載分佈和資源配置。動態 WLM 是工作負載管理 (WLM) 組態的範例，其根據工作負載需求動態調整記憶體配置，藉此實現最佳並行和效能。下節提供實作和設定 Amazon Redshift 叢集的動態 WLM 的詳細資訊。
假設您的叢集 WLM 使用下列動態屬性設定兩個佇列。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
現在，假設您的叢集有 200 GB 的記憶體可供查詢處理使用。(此為任意數字，僅供示範用途。) 如下列方程式所示，每個槽配置 25 GB。
```
(200 GB * 50% ) / 4 slots = 25 GB
```
接下來，您將 WLM 變更為使用下列動態屬性。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
如下列方程式所示，佇列 1 中每個槽的新記憶體配置為 50 GB。
```
(200 GB * 75% ) / 3 slots = 50 GB
```
假設套用新組態時，查詢 A1、A2、A3 和 A4 在執行中，而查詢 B1、B2、B3 和 B4 會排入佇列。WLM 會動態重新設定查詢槽，如下所示。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
1. WLM 會重新計算每個查詢槽的記憶體配置。佇列 1 最初配置 100 GB。新的佇列總共配置 150 GB，所以新佇列立即有 50 GB 可用。佇列 1 現在使用四個槽，且新的並行層級是三個槽，所以不會新增任何槽。
1. 當一個查詢完成，就會移除槽並釋出 25 GB。佇列 1 現在有三個槽和 75 GB 的可用記憶體。新的組態規定每個新的槽要有 50 GB，但新的並行層級是三個槽，所以不會新增任何槽。
1. 當第二個查詢完成，就會移除槽並釋出 25 GB。佇列 1 現在有兩個槽和 100 GB 的可用記憶體。
1. 使用 50 GB 的可用記憶體新增一個槽。佇列 1 現在有三個槽和 50 GB 的可用記憶體。排入佇列的查詢現在可以路由至新的槽。
1. 當第三個查詢完成，就會移除槽並釋出 25 GB。佇列 1 現在有兩個槽和 75 GB 的可用記憶體。
1. 使用 50 GB 的可用記憶體新增一個槽。佇列 1 現在有三個槽和 25 GB 的可用記憶體。排入佇列的查詢現在可以路由至新的槽。
1. 當第四個查詢完成，就會移除槽並釋出 25 GB。佇列 1 現在有兩個槽和 50 GB 的可用記憶體。
1. 使用 50 GB 的可用記憶體新增一個槽。佇列 1 現在有三個槽，各有 50 GB，所有可用的記憶體都已配置。
轉移完成，所有查詢槽都可供排入佇列的查詢使用。