Sybase数据库技术,数据库恢复

 

随着Sybase被完全整合到SAP下，Sybase原来的支持网站被SAP Support Portal取代。
只有购买了SAP服务的用户才能使用账号登录SAP Support Portal进行介质下载、补丁升级、报Incident等。
目前，原Sybase所有产品（包括：Adaptive Server Enterprise、Sybase IQ、Replication Server、PowerDesigner等）的官方手册仍然可以从https://infocenter.sybase.com/help/index.jsp进行浏览或下载。暂不清楚该网站https://infocenter.sybase.com/help/index.jsp何时会被完全迁移到SAP Support上！
Sybase官方手册英文版有html和pdf两种格式，而中文版手册只有pdf一种格式。为了国内Sybase用户更方便、快捷地搜索Sybase常见产品的官方手册内容，特将中文版Sybase官方手册转为html格式！
Sybase产品官方手册中文版的html格式所有内容的版权归SAP公司所有！本博客站长是Sybase数据库的铁杆粉丝！

如有Sybase数据库技术问题需要咨询，请联系我！

  QQ :289965371
  Email:

以下官方手册为ASE 15.7 ESD#2中文版：

1. 新增功能公告 适用于 Windows、Linux 和 UNIX 的 Open Server 15.7 和 SDK 15.7
   
2. 新增功能摘要
   
3. 新增功能指南
   
4. ASE 15.7 发行公告
   
5. 配置指南（windows）
   
6. 安装指南（windows）
   
7. 参考手册：构件块
   
8. 参考手册：命令
   
9. 参考手册：过程
   
10. 参考手册：表
    
11. Transact-SQL® 用户指南
    
12. 系统管理指南，卷 1
    
13. 系统管理指南，卷 2
    
14. 性能和调优系列：基础知识
    
15. 性能和调优系列：锁定和并发控制
    
16. 性能和调优系列：监控表
    
17. 性能和调优系列：物理数据库调优
    
18. 性能和调优系列：查询处理和抽象计划
    
19. 性能和调优系列：使用 sp_sysmon 监控 Adaptive Server
    
20. 性能和调优系列：利用统计分析改进性能
    
21. 程序员参考 jConnect for JDBC 7.0.7
    
22. Adaptive Server Enterprise 中的 Java
    
23. 组件集成服务用户指南
    
24. Ribo 用户指南
    
25. 内存数据库用户指南
    
26. Sybase Control Center for Adaptive Server® Enterprise
    
27. 安全性管理指南
    
28. 实用程序指南
    

 

< 上一个 | 内容 | 下一步 >

DTM 管理和故障排除 ‌ ‌

事务和控制线程

在 Adaptive Server 版本 12.0 以前的版本中，事务的所有资源都由一个服 务器任务独占。服务器只能与启动事务的任务来共享该事务。

Adaptive Server 12.5 和更高版本对由符合 X/Open XA 的事务管理器（如 Encina 和 TUXEDO）使用的“挂起”和“连接”语义提供本机支持。事 务可以在不同的执行线程中共享，也可以不与任何线程相关联。

如果一个事务没有与之关联的线程，则称之为“分离的事务”。分配给 分离的事务的 spid 值为 0。可以在新的 master.dbo.systransactions 表中查 看事务的 spid 值，也可以在新的 sp_transactions 过程的输出中查看该值。 有关详细信息，请参见 第 181 页的“获取有关分布式事务的信息”。

对于系统管理员的提示

由于客户端应用程序可能需要重新附加初始线程，或者将新线程附加到 事务，因此应该在 Adaptive Server 中保留分离的事务。当未将线程附加 到该事务，系统管理员无法通过注销与事务相关的 spid 来回退该事务。

处于分离状态的事务也可以阻止用 dump transaction 命令来截断日志。在 极为特殊的情况下，可以使用新的 dbcc complete_xact 命令来回退分离的 事务，以尝试完成事务。请参见 第 187 页的“尝试完成事务”。

dtm detach timeout period 参数

