事务处理

此页上的脚本内容仅用于导航目的，不会以任何方式变更该内容。

本章定义事务处理并描述数据库如何处理事务处理。

事务处理简介

transaction 是包含一个或多个 SQL 语句的逻辑原子工作单元。

事务处理将 SQL 语句分组，以使它们要么全部提交（即应用于数据库），要么全部回退（即从数据库撤消）。Oracle AI Database 为每个事务处理分配一个称为事务处理 ID 的唯一标识符。

所有 Oracle 事务处理都遵循数据库事务处理的基本属性，称为 ACID 属性。ACID 是以下项的首字母缩略词：

事务的使用是数据库管理系统与文件系统不同的最重要方式之一。

样品交易：账户借项和贷项

要说明事务处理的概念，请考虑银行数据库。

当客户将资金从储蓄账户转移到支票账户时，该事务处理必须包括三个单独的操作：

Oracle AI Database 必须支持两种情况。如果所有三个 SQL 语句都保持帐户的正确平衡，则事务处理的影响可以应用于数据库。但是，如果资金不足、账号无效或硬件故障等问题导致事务处理中的一两个对账单无法完成，则数据库必须回滚整个事务处理，以便所有账户的余额正确无误。

下图显示了银行业务事务处理。第一个对账单从储蓄账户 3209 中减去 500 美元。第二份报表向支票账户 3208 添加了 $500。第三条语句将传送的记录插入到日记帐表中。最终语句将提交事务处理。

图 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 支持 statement-level atomicity ，这意味着 SQL 语句是原子工作单元，可以完全成功或完全失败。

成功的语句不同于已提交的事务处理。单个 SQL 语句在数据库作为原子单元进行语法分析并运行时会成功执行，就像在多行更新中更改所有行时一样。

如果 SQL 语句在执行期间导致错误，则该语句不成功，因此将回退该语句的所有效果。此操作是语句级回退。此操作具有以下特征：

导致语句级回退的错误的一个示例是尝试插入重复的主键。死锁中涉及的单个 SQL 语句（争用相同数据）也会导致语句级回退。但是，在 SQL 语句解析期间发现的错误（例如语法错误）尚未运行，因此不会导致语句级回退。

另请参见：

系统更改号 (System Change Numbers，SCN)

