交易

此頁面上的命令檔內容僅適用於瀏覽用途，而且無法利用任何方式來更改內容。

本章定義異動，並描述資料庫如何處理異動。

交易簡介

交易是包含一或多個 SQL 敘述句的邏輯、單元工作。

交易會將 SQL 敘述句分組，讓它們全部確認，這表示它們會套用至資料庫，或全部倒回，這表示它們是從資料庫還原的。Oracle AI Database 為每筆交易指派一個稱為交易 ID 的唯一識別碼。

所有 Oracle 交易都會遵循資料庫交易的基本特性 (稱為 ACID 特性 )。「ACID」是以下列縮寫詞為首字母：

交易的使用是資料庫管理系統與檔案系統不同的最重要方式之一。

樣品交易：帳戶借方與貸方

為了說明交易的概念，請考慮銀行業務資料庫。

當客戶將金額從儲蓄帳戶轉帳至支票帳戶時，交易必須由三個不同的作業組成：

Oracle AI Database 必須允許兩種情況。如果這三個 SQL 陳述式都維持帳戶的正確餘額，則交易的影響可以套用至資料庫。不過，如果資金不足、帳號無效或硬體故障等問題導致交易中一或兩個對帳單無法完成，則資料庫必須回復整個交易，以便所有帳戶的餘額都正確無誤。

下圖說明銀行業務交易。第一張對帳單從儲蓄帳戶 3209 中減去 $500。第二張對帳單將 $500 加到支票帳戶 3208。第三個報表會將拋轉的記錄插入分錄表格中。最後一個敘述句會確認交易。

圖 1：銀行交易

cncpt025.gif 圖解描述

交易的結構

資料庫交易是由一或多個敘述句所組成。

具體而言，交易包含下列其中一項：

交易具有開始與結束。

另請參閱：

交易的開端

當遇到第一個可執行 SQL 敘述句時，就會開始交易。

可執行 SQL 敘述句是一個 SQL 敘述句，可產生對資料庫執行處理的呼叫，包括 DML 和 DDL 敘述句以及 SET TRANSACTION 敘述句。

交易開始時，Oracle AI Database 會將交易指定給可用的還原資料區段，以記錄新交易的還原項目。直到在第一個 DML 敘述句期間配置還原區段與交易表格槽位之後，才會配置交易 ID。交易 ID 是唯一的，它代表還原區段編號、槽位以及序號。

下列範例會執行 UPDATE 敘述句以開始交易，並查詢 V$TRANSACTION 以取得交易的相關詳細資訊：

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
  2  XIDSQN AS "seq", STATUS AS "txn status"
  3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

另請參閱：「還原區段」

交易結束

交易可能會在不同情況下結束。

交易會在發生下列任一動作時結束：

當一個交易結束後，下一個可執行 SQL 敘述句會自動啟動下列交易。下列範例會執行 UPDATE 來啟動交易，以 ROLLBACK 敘述句結束交易，然後執行 UPDATE 來啟動新的交易 (請注意，交易 ID 不同)：

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

另請參閱：

敘述句層次原子性

Oracle AI Database 支援陳述式層級的原子性，這表示 SQL 陳述式是工作單元，可完全成功或完全失敗。

成功的敘述句與確認的交易不同。如果資料庫在多資料列更新中變更所有資料列時，沒有錯誤作為單元單位，則單一 SQL 敘述句會順利執行。

如果 SQL 敘述句在執行期間造成錯誤，則不會成功，因此會倒回敘述句的所有效果。此作業是敘述句層次倒回。此作業具有下列特性：

造成敘述句層次倒回的錯誤範例就是嘗試插入重複的主索引鍵。死鎖中與相同資料競爭的單一 SQL 敘述句，也可能造成敘述句層次倒回。不過，在 SQL 敘述句剖析期間發現的錯誤 (例如語法錯誤) 尚未執行，所以不會導致敘述句層次倒回。

另請參閱：

系統變更號碼 (SCN)

系統變更編號 (SCN) 是 Oracle AI Database 所使用的邏輯內部時戳。