系统管理员也可以指定一个服务器范围的时间间隔，在此时间之后， Adaptive Server 将自动回退处于分离状态的事务。dtm detach timeout period 用于设置分布式事务分支可以保持分离状态的时间长度（单位为 分钟）。如果超过此时间，Adaptive Server 将回退分离的事务。

例如，要在 30 分钟后自动回退分离的事务，可使用以下命令：

sp_configure 'dtm detach timeout period', 30

为支持分离的事务而对锁管理器所做的更改 ‌

在 Adaptive Server 版本 12.0 以前的版本中，锁管理器使用事务线程的 spid 值来唯一地标识事务锁。在新的事务管理器中，事务可以从其初始线程 中分离出来，从而没有关联的 spid。此外，具有不同 spid 值的多个线程 必须能够共享相同的事务锁，以执行分布式事务的工作。

为了便于进行这些更改， Adaptive Server 版本 12.5 和更高版本的锁管理 器使用唯一的锁所有者 ID 取代 spid 来标识事务锁。锁所有者 ID 独立于 创建事务的 spid，即使事务从线程中分离出来，锁所有者 ID 仍然保留。 当事务没有关联的线程，或者新线程被附加到事务时，就可以通过锁所 有者 ID 来支持事务锁。

锁所有者 ID 存储在 master.dbo.syslocks 的新 loid 列中。若要确定事务的

loid 值，可以检查 sp_lock 或 sp_transactions 输出。

通过检查 sp_transactions 输出中的 spid 和 loid 列，可了解有关事务及其控 制线程的信息。spid 值为 0 表示该事务已从其控制线程中分离。非零的 spid 值表示控制线程当前附加在该事务上。

如果 sp_transactions 输出中的 loid 值为偶数，则表示本地事务拥有该锁。 如果 loid 值为奇数，则表示外部事务拥有该锁。

有关 sp_transactions 输出的详细信息，请参见 第 181 页的“获取有关分布 式事务的信息”。

获取有关分布式事务的信息 ‌

Adaptive Server 有一个系统表 master.dbo.systransactions，该表存储关于所 有服务器事务的信息。systransactions 可标识每个事务并维护有关事务状 态及其关联线程的信息。

新系统过程 sp_transactions 可转换 systransactions 和 syscoordinations 表中 的信息，以显示活动事务的状态条件。

systransactions 中的事务标识

Adaptive Server 将事务名称存储在数据类型为 varchar(255) 的列中，以适 应不同分布式事务协议所提供的事务名称的长度和格式。在以前的服务 器版本中，该列的数据类型为 varchar(64)。例如，在 X/Open XA 协议中

，为分布式事务分配的事务名称同时包含全局事务 ID ( gtrid ) 和分支限定 符。在 Adaptive Server 中，该信息已合并在 systransactions 表的 xactname 列中。

systransactions.xactname 同时存储外部创建的分布式事务的名称以及本地 服务器事务的名称。外部创建的分布式事务由 X/Open XA 事务管理器或 MSDTC 定义。定义本地事务的客户端可以在 varchar(255) 列的约束范围 内用任何名称来命名这些事务。同样地，外部事务管理器可以使用多种 不同的格式来命名分布式事务。

事务关键字

事务关键字存储在 systransactions 的 xactkey 列中，可用作服务器事务的 唯一内部句柄。对于本地事务，即使事务名称对于服务器来说并不唯一， xactkey 也能确保可以区分各个事务。

从 Adaptive Server 12.0 版开始，所有系统表都引用 systransactions.xactkey 来唯一地标识事务。此规则仅有的例外是 sysprocesses 和 syslogshold 表， 它们引用 systransactions.xactname 并将该值截断至 varchar(64) 的长度（对 于 sysprocesses）和 varchar(67) 的长度（对于 syslogshold），以向后兼容 Adaptive Server 的以前版本。

使用 sp_transactions 查看活动事务

sp_transactions 过程可转换 systransactions 和 syscoordinations 中的信息，以 提供有关活动事务的信息。如果不使用关键字，sp_transactions 将显示关 于所有活动事务的信息：

sp_transactions

failover srvname namelen xactname

------------------------------ ----------- -----------

--------------------

----------------- ---------- ------ ------ -----------

-------------------------- ------------------------------ -------

