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/)。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Redshift 中的隔離層級
<a name="c_serial_isolation"></a>

Amazon Redshift 中是使用資料表上的寫入鎖定及*可序列化隔離*的原則，以保護的方式支援並行寫入操作。可序列化隔離可維持對資料表執行的交易對該資料表執行的唯一交易的錯覺。

Amazon Redshift 資料庫支援並行寫入操作，方法是讓每個操作在交易開始時使用其資料的最新認可版本或快照。資料庫快照會在多數 SELECT 陳述式、DML 命令 (例如 COPY、DELETE、INSERT、UPDATE 和 TRUNCATE)，以及下列 DDL 命令的第一個出現的交易內建立：
+  ALTER TABLE (用來新增或捨棄資料欄) 
+  CREATE TABLE 
+  DROP TABLE 
+  TRUNCATE TABLE 

其他交易無法變更此快照，這表示交易會彼此隔離。也就是說，並行交易彼此看不見對方，也無法偵測到彼此的變更。

任何並行執行交易產生的結果，都必須與依序執行這些交易產生的結果相同。如果這些交易中沒有任何序列執行會產生相同的結果，系統會停止和還原所執行陳述式可能破壞序列化可行性的交易。

例如，假設使用者嘗試執行兩項並行交易：T1 和 T2。執行 T1 和 T2 必須產生相同的結果，至少須符合下列其中一個案例：
+ T1 和 T2 會依照該順序循序執行。
+ T2 和 T1 會依照該順序循序執行。

 Amazon Redshift 中的隔離層級可防止下列問題：
+  已變更讀取 - 當交易讀取尚未認可的資料時，便會發生已變更讀取。例如，假設交易 1 更新一列。交易 2 在 T1 認可更新之前讀取更新的列。如果 T1 復原變更，則 T2 將擁有未認可列中的讀取資料，而 Amazon Redshift 現在將這些資料視為未曾存在。
+  不可重複讀取 - 當單一交易讀取同一列兩次，但倆次得到不同的資料時，便會發生不可重複讀取。例如，假設交易 1 讀取一列。交易 2 更新或刪除該列，並認可更新或刪除。如果 T1 重新讀取該列，則會擷取不同的列值或發現該列已刪除。
+  幽靈 - 幽靈是符合搜尋條件但一開始未看見的列。例如，假設交易 1 讀取一組符合其搜尋條件的列。交易 2 在 UPDATE 或 INSERT 陳述式中產生符合 T1 搜尋條件的新列。如果 T1 重新執行其搜尋陳述式，則會取得一組不同的列。

## SNAPSHOT 和 SERIALIZABLE 隔離
<a name="c_serial_isolation-snapshot_and_serializable"></a>

SERIALIZABLE 和 SNAPSHOT 隔離都是 Amazon Redshift 中提供的可序列化隔離層級。

SNAPSHOT 隔離是建立佈建叢集和無伺服器工作群組時的預設隔離層級，可讓您花較短的時間處理比 SERIALIZABLE 隔離更大的資料量。

SERIALIZABLE 隔離須花較多時間，但對並行交易實施更嚴格的限制。此隔離層級僅允許認可一項交易，同時取消所有其他具有可序列化隔離違規錯誤的並行交易，藉此防止寫入偏斜異常等問題。

以下是使用 SNAPSHOT 隔離時，如何處理兩個並行寫入操作的時間軸範例。允許認可使用者的每個 UPDATE 陳述式，因為其不會嘗試更新相同的列而發生衝突。


| 時間  | 使用者 1 動作  | 使用者 2 動作  | 
| --- | --- | --- | 
| 1 | BEGIN; |  | 
| 2 |  | BEGIN; | 
| 3 | SELECT \* FROM Numbers;

```
digits
------
0
1
``` |  | 
| 4 |  | SELECT \* FROM Numbers;

```
digits
------
0
1
``` | 
| 5 | UPDATE Numbers SET digits=0 WHERE digits=1; |  | 
| 6 | SELECT \* FROM Numbers;

```
digits
------
0
0
``` |  | 
| 7 | COMMIT; |  | 
| 8 |  | Update Numbers SET digits=1 WHERE digits=0; | 
| 9 |  | SELECT \* FROM Numbers;

```
digits
------
1
1
``` | 
| 10 |  | COMMIT; | 
| 11 | SELECT \* FROM Numbers;

```
digits
------
1
0
``` |  | 
| 12 |  | SELECT \* FROM Numbers;

```
digits
------
1
0
``` | 

如果使用可序列化隔離執行相同的案例，Amazon Redshift 會因為可序列化違規而終止使用者 2，並傳回錯誤 `1023`。如需詳細資訊，請參閱[對可序列化隔離錯誤進行故障診斷](c_serial_isolation-serializable-isolation-troubleshooting.md)。在這種情況下，只有使用者 1 可以成功提交。

## 考量事項
<a name="c_serial_isolation-considerations"></a>

使用 Amazon Redshift 中的隔離層級時，請考量下列事項：
+  查詢 STV\_DB\_ISOLATION\_LEVEL 目錄檢視，以檢視資料庫使用的隔離層級。如需詳細資訊，請參閱[STV\_DB\_ISOLATION\_LEVEL](r_STV_DB_ISOLATION_LEVEL.md)。
+  查詢 PG\_DATABASE\_INFO 檢視，以查看您的資料庫支援多少個並行交易。如需詳細資訊，請參閱[PG\_DATABASE\_INFO](r_PG_DATABASE_INFO.md)。
+  系統目錄資料表 (PG) 和其他 Amazon Redshift 系統資料表不會在交易中鎖定。因此，DDL 和 TRUNCATE 操作所產生的資料庫物件變更，都會在認可至任何並行交易時顯示出來。

   例如，假設當兩個並行交易 T1 和 T2 開始時，資料表 A 存在於資料庫。假設 T2 從 PG\_TABLES 目錄資料表中進行選取，傳回了資料表清單。然後 T1 捨棄資料表 A 並遞交，然後 T2 再次列出資料表。資料表 A 現在不會再出現在清單中。如果 T2 嘗試查詢已捨棄的資料表，Amazon Redshift 會傳回「關聯不存在」錯誤。傳回資料表的清單至 T2 或檢查資料表 A 存在的類別查詢，不會受限於與對使用者資料表執行的相同隔離規則。

   對這些資料表更新的交易會在讀取已認可隔離模式中執行。
+  PG 字首目錄資料表不支援 SNAPSHOT 隔離。