資料庫中發生的 SCN 順序事件，必須滿足交易的 ACID 特性。Oracle AI Database 使用 SCN 將 SCN 標示為已知在磁碟上進行的所有變更，以避免套用不必要的重做。資料庫也使用 SCN 標記一組資料沒有重做存在的時間點，讓復原可以停止。

SCN 是以單調遞增順序進行。Oracle AI Database 可以像時鐘一樣使用 SCN，因為觀察到的 SCN 表示邏輯時間點，而重複的監測傳回等於或大於值。如果某個事件的 SCN 低於另一個事件，則該事件會在稍早的資料庫中發生。數個事件可能會共用相同的 SCN，這表示它們在資料庫中同時發生。

每筆交易都有 SCN。例如，如果交易更新一列，則資料庫會記錄發生此更新的 SCN。此交易中的其他修改具有相同的 SCN。當交易確認時，資料庫會記錄此確認的 SCN。

Oracle AI Database 會在系統全域區域 (SGA) 中增加 SCN。當交易修改資料時，資料庫會將新的 SCN 寫入至指派給交易的還原資料區段。日誌寫入器處理作業接著會將交易的確認記錄立即寫入線上重做日誌。確認記錄具有交易的唯一 SCN。Oracle AI Database 也使用 SCN 作為其執行處理復原和媒體復原機制的一部分。

另請參閱：「執行處理復原簡介」

交易控制概要

交易控制是由 DML 敘述句所做的變更，並將 DML 敘述句群組成交易。

一般而言，應用程式設計人員會考量交易控制，以便以邏輯單位完成工作，且資料保持一致。

交易控制涉及使用下列陳述式，如交易控制陳述式中所述：

表 13-1 中的階段作業說明交易控制的基本概念。

表格 1 交易控制

T 階段作業 說明
t0 
COMMIT;
 此敘述句會結束階段作業中的任何現有交易。
t1 
SET TRANSACTION NAME 'sal_update';
 此敘述句會開始一個交易，並將它命名為 sal_update。
t2 
UPDATE employees
 SET salary = 7000
  WHERE last_name = 'Banda';
 此報表會將 Banda 的薪資更新為 7000。
t3 
SAVEPOINT after_banda_sal;
 此敘述句會建立一個名為 after_banda_sal 的儲存點，讓此交易中的變更可以倒回至此點。
t4 
UPDATE employees
 SET salary = 12000
  WHERE last_name = 'Greene';
 此報表會將 Greene 的薪資更新為 12000。
t5 
SAVEPOINT after_greene_sal;
 此敘述句會建立一個名為 after_greene_sal 的儲存點，讓此交易中的變更可以倒回至此點。
t6 
ROLLBACK TO SAVEPOINT
 after_banda_sal;
 此陳述式會將交易回復至 t3，還原 Greene 在 t4 的薪資更新。sal_update 交易未結束。
t7 
UPDATE employees
 SET salary = 11000
  WHERE last_name = 'Greene';
 此報表會將交易 sal_update 中的 Greene 薪資更新為 11000。
t8 
ROLLBACK;
 此敘述句會倒回交易 sal_update 中的所有變更，並結束交易。
t9 
SET TRANSACTION NAME 'sal_update2';
 此敘述句會在階段作業中開始新的交易，並將它命名為 sal_update2。
t10 
UPDATE employees
 SET salary = 7050
  WHERE last_name = 'Banda';
 此報表會將 Banda 的薪資更新為 7050。
t11 
UPDATE employees
 SET salary = 10950
  WHERE last_name = 'Greene';
 此報表會將 Greene 的薪資更新為 10950。
t12 
COMMIT;
 此敘述句會確認交易 sal_update2 中所做的所有變更，並結束交易。確認可確保變更會儲存在線上重做日誌檔中。

異動名稱

交易名稱是使用者指定的選擇性標記，可作為交易執行工作的提醒。您可以使用 SET TRANSACTION ... NAME 敘述句來命名交易，如果使用，則必須是交易的第一個敘述句。

在表格 13-1 中，第一個交易的名稱是 sal_update，第二個交易的名稱是 sal_update2。

交易名稱提供下列優點：