----------------------------------------------------------------- 0x00000b1700040000dd6821390001 Local None Jun 1 1999 3:47PM

Begun Attached 1 1 2

Resident Tx NULL 17

$user_transaction

Resident Tx caserv2 108

00000b1700040000dd6821390001-aa01f04ebb9a-00000b1700040000dd6821390001-

aa01f04ebb9a-caserv1-caserv1-0002

标识本地、远程和外部事务

“type”列说明事务是本地事务、远程事务还是外部事务。本地事务在本 地服务器（运行 sp_transactions 的服务器）上执行。本地事务在“srvname”

列中显示一个空值，因为该事务发生在当前服务器上。

对于远程事务， sp_transactions 将在“srvname”列下面列出执行该事务的 服务器的名称。上面的 sp_transactions 输出显示了在名为“caserv2”的服 务器上执行的远程事务。

外部事务是指由外部事务协调器（如 CICS、Encina 或其它 Adaptive Server 的“ASTC HANDLER”进程）来协调的事务。外部事务在“srvname” 列中也显示一个空值。

标识事务协调器

“coordinator”列指示用来管理事务的方法或协议。在以上输出中，本地 事务 $user_transaction 没有外部协调器。在 caserv2 上发生的远程事务有 协调器值“ASTC”。这表示使用本机 Adaptive Server 协调服务来协调 该事务，如 第 174 页的“使用 Adaptive Server 协调服务”所述。

有关可能的协调器值的完整列表和说明，请参见《参考手册》中的

sp_transactions。

查看事务控制线程

spid 列显示附加到事务的进程的进程 ID（如果该事务已从其控制线程中 分离，则显示为 0）。对于本地事务，spid 值表示在本地服务器上运行 的进程 ID。对于远程事务，spid 表示在指定的远程服务器上运行的任务 的进程 ID。以上输出显示了在远程服务器 caserv2 上运行的 spid 值 8。

理解事务状态信息

“state”列显示关于每个事务当前状态的信息。在任意给定时间，本地 或外部事务可能处于执行命令、被中止、被提交，或其它状态。另外， 分布式务可以处于就绪状态，也可以尝试完成或回退。

“connection”列显示有关事务连接状态的信息。该信息可用来确定事务 当前是附加于一个进程，还是从一个进程中分离。为了响应来自事务管 理器的请求，X/Open XA 环境中的事务可以从它们的启动进程中分离。

有关可能的协调器值的完整列表和说明，请参见《参考手册：过程》中 的 sp_transactions。

将 sp_transactions 输出限制为特定状态

可以使用 sp_transactions 和 state 关键字来将输出限制为指定的事务状态。 例如：

sp_transactions "state", "Prepared"

只显示就绪的分布式事务的信息。

事务故障切换信息 ‌

“ failover”列显示在高可用性环境中运行的服务器的特殊信息。在高可 用性环境中，如果原始服务器发生了严重故障，就可能将就绪事务传送 给辅助同服务器。“failover”列可以显示三种可能的故障切换状态，以 指示事务的执行方式和位置：‌

• 在正常操作条件下，不使用 Adaptive Server 高可用性功能的系统上将 显示“Resident Tx”。“Resident Tx”表示事务已启动，并且正在一 个主 Adaptive Server 上执行。

• 对辅助协同服务器进行故障切换后，将显示“Failed-over Tx”。 “Failed-over Tx”表示事务原来在主服务器上启动并达到就绪状态， 但被自动迁移到辅助协同服务器上（例如，因为主服务器发生了系 统故障）。就绪事务的迁移对外部协调服务来说是透明的。

• 在对辅助协同服务器进行故障切换后，还显示“Tx by Failover-Conn”。 “Tx by Failover-Conn”表示应用程序或客户端试图在主服务器上启 动事务，但是主服务器因连接故障切换而不可用。在发生这种情况 后，事务将在辅助协同务器上自动启动，并将该事务标记为“Tx by Failover-Conn”。

有关 Adaptive Server 故障切换功能的详细信息，请参见 第 183 页的“事 务故障切换信息”。

使用 sp_transactions 确定提交节点和 gtrid‌