系统更改号 (system change number，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 可在系统全局区域 (system global area，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 语句更改的旧数据值。 " Read Consistency in the Read Committed Isolation Level "
Oracle AI Database 已在 SGA 的联机重做日志缓冲区中生成重做。 重做日志记录包含对数据块的更改以及对还原块的更改。 重做日志缓冲区
已对 SGA 的数据库缓冲区进行了更改。 存储在 SGA 的数据库缓冲区中的已提交事务处理的数据更改不一定由数据库写进程 (database writer，DBW) 立即写入数据文件。磁盘写入可以在提交之前或之后进行。 “ Database Buffer Cache（数据库缓冲区高速缓存）”
受数据更改影响的行将被锁定。 其他用户无法更改受影响行中的数据，也无法看到未提交的更改。 “锁定行为概要”

保存点

savepoint 是事务处理上下文中用户声明的中间标记。

在内部，保存点标记解析为 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 transaction 上入队。

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 所花费的时间会减少。

默认行为是让 LGWR 同步将重做写入联机重做日志，并让事务在向用户返回提交之前等待缓冲重做位于磁盘上。但是，为了降低事务处理提交延迟，应用程序开发人员可以指定异步写入重做，以便事务处理无需等待重做进入磁盘，并且可以立即从 COMMIT 调用返回。

另请参见：

隔离事务处理概览

隔离的事务是在数据库恢复期间隔离且未恢复的事务。需要 DBA 进行干预才能解决问题，然后才能释放锁。

Oracle AI Database 利用重做和还原实现数据一致性。当数据库在崩溃后打开时，重做应用将向前滚动数据库以获取所有已提交的更改（称为高速缓存恢复），还原将回滚未提交且由于崩溃而现在处于非活动状态所做的更改。这称为 crash 恢复。打开的数据库不会等待未提交的事务的还原应用以加快启动速度。相反，它会在事务处理表中将事务处理的状态标记为“不活动”，然后快速打开数据库。然后，系统监视器 (system monitor，SMON) 后台进程异步执行不活动事务处理的还原应用，该过程称为事务处理恢复。

SMON 恢复非活动事务处理的另一时间是在实例恢复期间。Oracle RAC 实例可能会因正在运行的事务处理而崩溃。这些非活动事务处理保留行锁，用于阻止其他剩余 RAC 实例上的相同行上的事务处理。其余一个实例上的 SMON 后台进程分两个阶段执行实例恢复，即高速缓存恢复，然后再执行事务处理恢复。

PMON 后台进程还可以在失败的进程清理到 SMON 期间卸载终止大型事务处理的工作。

SMON 进程执行系统级任务，例如清除未使用的临时段、合并连续区以及执行许多其他任务。这是一个不可恢复的过程，这意味着 SMON 中的崩溃会导致 CDB 实例崩溃。由于以下各种原因，可能会发生 SMON 事务处理恢复失败：

崩溃不仅会停止 SMON 正在主动恢复的事务处理的恢复，还会停止其余非活动事务处理的恢复。存在持久性故障时，Oracle 技术支持建议客户禁用 SMON 事务处理恢复并打开数据库以减少影响。这会导致无效事务处理将行锁保留更长时间。这严重影响了关键业务运营。

在 DBA 解决此问题之前，无法恢复的任何事务处理都会被隔离并保持未恢复状态。DBA 将收到有关隔离事务处理的通知，并且必须立即采取措施，以便释放被隔离事务处理持有的行锁。

DBA 会收到各种日志和视图中存在隔离的事务处理的预警，以帮助识别隔离的事务处理及其隔离的原因。DBA 使用此信息解决特定问题，以便可以删除隔离。

当多个事务处理发生故障或跨越整个 PDB 时，例如由于代码 bug 导致的逻辑数据损坏、多个块的物理损坏或 PDB SGA 损坏，隔离失败的非活动事务处理恢复可能有帮助，也可能没有帮助。这取决于这些故障的根本原因是否相同，因为恢复其他非活动事务处理可能会遇到相同的问题。即使在隔离了几个事务处理之后，系统仍保持不一致状态。如果由于逻辑数据损坏而导致故障，这可能会很危险，因为故障会随着时间的推移而扩散。为防止发生此情况，事务处理隔离限制为三 (3)，之后将隔离升级到数据库级别，如果为 PDB 启用了归档日志记录并且可以关闭 PDB，则 PDB 将使用 shutdown abort 终止。PDB 的事务处理恢复将自动禁用，以便 DBA 可以在下次启动时更正问题。解决问题后，DBA 应为下一次启动启用恢复。

注：由于 Oracle Data Guard 使用逻辑复制，因此隔离元数据在使用 Oracle Data Guard 时不会复制到备用服务器。因此，备用服务器上的事务隔离视图（如 DBA_QUARANTINED_TRANSACTIONS）的内容可能与主服务器上的条目不同。

相关主题

Transaction Guard 概览

Transaction Guard 是一个 API，应用程序可以使用它来提供事务处理幂等性，这是数据库保留保证提交结果的能力，以指示事务处理是否已提交和已完成。Oracle AI Database 为 JDBC Thin、OCI、OCCI 和 ODP.Net 提供 API。

可恢复错误是由外部系统故障引起的，与正在执行的应用程序会话逻辑无关。在前台进程、网络、节点、存储和数据库的计划内和计划外中断后，会发生可恢复的错误。如果中断中断了客户机应用程序与数据库之间的连接，则应用程序将收到断开连接错误消息。在连接中断时运行的事务处理称为正在运行的事务处理。

要决定是重新提交事务处理，还是将结果（已提交或未提交）返回给客户机，应用程序必须确定正在进行的事务处理的结果。在 Oracle Database 12c 之前，返回到客户机的提交消息并不持久。检查事务处理并不能保证它不会在检查后提交，从而允许重复事务处理和其他形式的逻辑损坏。例如，当用户在线购买工作簿时，可能会刷新 Web 浏览器，并针对同一工作簿收取两次费用。

另请参见：

Transaction Guard 的优势

从 Oracle Database 12c 开始，Transaction Guard 为应用程序提供了一个工具，用于确定可恢复停机后正在进行的事务处理的状态。

使用 Transaction Guard，应用程序可以确保事务处理不超过一次执行。例如，如果在线书店应用程序确定以前提交的提交失败，则应用程序可以安全地重新提交。

Transaction Guard 提供了执行次数最多的工具，可避免应用程序执行重复提交。Transaction Guard 为每个事务处理提供已知结果。

Transaction Guard 是 Oracle AI Database 的核心功能。Application Continuity 在屏蔽最终用户中断时使用 Transaction Guard。如果没有 Transaction Guard，则应用程序在出错后重试可能会导致提交重复的事务处理。

另请参见：

Transaction Guard 的工作原理

本节介绍丢失提交消息的问题以及 Transaction Guard 如何使用逻辑事务处理 ID 来解决该问题。

丢失的提交消息

在设计幂等性时，开发人员必须在提交提交语句后解决通信失败的问题。提交消息不会保留在数据库中，因此在失败后无法检索。

下图是客户机应用程序与数据库之间交互的高级表示形式。

图 2：丢失的提交消息

插图 cncpt356.png 的说明

在标准提交案例中，数据库提交事务处理并向客户机返回成功消息。在图 13-2 中，客户机提交提交语句并收到一条消息，指出通信失败。这种类型的故障可能由于多种原因而发生，包括数据库实例故障或网络中断。在此方案中，客户不知道事务处理的状态。

通信失败后，数据库可能仍在运行提交，并且不知道客户机已断开连接。检查事务处理状态并不保证在检查后不会提交活动事务处理。如果客户机由于此过时信息而重新发送提交，则数据库可能会重复该事务处理，从而导致逻辑损坏。

逻辑事务处理 ID

Oracle AI Database 使用称为逻辑事务处理 ID 的全局唯一标识符解决通信故障。

此 ID 包含会话首次连接时分配的逻辑会话编号，以及每次会话提交或滚动 back.Foot 1 时更新的正在运行的提交编号。从应用程序角度来看，逻辑事务处理 ID 唯一标识在会话上提交的最后一个失败的数据库事务处理。

对于提交一个或多个事务处理的客户机的每次往返行程，数据库将存储一个逻辑事务处理 ID。此 ID 可以为提交数据的每个往返行程的应用程序和数据库之间的交互提供事务处理幂等性。

最多一次协议允许通过要求数据库执行以下操作来访问提交结果：

在事务处理运行时，数据库和客户机都保存逻辑事务处理 ID。数据库在验证时、从连接池借入时以及从执行一个或多个提交操作的客户机驱动程序每次往返时都为客户机提供逻辑事务处理 ID。

在出现可恢复错误后，应用可以确定最后一笔交易的结果之前，该应用将使用 Java、OCI、OCCI 或 ODP.Net API 获取客户端保存的逻辑交易 ID。然后，应用程序将调用逻辑事务处理 ID 为 DBMS_APP_CONT.GET_LTXID_OUTCOME 的 PL/SQL 过程，以确定上次提交的结果：已提交（true 或 false）和完成的用户调用（true 或 false）。

使用 Transaction Guard 时，当错误可恢复且会话上的最后一个事务处理尚未提交时，应用程序可以重放事务处理。当最后一个事务处理已提交且用户调用已完成时，应用程序可以继续。应用程序可以使用 Transaction Guard 将已知结果返回给客户端，以便客户端可以决定要执行的下一个操作。

另请参见：

Transaction Guard：示例

在此方案中，由于可恢复的错误，提交消息将丢失。

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 可提供有效工作时间，从当前位置排出到当前不受维护影响的新位置。在耗尽间隔结束时，会话可能会保留在计划维护的数据库实例上。Application Continuity 可以将这些会话故障转移到剩余站点，然后重新提交任何正在进行的事务，而不必强制断开这些会话的连接。

启用“Application Continuity（应用程序连续性）”后，数据库可以执行以下操作：

使用 SRVCTL 实用程序、Global Data Services Control Utility (GDSCTL) 和 Oracle Data Guard Broker 的 drain_timeout 和 stop_option 服务属性控制计划内维护期间的排空行为。DBMS_SERVICE 软件包提供底层基础结构。

另请参见：

应用连续性架构

Application Continuity 的主要组件是运行时、重新连接和重放。

这些阶段如下：

  1. 正常运行时

    在此阶段中，“Application Continuity（应用程序连续性）”将执行以下任务：

    • 标识数据库请求

    • 确定本地和数据库调用是否可重放

    • 构建代理对象以启用重放（如有必要）和管理队列

    • 在禁用数据库请求或重放结束之前，暂挂这些调用的原始调用和验证

  2. 重新关联

    此阶段由可恢复错误触发。Application Continuity 执行以下任务：

    • 确保为数据库请求启用重放

    • 管理超时

    • 获取与数据库的新连接，然后验证这是有效的数据库目标

    • 使用 Transaction Guard 确定上次提交的事务处理是否成功（未重新提交提交的事务处理）

  3. 重放

    Application Continuity 执行以下任务：

    • 重放队列中保留的呼叫

    • 如果重放期间显示用户可见的结果更改，则禁用重放

    • 不允许提交，但允许最后一次撤回（遇到错误）提交

成功重放后，请求将从故障点继续。

另请参见：

自治事务处理概览

自治事务处理是一个独立的事务处理，可以从另一个事务处理（即主事务处理）调用。您可以暂停正在调用的事务处理，执行 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。

在多个数据库之间进行两阶段提交时，一个数据库将协调分布式事务处理。启动节点称为全局协调器。协调器询问其他数据库是否准备提交。如果任何数据库响应为 no，则将回退整个事务处理。如果所有数据库都投赞成票，则协调程序会广播一条消息，使提交在每个数据库上成为永久性提交。

两阶段提交机制对发出分布式事务处理的用户是透明的。事实上，用户甚至不需要知道交易是分布的。表示事务处理结束的 COMMIT 语句将自动触发两阶段提交机制。在数据库应用程序的主体中包括分布式事务处理时，无需编写代码或使用复杂的语句语法。

另请参见：

未决事务处理

当两阶段提交被任何类型的系统或网络故障中断时，将发生不确定的分布式事务处理。

例如，两个数据库向协调数据库报告它们已准备好提交，但协调数据库实例在收到消息后会立即失败。准备提交的两个数据库现在处于挂起状态，等待通知结果。

recoverer (RECO) 后台进程将自动解析不确定的分布式事务处理的结果。修复故障并重新建立通信后，每个本地 Oracle 数据库的 RECO 进程会自动在所有涉及的节点上一致地提交或回退任何怀疑的分布式事务。

如果出现长期故障，Oracle AI Database 允许每个本地管理员手动提交或撤消因故障而存在疑问的任何分布式事务处理。此选项使本地数据库管理员可以释放由于长期故障而无限期保留的所有锁定资源。

如果数据库必须恢复到过去一段时间，则数据库恢复工具使其他站点的数据库管理员能够将其数据库返回到更早的时间点。此操作可确保全局数据库保持一致。

另请参见：

脚注图例

脚注 1：

对于 Oracle Real Application Clusters (Oracle RAC)，逻辑事务处理 ID 将数据库实例号作为前缀。