另請參閱：

作用中交易

作用中交易是已啟動但尚未確認或倒回的交易。

在表格 13-1 中，修改 sal_update 交易中資料的第一個敘述句是 Banda 薪資的更新。從此更新的成功執行到 ROLLBACK 敘述句結束交易為止，sal_update 交易為作用中。

交易所做的資料變更是暫時變更，直到確認或倒回交易為止。交易結束之前，資料的狀態如下表所示。

表格 2 交易結束前的資料狀態

州別 說明 深入瞭解
Oracle AI Database 已在 SGA 中產生還原資訊。 還原資料包含由交易的 SQL 敘述句變更的舊資料值。 「讀取已確認隔離層級中的一致性」
Oracle AI Database 已在 SGA 的線上重做日誌緩衝區中產生重做。 重做日誌記錄包含對資料區塊的變更，以及對還原區塊的變更。 重做日誌緩衝區
已對 SGA 的資料庫緩衝區進行變更。 資料庫寫入器 (DBW) 不一定會立即將已確認交易的資料變更 (儲存在 SGA 的資料庫緩衝區中) 寫入資料檔。磁碟寫入可以在確認之前或之後進行。 資料庫緩衝區快取
受資料變更影響的資料列會被鎖定。 其他使用者則無法變更受影響資料列中的資料，也無法看到未確認的變更。 「鎖定行為摘要」

儲存點

儲存點是使用者宣告的交易相關資訊環境中的中間標記。

儲存點標記會在內部解析為 SCN。儲存點會將長期交易分為較小的部分。

如果您在長期交易中使用儲存點，則可以選擇稍後在交易的目前點之前執行倒回工作，但在交易內的宣告儲存點之後執行。因此，若您發生錯誤，您不需要重新提交每個陳述式。表格 13-1 會建立儲存點 after_banda_sal，以便將 Greene 薪資的更新回復至此儲存點。

倒回至儲存點

倒回至未確認交易中的儲存點表示還原在指定儲存點之後所做的任何變更，但這並不表示倒回交易本身。

當交易倒回至儲存點時，如在表格 13-1 中執行 ROLLBACK TO SAVEPOINT after_banda_sal 時，會發生下列情況：

  1. Oracle AI Database 只會倒回在儲存點之後執行的敘述句。

    在表格 13-1 中，ROLLBACK TO SAVEPOINT 會倒回 Greene 的 UPDATE，但不會倒回 Banda 的 UPDATE。

  2. Oracle AI Database 會保留 ROLLBACK TO SAVEPOINT 陳述式中指定的儲存點，但所有後續儲存點都會遺失。

    在表格 13-1 中，ROLLBACK TO SAVEPOINT 會導致 after_greene_sal 儲存點遺失。

  3. Oracle AI Database 會釋出在指定的儲存點之後取得的所有表格和資料列鎖定，但保留在儲存點之前取得的所有資料鎖定。

交易仍然有效，可以繼續。

另請參閱：

已排入佇列的交易

視情況而定，在倒回至儲存點之後，仍可能會封鎖等待先前鎖定資源的交易。

當某個交易被另一個交易封鎖時，它會在阻隔交易本身排入佇列，因此整個阻隔交易必須確認或倒回，才能繼續被阻隔的交易。

在下表顯示的案例中，階段作業 1 會倒回在執行 DML 敘述句之前建立的儲存點。不過，階段作業 2 仍會被阻隔，因為它正在等待階段作業 1 交易完成。

表格 3 倒回至儲存點範例

T 階段作業 1 階段作業 2 階段作業 3 說明
t0 
UPDATE employees
  SET salary=7000
  WHERE last_name=
  'Banda';
     梯次 1 開始一項異動。階段作業會將專用鎖定置於表格上的 Banda 列 (TX) 和子專用表格鎖定 (SX)。
t1 
SAVEPOINT
  after_banda_sal;
     階段作業 1 會建立名為 after_banda_sal 的儲存點。
t2 
UPDATE employees
  SET salary=12000
  WHERE last_name=
  'Greene';
     階段作業 1 會鎖定 Greene 資料列。