如果将 sp_transactions 和 xid 关键字一起使用，则除了 第 181 页的“使用 sp_transactions 查看活动事务”中所述的输出外，还将显示特定事务的提 交节点、父节点和 gtrid。这种形式的 sp_transactions 要求指定一个特定的 事务名称。例如：

sp_transactions "xid", "00000b1700040000dd6821390001-aa01f04ebb9a- 00000b1700040000dd6821390001-aa01f04ebb9a-caserv1-caserv1-0002" xactkey type coordinator starttime

state connection dbid spid loid

failover srvname namelen xactname

commit_node parent_node gtrid

------------------------------ ----------- -----------

--------------------

----------------- ---------- ------ ------ -----------

-------------------------- ------------------------------ -------

-----------------------------------------------------------------

-------------

-------------

-------------

0x00000b2500080000dd6821960001 External ASTC Jun 1 1999 3:47PM

Begun Attached 1 8 139

Resident Tx NULL 108

00000b1700040000dd6821390001-aa01f04ebb9a-00000b1700040000dd6821390001-

aa01f04ebb9a-caserv1-caserv1-0002

caserv1 caserv1 00000b1700040000dd6821390001-aa01f04ebb9a

提交节点和父节点

对于由 Adaptive Server 来协调的分布式事务，“commit node ”列将列出执 行分布式事务的最顶层分支的服务器名称。该事务决定了事务所有分支的 提交或回退状态。有关详细信息，请参见 第 175 页的“层次事务协调”。

“parent node”列将列出启动事务的服务器的名称。在以上的 sp_transactions 输出中，“commit node”和“parent node”列都列出了相 同的服务器 caserv1。这说明分布式事务在 caserv1 上开始，然后 caserv1 将该事务的分支传播到当前服务器。

全局事务 ID

“gtrid”列显示由 Adaptive Server 协调的分布式事务的全局事务 ID。事 务分支是同一分布式事务的一部分，它们共享同一个 gtrid。可以将特定 的 gtrid 与 sp_transactions gtrid 关键字一起使用，以确定在当前服务器上 运行的其它事务分支的状态。这对于系统管理员很有用，因为他们必须 确定应尝试提交还是回退分布式事务的一个特定分支。有关将 sp_transactions 和 gtrid 关键字一起使用的示例，请参见 第 189 页的“确定 Adaptive Server 事务的提交状态”。

注释 对于由符合 X/Open XA 要求的事务管理器、MSDTC 或 SYB2PC

来协调的事务，gtrid 列将显示外部事务协调器提供的完整事务名称。

执行外部事务的步骤

在所有版本中，Adaptive Server 用来执行外部事务的步骤如下：

1 TM 启动一个 begin transaction。

2 TM 启动一个 attach transaction。

注释 TM 可能将步骤 1 和 2 一起执行。

3 应用程序执行 DML 命令。

4 TM 启动一个 detach transaction。

5 如有必要，重复步骤 2 到 4。

6 如果事务未回退，则 TM 启动一个 prepare transaction。

7 TM 启动一个 commit transaction 或 rollback transaction。 执行步骤 3 可能导致分布式事务回退。

由于在发出每个命令前都检查全局变量非常麻烦，许多用户应用程序根 本不对其进行检查。在版本 15.0.3 以前的版本中，如果分布式事务已回 退，Adaptive Server 允许用户应用程序继续发出 SQL 命令。这些命令将 作为独立的事务在分布式事务外执行。应已包括在回退事务中的 SQL 命 令可以独立于该事务提交，从而导致数据在事务上不一致。

在版本 15.0.3 和更高版本中，Adaptive Server 会自动阻止原打算在分布式 事务内执行的 SQL 命令在该事务外执行。用户应用程序不再必须在发出 每个命令检查全局变量；当某个事务被隐式中止时，将显示一条错误消 息 (3953)，指出“由于外部事务已回退，无法执行该命令。”发出 detach transaction 命令时，此消息将消失。

要禁止 3953 错误消息并使 Adaptive Server 恢复以前的行为（即使 DTM 不处于活动状态，也执行 SQL 命令），请使用跟踪标志 -T3955 启动 Adaptive Server。

分布式事务的崩溃恢复过程 ‌

在崩溃恢复过程中，Adaptive Server 必须解决它发现的处于就绪状态的 分布式事务。解决就绪事务所采用的方法取决于用来管理分布式事务的 协调方法或协调协议。

注释 在常规数据库恢复过程中（使用 load database 或 load transaction 命 令），将不执行以下崩溃恢复过程。如果 load database 或 load transaction 应用任何已就绪或不确定的事务，Adaptive Server 就会在使关联数据库 联机之前中止这些事务。

由 MSDTC 协调的事务

使用 MSDTC 来协调的就绪事务根据主事务的提交状态来前进或回退。 在恢复过程中，Adaptive Server 开始与 MSDTC 建立联系，以确定主事 务的提交状态，然后相应地提交或回退就绪事务。如果无法与 MSDTC 取得联系，恢复过程就会等待，直到建立联系。在 Adaptive Server 与 MSDTC 建立联系之前，将不会执行进一步的恢复。

由 Adaptive Server 或 X/Open XA 协调的事务

在崩溃恢复过程中，Adaptive Server 还可能会遇到使用 Adaptive Server 事 务协调服务或 X/Open XA 协议来协调的就绪事务。当遇到这些事务时， 本地服务器必须等待进行协调的 Adaptive Server 或外部事务协调器来启 动联系并指示就绪事务是应提交还回退。

为了加快恢复进程，Adaptive Server 将把所有这些事务恢复到故障发生前 的状态。事务管理器用初始事务 ID 创建一个新事务，而锁管理将应用锁 来保护初始事务所修改的数据。恢复的事务仍处于就绪状态，但是已被 分离，没有线程与之关联。

一旦事务协调器与 Adaptive Server 建立联系，事务管理器就可提交或回 退事务。

使用这种恢复机制，即使进行协调的 Adaptive Server 或外部事务管理器 尚未尝试解决就绪事务，服务器也可以使数据库联机。由于就绪事务持 有它在恢之前拥有的锁，所以其它客户端和事务可以恢复对本地数据进 行的工作。一旦就绪事务与其协调器建立联系，即可将其提交或回退。

如果控制 Adaptive Server 或外部事务管理器不能完成事务，系统管理员 则可以尝试着完成该事务，以释放事务锁和事务资源。有关详细信息， 请参见 第 187 页的“尝试完成事务”。

由 SYB2PC 协调的事务

使用 SYB2PC 协议来协调的就绪事务将根据主事务的提交状态来前进或 回退。在恢复过程中，Adaptive Server 启动与提交服务的联系，以确定主 事务的提交状态，然相应地提交或回退就绪事务。如果无法与提交服务 联系，Adaptive Server 就不能使数据库联机。但是，Adaptive Server 将继 续恢复系统中的其它数据库。

在 Adaptive Server 的早期版本中，这种恢复方法用于 SYB2PC 事务，而

Adaptive Server 12.5 和更高版本仍沿用这种方法。

尝试完成事务 ‌

Adaptive Server 包括 dbcc complete_xact 命令，以便于尝试完成事务。dbcc complete_xact 通过提交或回退事务的工作来处理事务，从而释放该事务 占用的所有资源。

dbcc complete_xact 用于以下情况：只有系统管理员可以正确处理就绪事 务；或系统管理员必须在不等待事务协调器的情况下处理事务。

例如，在 第 175 页的图 8-2 中，如果所有远程 Adaptive Server 都已准备 好它们的事务，但是与 ASE1 的网络连接已永远丢失，就可以考虑尝试 完成事务。远程 Adaptive Server 将在 ASE1 的协调服务与之联系之前， 使其事务保持就绪状态。在这种情况下，只有 ASE2、ASE3 和 ASE4 的 系统管理员才能正确地解决就绪事务。在尝试完成 ASE3 中的就绪事务 后，将释放事务和锁资源，并在 systransactions 中记录提交状态，以备将 来由事务协调器使用。如果尝试完成 ASE2 中的事务，则同时会完成传 播给 ASE4 的事务。