t3   
UPDATE employees
  SET salary=14000
  WHERE last_name=
 'Greene';
   階段作業 2 嘗試更新 Greene 資料列，但是因為階段作業 1 對此資料列具有鎖定，所以無法取得鎖定。階段作業 2 中沒有開始的交易。
t4 
ROLLBACK
 TO SAVEPOINT
  after_banda_sal;
    

階段作業 1 會將更新回復為 Greene 的薪資，這會解除 Greene 的資料列鎖定。未釋出在 t0 取得的表格鎖定。

此時，階段作業 2 仍會被階段作業 1 封鎖，因為階段作業 2 會將尚未完成的階段作業 1 交易排入佇列。

t5     
UPDATE employees
  SET salary=11000
 WHERE last_name=
 'Greene';
 Greene 資料列目前已解除鎖定，因此階段作業 3 會取得更新 Greene 資料列的鎖定。這個敘述句會在階段作業 3 中開始一個交易。
t6 
COMMIT;
     階段作業 1 會確認，並結束其交易。階段作業 2 現在會排入佇列，以更新至階段作業 3 中交易後方的 Greene 資料列。

另請參閱：「鎖定持續時間」以深入瞭解 Oracle AI Database 版本鎖定的時間

倒回交易

倒回未確認的交易會還原對交易內 SQL 敘述句執行的所有資料變更。

倒回交易之後，在交易中完成的工作效果就不再存在。在不參照任何儲存點的情況下倒回整個交易時，Oracle AI Database 會執行下列動作：

倒回的持續時間是修改的資料量函數。

另請參閱：

交易確認

確認會結束目前的交易，並永久執行交易中的所有變更。

在表格 13-1 中，第二個交易以 sal_update2 開始，並以明確的 COMMIT 敘述句結束。兩個 UPDATE 陳述式產生的變更現在會變成永久性。

當交易確認時，會發生下列動作：

交易確認之後，使用者就可以檢視變更。

通常，無論交易大小為何，確認都是快速作業。確認的速度不會隨著交易中修改之資料的大小而增加。確認的最長部分是 LGWR 執行的實體磁碟 I/O。不過，LGWR 所花費的時間可以減少，因為它已經在背景中以增量方式寫入重做日誌緩衝區的內容。

預設行為是讓 LGWR 以同步方式將重做寫入至線上重做日誌，讓交易在將確認傳回給使用者之前，先等待緩衝重做加入磁碟。不過，對於較低的交易確認延遲，應用程式開發人員可以指定以非同步方式寫入重做，這樣交易就不需要等待重做位於磁碟上，而且可以立即從 COMMIT 呼叫傳回。

另請參閱：

隔離的交易概要

隔離的交易是隔離的交易，在資料庫復原期間不會復原。它需要 DBA 介入才能解決此問題，才能釋放鎖定。

Oracle AI Database 利用重做和還原來實現資料一致性。當資料庫在損毀之後開啟時，重做的應用程式會向前捲動資料庫，以取得所有確認的變更 (稱為快取復原 )，然後還原會倒回由未確認所做的變更，以及因為損毀而現在的非作用中變更。這稱為損毀復原。資料庫開啟並不會等待未確認交易的還原套用，以實現更快速的啟動。而是在交易表格中，會將交易的狀態標示為「非作用中」，並快速開啟資料庫。系統監督器 (SMON) 背景處理作業接著會以非同步方式執行非作用中交易的還原應用程式，因此稱為交易復原。

SMON 復原非作用中交易的另一個時間是執行處理復原期間。Oracle RAC 執行處理可能會因主動執行中的交易而當機。這些非作用中的交易會對在其他剩餘的 RAC 執行處理上的相同資料列封鎖交易。其中一個其餘執行處理的 SMON 背景處理作業會在兩個階段執行執行處理復原，接著執行快取復原，接著執行交易復原。

PMON 背景處理作業也可以將清除失敗處理作業時終止大型交易的工作卸載至 SMON。

SMON 處理作業會執行系統層次的作業，例如清除未使用的暫時區段、聯合連續擴充區塊以及許多其他作業。這是一個無法復原的處理作業，這表示 SMON 中發生損毀而導致 CDB 執行處理損毀。發生 SMON 交易復原失敗的原因有很多：

當機不僅會停止復原由 SMON 主動復原的交易，而且復原也會停止其餘的非作用中交易。發生永久失敗時，Oracle 客戶服務部會建議客戶停用 SMON 交易復原，然後開啟資料庫來減少影響。這會導致非作用中交易保留資料列鎖定的時間較長。這嚴重影響關鍵業務營運。

所有無法復原的交易都會被隔離，直到 DBA 能解決問題為止都不會被復原。DBA 會收到被隔離交易的通知，而且必須立即採取動作，才能釋放被隔離交易所保留的資料列鎖定。

DBA 有各種日誌與視觀表隔離的交易，可被警示協助識別隔離的交易及其隔離原因。DBA 會使用此資訊來解決特定問題，以便刪除隔離。

當多個交易發生失敗或跨整個 PDB 時 (例如因程式碼錯誤、多個區塊的實體損毀或 PDB SGA 損毀而導致的邏輯資料損毀)，查詢失敗的非作用中交易復原則不一定有幫助。這取決於這些失敗的根本原因是否相同，因為復原其他非作用中交易可能會在相同的問題中執行。即使在隔離幾筆交易之後，系統仍會保持在不一致的狀態。如果失敗是由於邏輯資料損毀所造成，這可能會很危險，因為它會隨著時間分散。為了避免發生此情況，會有三 (3) 項的交易隔離限制，在此限制之後，隔離區會提升至資料庫層次，如果 PDB 啟用存檔記錄日誌且能夠關閉 PDB，則會使用 shutdown abort 將 PDB 終止。PDB 的交易復原會自動停用，讓 DBA 在下次啟動時能夠更正問題。在解決問題之後，DBA 應啟用復原以便在下次啟動時執行。

注意：由於 Oracle Data Guard 使用邏輯複製，因此使用 Oracle Data Guard 時，隔離描述資料不會複製到待命伺服器。因此，待命伺服器上的交易隔離檢視 (例如 DBA_QUARANTINED_TRANSACTIONS) 內容可能會與主要伺服器上的項目不同。

相關主題

交易保全總覽

交易保全是應用程式可用來提供交易冪等的 API，資料庫可以保留保證的確認結果，指出交易是否已確認和完成。Oracle AI Database 提供適用於 JDBC Thin、OCI、OCCI 和 ODP.Net 的 API。

可復原的錯誤是由外部系統失敗所造成，與正在執行的應用程式階段作業邏輯無關。前景處理作業、網路、節點、儲存體以及資料庫的計畫性和非計畫性中斷之後，就會發生可復原的錯誤。如果中斷從屬端應用程式與資料庫之間的連線，應用程式就會收到中斷連線錯誤訊息。當連線中斷時所執行的交易稱為進行中交易。

若要決定要重新提交交易或將結果 (已確認或未確認) 傳回給用戶端，應用程式必須決定進行中交易的結果。在 Oracle Database 12c 之前，傳回給從屬端的確認訊息不是永久性訊息。檢查某個交易並不保證在檢查之後不會再確認，因此允許重複的交易以及其他形式的邏輯損毀。例如，使用者可能會在線上購買工作簿時重新整理 Web 瀏覽器，並對同一工作簿收取兩次費用。

另請參閱：

交易保全的優點

從 Oracle Database 12c 開始，Transaction Guard 提供應用程式一項工具，可判斷發生可復原中斷後進行中交易的狀態。

使用 Transaction Guard 時，應用程式可確保交易執行次數不超過一次。例如，如果線上書店應用程式判定先前提交的確認失敗，則應用程式可以安全地重新提交。

Transaction Guard 提供一項工具，可立即執行，以避免應用程式執行重複提交。Transaction Guard 可為每筆交易提供已知的結果。

Transaction Guard 是 Oracle AI Database 的核心功能。應用程式連續性在遮罩一般使用者的中斷時使用「交易保全」。如果沒有「交易保全」，應用程式在發生錯誤後重試可能會導致確認重複的交易。