完成就绪事务

警告！尝试完成就绪事务时，可能会在整个分布式事务中造成不一致的 结果。系统管理员尝试提交或回退事务的决定可能会与进行协调的 Adaptive Server 或事协议的决定相矛盾。

在尝试完成事务之前，系统管理员应该尽量确定进行协调的 Adaptive Server 或事务协议是决定提交还是回退分布式事务（请参见 第 189 页的 “确定 Adaptive Server 事务的提交状态”）。

通过使用 dbcc complete_xact，系统管理员可强制 Adaptive Server 提交或 回退分布式事务的分支。尝试完成就绪事务之后，Adaptive Server 将在 master.dbo.systransactions 中记录事务的提交状态，这样事务协调器（ Adaptive Server、MSDTC 或 X/Open XA 事务管理器）就可以知道事务 是已提交还是已回退。

Adaptive Server 将把尝试提交或中止事务的命令传播给它为事务分支所 协调的任何参与者服务器。例如，如 第 175 页的图 8-2 所示，如果您尝 试提交 ASE2 上的事务，则 ASE2 会将命令传播到 ASE4，这样 ASE4 上 的事务也会提交。

dbcc complete_xact 要求提供活动事务名称和预期的事务结果。例如，以 下命令将尝试提交事务：

dbcc complete_xact "00000b1700040000dd6821390001- aa01f04ebb9a-00000b1700040000dd6821390001-

aa01f04ebb9a-caserv1-caserv1-0002", "commit"

忘记尝试完成的事务

在系统管理员尝试完成就绪事务后， Adaptive Server 将在 master.dbo.systransactions 中保留事务提交状态的有关信息。保留该信息 后，外部事务协调器就可以检测到尝试完成的事务。

如果外部协调器是另一个 Adaptive Server，则服务器将检查提交状态， 如果尝试完成与分布式事务的提交状态发生冲突，则会记录警告消息。 检查完提交状态后，进行协调的 Adaptive Server 将从 systransactions 中 清除提交状态信息。

如果外部协调器是符合 X/Open XA 的事务管理器，那么当尝试完成与分 布式事务发生冲突时，该事务管理器将不记录警告消息，但遵循 X/Open XA 的事务管理器将从 systransactions 中清除提交状态信息。

手工清除提交状态

dbcc forget_xact 从 systransactions 中清除尝试完成事务的提交状态。当系 统管理员不希望协调服务知道事务已尝试完成时，或者当无法使用外部 协调器来清除 systransactions 中的信息时，就可以使用这种方法。

请参见《参考手册：命令》中的 dbcc，了解有关使用 dbcc forget_xact 的详 细信息。

完成未就绪的事务

dbcc complete_xact 还可用于回退由 Adaptive Server 协调、尚未达到就绪 状态的事务。尝试回退未就绪的事务不会给分布式事务带来风险，因为 协调服务器可以确定事务未准备好它的工作。在这些情况下，进行协调 的 Adaptive Server 可以回退整个分布式事务以保持一致性。

当尝试回退未就绪的 Adaptive Server 事务时，Adaptive Server 将不会 在 systransactions 中记录尝试回退，而是在屏幕上输出一条信息性消息并将 其记录在服务器的错误日志中。

确定 Adaptive Server 事务的提交状态‌

如果要提交或回退的分布式事务分支由 Adaptive Server 来协调，则可以 使用 sp_transactions 来确定分布式事务的提交状态。为此，请执行以下 步骤。

注释 这些步骤不能用于由 X/Open XA 协议、MSDTC 或 SYB2PC 来协 调的分布式事务。

1 在执行要完成的事务分支的服务器中，将 sp_transactions 和 xid 关键 字一起使用来显示有关事务的信息。记录事务的提交节点和 gtrid。 例如：

sp_transactions "xid", "00000b1700040000dd6821390001-aa01f04ebb9a- 00000b1700040000dd6821390001-aa01f04ebb9a-caserv1-caserv1-0002" xactkey type coordinator starttime

state connection dbid spid loid

failover srvname namelen xactname

commit_node parent_node gtrid

------------------------------ ----------- -----------