另請參閱：

Transaction Guard 的運作方式

本節說明遺失確認訊息的問題，以及「交易保全」如何使用邏輯交易 ID 來解決問題。

遺失確認訊息

設計閒置時，開發人員必須在提交確認陳述式後解決通訊失敗的問題。確認訊息不會保留在資料庫中，因此無法在失敗後擷取。

下圖是從屬端應用程式與資料庫之間互動的高階表示法。

圖 2：遺失確認訊息

cncpt356.png 圖解描述

在標準確認案例中，資料庫會確認一個交易，然後將成功訊息傳回給從屬端。在圖 13-2 中，從屬端會送出確認敘述句，並接收說明通訊失敗的訊息。此類型的失敗有幾個原因，包括資料庫執行處理失敗或網路中斷。在此案例中，用戶端不知道交易的狀態。

通訊失敗之後，資料庫可能仍在執行提交，而且無法察覺到用戶端已中斷連線。檢查交易狀態並不保證作用中的交易在檢查之後不會確認。如果從屬端因為此過時的資訊而重新傳送確認，則資料庫可能會重複交易，進而導致邏輯損毀。

邏輯異動 ID

Oracle AI Database 使用稱為邏輯交易 ID 的全域唯一識別碼來解決通訊失敗。

此 ID 包含階段作業首次連線時所配置的邏輯階段作業編號，以及每次階段作業確認或輪換 back.Foot 1 時所更新的執行中確認編號。從應用程式的角度來看，邏輯交易 ID 可唯一識別在階段作業上提交失敗的最後一個資料庫交易。

對於確認一或多筆交易的從屬端往返，資料庫會儲存一個邏輯交易 ID。此 ID 可針對每個確認資料的往返行程，提供應用程式與資料庫之間互動的交易等冪。

at-most-once 協定可藉由要求資料庫執行下列動作來存取確認結果：

當交易執行時，資料庫與用戶端都會保留邏輯交易 ID。資料庫會在認證時、從連線集區借用，以及從從屬端驅動程式執行一或多個確認作業的往返時，提供從屬端一個邏輯交易 ID。

應用程式必須先使用 Java、OCI、OCCI 或 ODP.Net API 取得從屬端保留的邏輯交易 ID，應用程式才能判斷可復原錯誤後最後一個交易的結果。應用程式接著會呼叫含有邏輯交易 ID 的 PL/SQL 程序 DBMS_APP_CONT.GET_LTXID_OUTCOME，以判斷上次送出的結果：已確認 (true 或 false) 以及完成的使用者呼叫 (true 或 false)。

使用「交易保全」時，應用程式可以在可復原錯誤且階段作業上最後一個交易尚未確認時重新執行交易。當最後一個交易已確認，且使用者呼叫已完成時，應用程式可以繼續。應用程式可以使用 Transaction Guard 將已知的結果傳回用戶端，讓用戶端可以決定下一個要採取的動作。

另請參閱：

交易保全：範例

在此情況下，確認訊息會因為發生可復原的錯誤而遺失。

「交易保全」使用邏輯交易 ID 來保留 COMMIT 敘述句的結果，確保交易有已知的結果。

圖 3：邏輯交易狀態檢查

cncpt365.png 圖解描述

在圖 13-3 中，資料庫會通知應用程式是否已確認交易，以及是否已完成最後一個使用者呼叫。然後應用程式可以將結果傳回給一般使用者。可能性包括：

另請參閱：Oracle AI Database Development Guide 瞭解如何使用 Transaction Guard

應用程式連續性概要

應用程式連續性會在非計畫性和計畫性停機後重新執行未完成的應用程式要求，以嘗試遮蔽應用程式的停機。在此環境定義中，要求是來自應用程式的工作單位。

通常，要求會對應至單一資料庫連線上單一 Web 要求的 DML 敘述句和其他資料庫呼叫。一般而言，要求會被從連線集區取出和存入資料庫連線之間的呼叫來劃分。

本節包含下列主題：

申請持續性的優點

開發人員的基本問題是如何遮罩一般使用者遺失的資料庫階段作業。

當任何元件中斷資料庫與從屬端之間的交談時，應用程式連續性會嘗試回復資料庫階段作業，以解決遺失的階段作業問題。回復的資料庫階段作業包括所有狀態、游標、變數，以及最近一次存在的交易。

應用程式連續性的使用案例

在一般情況下，從屬端已送出要求至資料庫，而資料庫已建立交易和非交易狀態。

用戶端的狀態會維持在目前狀態 (可能含有輸入的資料、傳回的資料，以及快取的資料和變數)。不過，應用程式必須在其中運作的資料庫階段作業狀態也會遺失。

如果用戶端要求已起始一或多個交易，則應用程式會面臨下列可能性：

如果重新執行成功，就不會中斷計畫性和非計畫性停機的資料庫使用者服務。如果資料庫偵測到應用程式可看見且可能進行的資料變更，則重新執行會被拒絕。當超過允許的開始重新執行時間、應用程式使用限制的呼叫，或應用程式已使用 disableReplay 方法明確停用重新執行時，就不會嘗試重新執行。

另請參閱：Oracle Real Application Clusters Administration and Deployment Guide，以深入瞭解 Application Continuity 如何運作資料庫階段作業。

計畫性維護的應用程式連續性

應用程式持續性針對計畫性停機，讓應用程式能夠繼續執行能夠可靠地清空或移轉之資料庫階段作業的作業。

排定的維護並不需要中斷應用程式工作。應用程式連續性提供主動工作時間，從目前位置排水至目前不受維護影響的新位置。在清空間隔結束時，階段作業可能會保留在計畫維護的資料庫執行處理上。「應用程式連續性」不會強制中斷這些階段作業的連線，而是可以將這些階段作業容錯移轉至其他網站，然後重新送出任何進行中的交易。

啟用「應用程式連續性」時，資料庫可以執行下列作業：

使用 SRVCTL 公用程式、全域資料服務控制公用程式 (GDSCTL) 和 Oracle Data Guard Broker 的 drain_timeout 和 stop_option 服務屬性，控制計畫性維護期間的清空行為。DBMS_SERVICE 套裝程式提供基礎基礎架構。

另請參閱：

應用程式連續性架構

「應用程式連續性」的主要元件為執行時期、重新連線和重新執行。

階段如下：

  1. 一般程式實際執行

    在此階段中，「應用程式連續性」會執行下列作業：

    • 識別資料庫要求

    • 決定本機和資料庫呼叫是否可重新執行

    • 建立代理主機物件以啟用重新執行 (如有需要)，以及管理佇列

    • 保留這些呼叫的原始呼叫和驗證，直到資料庫要求或重新執行結束為止

  2. 重新建立連線

    此階段是由可復原的錯誤所觸發。「應用程式連續性」執行下列作業：

    • 確定已啟用資料庫要求的重新執行

    • 管理逾時

    • 取得資料庫的新連線，然後驗證這是有效的資料庫目標

    • 使用「交易保全」來判斷上次順利確認的交易 (未重新送出確認的交易)

  3. 重新執行

    「應用程式連續性」執行下列作業：

    • 重新執行佇列中保留的通話

    • 如果在重新執行期間顯示使用者可見的結果變更，則停用重新執行

    • 不允許確認，但允許最後一次恢復 (發生錯誤) 確認

在成功重新執行之後，要求會從失敗點繼續執行。

另請參閱：

自治式交易總覽

自治式異動是可從其他異動 (即主要異動) 呼叫的獨立異動。您可以暫停呼叫交易、執行 SQL 作業並在自治式交易中確認或還原它們，然後繼續呼叫交易。

不論呼叫的交易是確認還是倒回，自治式交易對於必須獨立執行的動作都很有用。例如，在股票購買交易中，不論整體股票購買是否經過，您都想要確認客戶資料。此外，即使整體交易倒回，您也要將錯誤訊息記錄至除錯表格。

自主交易具有以下特性：