--------------------

----------------- ---------- ------ ------ -----------

-------------------------- ------------------------------ -------

-----------------------------------------------------------------

-------------

-------------

-------------

0x00000b2500080000dd6821960001 External ASTC Jun 1 1999 3:47PM

Begun Attached 1 8 139

Resident Tx NULL 108

00000b1700040000dd6821390001-aa01f04ebb9a-

00000b1700040000dd6821390001-aa01f04ebb9a-caserv1-caserv1-0002

caserv1 sfserv 00000b1700040000dd6821390001-aa01f04ebb9a

在本例中，分布式事务的提交节点是“caserv1”，gtrid 是 “00000b1700040000dd6821390001-aa01f04ebb9a”。

2 登录到提交节点所指定的服务器上。例如：

isql -Usa -Psa_password -Scaserv1

3 将 sp_transactions 和 gtrid 关键字一起使用来确定在步骤 1 中获得 gtrid

的分布式事务的提交状态：

sp_transactions "gtrid", "00000b1700040000dd6821390001-aa01f04ebb9a" xactkey type coordinator starttime

state connection dbid spid loid failover srvname namelen

xactname commit_node parent_node

------------------------------ ----------- -----------

--------------------

----------------- ---------- ------ ------ -----------

-------------------------- ------------------------------ -------

-----------------------------------------------------------------

-------------

-------------

0x00000b1700040000dd6821390001 Local None Jun 1 1999 3:47PM

Committed Attached 1 1 2

Resident Tx NULL 17

$user_transaction

caserv1 caserv1

在本例中，带有指定 gtrid 的本地事务已提交，如“state”列中所示。 系统管理员应该尝试提交 在步骤 1 中检查的就绪事务。

4 使用具有系统管理员特权的帐号登录到执行要完成的事务分支的服 务器：

isql -U sa -Psa_password -Ssfserv

5 使用 dbcc complete_xact 提交事务。在本例中，系统管理员应使用

commit 关键字来保持与分布式事务的一致性：

dbcc complete_xact "00000b1700040000dd6821390001- aa01f04ebb9a-00000b1700040000dd6821390001-

aa01f04ebb9a-caserv1-caserv1-0002", "commit"

编程与配置注意事项

本节介绍在排除故障时应考虑的配置选项。

分布式事务中的 DDL 行为

如果由外部事务管理器通过 X/Open XA 协议或其它 Adaptive Server 的 Adaptive Server 事务协调服务来协调某事务，则在该事务中不允许使用 DDL 命令。即使在启用了数据库选项 ddl in tran 的情况下，这一行为仍 然适用。

外部事务中的 Adaptive Server 隐式回退

如果外部事务中出现错误（例如，死锁、更新触发器中止等），Adaptive Server 可能会中止该外部事务。

虽然 Adaptive Server 会发送表示发生故障的错误消息，但应用程序并不 总是检查这些消息，特别是对于简单插入（例如，它们可能不知道由 DBA 添加的触发器）。错误消息中可能并不总是明显说明 XA 事务已结束。

如果 Adaptive Server 中止一个外部事务并引发 SQLException，您可以发 出 select @@trancount。如果 @@trancount 的值为零，则表示 DTM 事 务已中止。

应用程序应调用事务管理器（通常为应用程序服务器），通知它该事务 已中止。如果忽略错误消息，后续更新可能在 DTM 事务上下文外（例 如，本地务）进行。您可以记录错误消息并检查 @@transtate 或

@@trancount 以检验是否进行了更新。

下面介绍了一个导致 Adaptive Server 回退外部事务的触发器。Insert 语句 中包含可能失败的触发器。如果 Adaptive Server 无法发出 insert，则更新 将运行 ut.commit 函数。

本例（伪代码形式）假设您正在运行一个 JTA/XA UserTransaction：

try {

insert into table values (xx....) update table

ut.commit();

} catch (SQLException sqe) {

if this is a known error then process else

select @@trancount into count if count == 0

then ut.rollback() }

如果不包括回退函数，则附加更新将在 JTA/XA 事务外进行。

< 上一个 | 内容 | 下一步 >