在 PL/SQL 中，自治式交易會在自治式範圍內執行，此為以 pragma AUTONOMOUS_TRANSACTION 標示的常式。在此相關資訊環境中，常式包括最上層匿名 PL/SQL 區塊與 PL/SQL 子程式與觸發程式。pragma 是指示編譯器執行編譯選項的指令。pragma AUTONOMOUS_TRANSACTION 會指示資料庫執行此程序時，會以獨立於其父項交易的新自治式交易來執行。

下圖顯示控制如何從主要常式 (MT) 流向自治式常式，以及返回。主要常式為 proc1，自治式常式為 proc2。自治式常式可在控制權返回主要常式之前確認多個交易 (AT1 和 AT2)。

圖 4：交易控制流程

cncpt288.gif 圖解描述

當您輸入自治式常式的可執行區段時，主要常式會暫停。當您退出自治式常式時，主要常式會繼續。

在圖 13-4 中，proc1 內的 COMMIT 不僅會永久執行自己的工作，還會永久執行其階段作業中執行的任何未處理工作。不過，proc2 中的 COMMIT 只會永久執行 proc2 交易中執行的工作。因此，交易 AT1 和 AT2 中的 COMMIT 敘述句對 MT 交易沒有影響。

另請參閱：Oracle AI Database Development Guide 和 Oracle AI Database PL/SQL Language Reference，瞭解如何使用自主交易

分散式交易概要

分散式交易是一種交易，包含一或多個敘述句，這些敘述句會使用稱為資料庫連結的綱要物件，在分散式資料庫的兩個或多個不同節點上更新資料。

分散式資料庫是一組分散式系統中的資料庫，可對應用程式顯示為單一資料來源。資料庫連結描述一個資料庫執行處理如何登入另一個資料庫執行處理。

與本機資料庫上的交易不同，分散式交易會變更多個資料庫上的資料。因此，分散式交易處理較為複雜，因為資料庫必須以單元單位協調交易中變更的確認或倒回。整個交易都必須確認或倒回。即使發生網路或系統故障，Oracle AI Database 也必須協調網路上的交易控制，並維持資料的一致性。

兩階段確認

兩階段確認機制可確保參與分散式交易的所有資料庫都會全部確認或全部還原交易中的敘述句。此機制也可保護透過完整性限制條件、遠端程序呼叫以及觸發程式所執行的隱含 DML。

在多個資料庫之間進行兩階段確認時，一個資料庫會協調分散式交易。起始節點稱為全域協調器。協調器會詢問其他資料庫是否準備確認。如果有任何資料庫回應的是否，就會倒回整個交易。如果所有資料庫都投票為「是」，則協調器會廣播訊息，讓每個資料庫的確認永久生效。

雙階段確認機制對於發出分散式交易的使用者而言是通透的。事實上，使用者甚至不需要知道交易已分配。代表交易結束的 COMMIT 敘述句會自動觸發兩階段確認機制。在資料庫應用程式內文中包含分散式交易時，不需要編寫程式碼或複雜的敘述句語法。

另請參閱：

不確定的交易

當兩階段確認因任何類型的系統或網路故障而中斷時，就會發生有問題分散式交易。

例如，兩個資料庫會向它們準備確認的協調資料庫報告，但協調資料庫執行處理在收到訊息後會立即失敗。準備確認的兩個資料庫現在會在等待結果通知時停滯。

復原器 (RECO) 背景處理作業會自動解析有問題之分散式交易的結果。修復失敗並重新建立通訊之後，每個本機 Oracle 資料庫的 RECO 處理作業會自動在所有相關節點上一致地確認或倒回任何有問題的分散式交易。

如果發生長期失敗，Oracle AI Database 可讓每個本機管理員手動確認或還原因失敗而有疑慮的任何分散式交易。此選項可讓本機資料庫管理員釋出因長期失敗而無限期保留的任何鎖定資源。

如果資料庫必須復原至過去的時間點，則資料庫復原設備可讓其他網站的資料庫管理員將其資料庫回復至較早的時間點。此作業可確保全域資料庫維持一致。

另請參閱：

註腳圖例

註腳 1：

若為 Oracle Real Application Clusters (Oracle RAC)，邏輯交易 ID 會包含資料庫執行處理編號作為前置碼。