`
yangzb
  • 浏览: 3506634 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

oracle分布式事务总结

阅读更多
oracle分布式事务总结(转)
2008-09-18 17:47

基本概念

Local Coordinator:在分布事务中,必须参考其它节点上的数据才能完成自己这部分操作的站点。

Global Coordinator:分布事务的发起者,负责协调这个分布事务。

Commit Point Site:在分布事务中,首先执行COMMIT或ROLLBACK操作的站点。一般情况下,应该把存储关键数据的站点作为Commit Point Site。因为Commit Point Site和其它站点不一样,从来不会进入prepared状态,所以不会存在IN-DOUBT事务。

可以设置初始化参数COMMIT_POINT_STRENGTH,在分布式事务中,会根据这 个值的大小来确定Commit Point Site,分布事物的状态信息也存在该数据库中。一般将关键的数据库作为commit point site ,commit_point_strength值较高的数据库为commit point site,在分布事物中最先提交

分布式提交的3个阶段

分布事物的两阶段提交分三个过程:

1. 准备阶段(PREPARE PHASE)

·本地数据库Global Coordinator向其它数据库发出COMMIT通知

·比较所有数据库的SCN号,将最高的SCN号作为分布事物的全局SCN号

·所有数据库写在线日志

·对分布事物修改的表加分布锁,防止被读写

·各数据库向Global Coordinator发出已经准备好的通知

所有参与分布事物的数据库必须经过上述准备,才能进入下一阶段。

2. 提交阶段(COMMIT PHASE)

·本地数据库Global Coordinator通知commit point site首先提交。commit point site提交后,释放其占有的资源,通知Global Coordinator完成提交

·本地数据库Global Coordinator通知其它数据库提交

·提交节点在日志中追加一条信息,表示分布事物已经完成提交,并通知Global Coordinator。此时所有数据库的数据保持了一致性。

3. 注销阶段(FORGET PHASE)

·本地数据库Global Coordinator通知commit point site所有数据库已经完成提交

·commit point site清除分布事物的记录和状态信息,并通知Global Coordinator

·Global Coordinator清除本地分布事物的记录和状态信息

此时分布事物的两阶段提交全部完成。

如果两阶段提交完成之前,数据库或网络出现异常,应用就会报错,分布事物处于IN_DOUBT状态。一旦数据库或网络恢复正常,系统(RECO PROCESS)会自动处理IN_DOUBT状态的分布事物。有些情况需要管理员手工处理IN_DOUBT状态的分布事物:

·IN_DOUBT状态的分布事物,将关键表锁住,造成应用不能正常工作

两个重要的视图

DBA_2PC_PENDING:列出所有的悬而未决的事务﹐此视图在末填入悬而未决的事务之前是空的﹐解决这后也被清空。

LOCAL_TRAN_ID

本地事务标识﹐格式为integer.integer.ingeger。

当一个连接的local_tran_id和global_tran_id相同时﹐那么该节点是该事务的全局协调器。

GLOBAL_TRAN_ID

全局事务标识,格式为﹕global_db_name.db_hex_id.local_tran_id,其中db_hex_id是用来标识数据库八字符的十六进制数﹐公共事各id在分布式事务的每个节点都是相同的。

“YES”意味着一部分事务已经在一个节点上提交﹐而在另一个节点上被回滚。

TRAN_COMMENT

事务的注释﹐或者如果使用了事务命名﹐当事各被提交时﹐事务的名字就会出现在此处

已提交的事务的全局提交数

DBA_2PC_PENDING的STATE列的说明

Connecting

通常情况下﹐只有全局协调器和本地协调器才使用这个条目﹐节点在能够决定它是否能够准备好之前﹐要收集来自于其它数据库服务的信息。

节点已准好﹐可能或者也可能没有将已准备好的消息通知本地协调器﹐但此时﹐该节点还没有接收到提交的请求﹐仍保持着准许备好的状态﹐控制着提交事务所必需的任何本地资源。

节点(任何类型)已经提交了事务﹐但该事务所包含的其它节点可能并没有提交﹐也就是该事务在一个个或多个其它节点上仍然是悬而未决 。

Forced commit

DBA进行判断后﹐可以强行提交未决的事务﹐如果一个事务由DBA在本地节点进行手动提交时﹐产生此项目

Forced abor(rollback)

DBA进行判断后﹐可以强行回滚未决的事务﹐如果一个事务由DBA在本地节点进行手动回滚时﹐产生此项目

DBA_2PC_NEIGHBORS:列出所有获得的(从远程客户)和送出的(给远程服务器)悬而未决的事务﹐也表示该本地节点是不是事务的提交点站点。

 

LOCAL_TRAN_ID

对获得事务来说指本地节点信息的客户数据库的名称﹔对送出的事务来说指用于访问远程服务器上信息的数据库链接的名称

DBuser_owner

对获得事务来说指远程数据库链接用于连接的本地账户﹔对于送出事务来说指该数据库链接的拥有者。

INTERFACE

‘C’代表提交信息﹐’N’表示已准备好状态的一条消息或是一条请求只读提交的请求。

当’IN_OUT’为OUT时﹐’C’表示该连接的远程的站点是提交点站点,并且知道是提交还是中断。’N’表示本地节点正在通知远程节点﹐说它已准备好。

当’IN_OUT’为IN时﹐‘C’表示本地节点或送出的远程的一个数据库是提交点站点﹐’N’表示本地节点正在通知远程节点﹐说它已准备好。

处理悬挂事务的一般步骤

1、 检查alert文件,发现类似下面error:

       ORA-1591 "lock held by in-doubt distributed transaction %s"

       ORA-2062 "distributed recovery received dbid x, expected y"

       ORA-2068 "following severe error from %s%s"

2、 确认网络是否正常、dblink是否valid、v$dblink和gv$dblink中查询当前是否在使用分布式事务。

3、 查询视图dba_2pc_pending,查询悬挂事务信息:

SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#

       FROM DBA_2PC_PENDING

       WHERE LOCAL_TRAN_ID = '??.';

       如果没有记录,说明RECO进程已经自动处理了该事务。

4、 在所有节点上查询视图dba_2pc_neighbors

5、 得到所有节点的COMMIT_POINT_STRENGTH值,值最大的为commit point site,即最早提交的点,如果悬挂事务发生在commit point site,则它的state决定了整个分布式事务的状态。悬挂事务是否应该commit force或者是rollback force,由此节点决定。

6、 检查dba_2pc_pending的state列,如果是commited,意味着本地数据库提交已经成功。其他节点需要根据本地事务号和最大的commit#进行强制提交。用法如下:

       SVRMGR> COMMIT FORCE 'your local transactionID on this node', 'highest SCN from already committed site';

       SVRMGR> COMMIT FORCE '1.13.5197', '88123887';

7、 如果commit point site的state为commited外的其他状态,则表明commit point site 没有提交成功,分布式事务需要强制回滚。这里不再需要所有节点的最大commit#。用法如下:

       SVRMGR> ROLLBACK FORCE 'your local transactionID on this node';

       SVRMGR> ROLLBACK FORCE '1.13.5197';

8、 清除dba_2pc_pending和dba_2pc_neighbers的相关记录。一般分布式事务自动恢复后,视图内容会自动清除,如果是手工提交的事务,则需要用dbms_transaction包手工清除,清除规则如下表所示:

确定何时能使用DBMS_TRANSACTION

Collecting

Purge_lost_db_entry(只有当自动回复不能解决事务时)

Committed

Committed

Committed

Purge_lost_db_entry(只有当自动回复不能解决事务时)

Forced

Commit

Committed

Purge_lost_db_entry(只有当自动回复不能解决事务时)

Forced rollback

Purge_lost_db_entry(只有当自动回复不能解决事务时)

Forced commit

Committed

手动删除不一致性﹐然后使用purge_mixed

Forced rollback

手动删除不一致性﹐然后使用purge_mixed

测试记录

¡        设置db1的commit_point_strength为1,db2的commit_point_strength为2,db2为commit point site。

¡        db1、db2上执行100次insert循环,每次循环用分布式事务插入db1和db2中的测试表。中间reboot db2服务器。此时db1对测试表的查询出现以下错误:

SQL> select count(1) from temp.my_table;

select count(1) from temp.my_table

*

ERROR at line 1:

ORA-01591: lock held by in-doubt distributed transaction 7.30.7415

[oracle@db2 bdump]$ tail -f alert_ntespay.log

Tue Mar 4 14:14:28 2008

DISTRIB TRAN 1234.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

is local tran 7.30.7415 (hex=07.1e.1cf7)

insert pending prepared tran, scn=934346533 (hex=0.37b0ff25)

db1中分布式事务相关的2个视图内容如下:

select a.* from dba_2pc_pending a where LOCAL_TRAN_ID='7.30.7415';

         LOCAL_TRAN_ID    GLOBAL_TRAN_ID STATE       MIXED     ADVICE    TRAN_COMMENT FAIL_TIME       FORCE_TIME         RETRY_TIME   OS_USER OS_TERMINAL         HOST        DB_USER COMMIT#

1       7.30.7415         4660.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 prepared    no                        2008-3-4 14:14:28                 2008-3-4 14:22:56        zhenxingzhai       ZHAIZHENXING         NETEASE\ZHAIZHENXING               934346533

其中,

state有以下几种状态:

Collecting, prepared, committed, forced commit, or forced rollback

mixed表示是否部分提交,部分回滚

advice:

C

for commit,

R

for rollback, else

NULL

select a.* from dba_2pc_neighbors a where LOCAL_TRAN_ID='7.30.7415';

      LOCAL_TRAN_ID    IN_OUT    DATABASE       DBUSER_OWNER     INTERFACE      DBID         SESS#        BRANCH

1       7.30.7415   in      NULLjavaxa.oracle.com        TEMP       N      javaxa_orcl 1         01000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

此视图说明了数据源1的输入连接信息。因为数据源2不是通过dblink连接的,以此没有出现它的记录。

¡        db2重启后查询my_tab:

SQL> select count(1) from my_tab;

COUNT(1)

----------

        75

¡        因为db2中dba_2pc_pending和dba_2pc_neighbers中没有记录,并且db2为commit point site,没有记录意味着没有进行任何操作,所以db1应该和db2一样,进行强制rollback。

SQL> conn / as sysdba

Connected.

SQL> rollback force '7.30.7415';

Rollback complete.

SQL> select count(12) from temp.my_table;

COUNT(12)

----------

        75

db1的alert日志中显示了可疑事务的回滚过程:

Tue Mar 4 15:14:31 2008

DISTRIB TRAN 1234.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

is local tran 7.30.7415 (hex=07.1e.1cf7)

change pending prepared tran, scn=934346533 (hex=0.37b0ff25)

to     pending forced rollback tran, scn=934346533 (hex=0.37b0ff25)

¡        回滚后,两个视图中的状态更改为如下:

select a.* from dba_2pc_pending a where LOCAL_TRAN_ID='9.33.5992';

            LOCAL_TRAN_ID    GLOBAL_TRAN_ID STATE       MIXED     ADVICE    TRAN_COMMENT FAIL_TIME       FORCE_TIME         RETRY_TIME   OS_USER OS_TERMINAL         HOST        DB_USER COMMIT#

1       7.30.7415         4660.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 forced rollback no                        2008-3-4 14:14:28        2008-3-4 15:14:31        2008-3-4 15:20:07        zhenxingzhai         ZHAIZHENXING      NETEASE\ZHAIZHENXING               934346533

select a.* from dba_2pc_neighbors a where LOCAL_TRAN_ID='9.33.5992';

      LOCAL_TRAN_ID    IN_OUT    DATABASE       DBUSER_OWNER     INTERFACE      DBID         SESS#        BRANCH

1       7.30.7415   in      NULLjavaxa.oracle.com        TEMP       N      javaxa_orcl 1         01000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

¡        去除dba_2pc_pending和dba_2pc_ neighbors中的记录:

(1) Disable分布式恢复

SQL> ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;

System altered.

(2)Puege(清空)in-doubt transaction entry:

SQL> exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('7.30.7415');

PL/SQL procedure successfully completed.

(3)commit;

(4)然后enable 分布式恢复:

SQL> ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;

分布式事务相关资料

Note:1012842.102

Note:100664.1

Note:274321.1

Note:126069.1

http://www.itk.ilstu.edu/docs/Oracle/server.101/b10739/ds_txns.htm#i1007721

分享到:
评论

相关推荐

    在分布式事务中实现基于Oracle PLSQL UL LOCK的悲观离线锁

    总结来说,实现基于Oracle PL/SQL的Ultra Lock悲观离线锁是为了解决分布式事务中的并发控制问题。通过精细的锁策略,我们可以确保数据的一致性,但同时也需要关注其对并发性能的影响,并采取适当的措施来防止死锁。...

    Seata是一种易于使用高性能基于Java的开源分布式事务解决方案

    总结来说,Seata是一个强大的分布式事务处理工具,它提供了多种分布式事务模式,能够灵活应对各种复杂的业务场景。对于Java开发的分布式应用来说,Seata是实现高并发、高可用和强一致性的理想选择。通过合理运用...

    Seata 是一款开源的分布式事务解决方案,提供高性能和简单易用的分布式事务服务

    总结来说,Seata作为一款优秀的分布式事务解决方案,不仅在性能上表现出色,而且在易用性和可扩展性上也有着突出的优势,对于构建高可用、高性能的分布式系统具有重要的价值。开发者可以通过Seata轻松解决分布式环境...

    seata分布式事务0.9.0

    总结,Seata 0.9.0是一个强大的分布式事务解决方案,通过其核心概念和工作原理,以及不断优化的版本更新,为开发者提供了处理分布式事务的有效工具。在实际应用中,它可以帮助企业构建高可用、高性能的微服务架构,...

    基于Oracle的分布式数据库设计与技术.pdf

    【Oracle分布式数据库设计】 Oracle分布式数据库设计是一种将数据分布在多个地理位置独立的节点上,通过网络进行协调和通信的技术。这种设计允许数据在不同的系统之间共享,同时保持数据的一致性和完整性,适合大型...

    掌握分布式事务的艺术:深入MySQL XA事务处理

    ### 掌握分布式事务的艺术:深入 MySQL XA 事务处理 #### 1. 分布式事务与 XA 事务概述 ##### 1.1 分布式事务定义 分布式事务是指那些跨越多个数据库实例或者服务的事务。这类事务的管理比单一数据库上的事务更加...

    基于Oracle的分布式客户关系管理系统分析与设计.doc

    总结,本设计以Oracle分布式数据库技术为基础,构建了一个高效、可扩展的CRM系统,旨在提升企业的客户服务水平,增强竞争力。通过B/S架构,系统实现了跨地域的协同工作,降低了维护成本,为企业的长远发展提供了有力...

    基于oracle的分布式客户关系管理系统分析与设计.doc

    通过全局命名和分布式事务处理,实现跨数据库的操作。 3.2.2 Struts MVC框架 Struts框架遵循MVC设计模式,其中Model表示业务对象和数据,View负责显示,Controller处理用户请求并调用业务逻辑。Struts提供了一系列...

    oracle自治事务(Trigger)

    3. **数据同步**:在分布式系统中,自治事务可以用来同步不同数据库之间的数据。 4. **定时任务**:在触发器内部执行定时任务,不受外部事务的影响。 #### 五、总结 自治事务是Oracle触发器的一个强大功能,它使得...

    oracle数据库学习总结.doc.docx

    Oracle支持分布式数据库系统,允许在不同的地理位置分散数据,并进行跨站点的数据操作和事务处理,这对于大型企业尤其重要。 通过深入学习这些知识点,你可以逐步掌握Oracle数据库的基本概念、管理和操作,为实际...

    oracle_中间件_tuxedo

    ### Oracle Tuxedo:分布式事务处理与集成基础架构的卓越表现 #### 分布式事务处理:数据完整性的保障 Oracle Tuxedo以其先进的分布式事务处理能力而著称,这一特性确保了跨所有资源的数据完整性,无论访问协议...

    oracle_DB_NAME,INSATNCE_NAME,ORACLE_SID区别

    GLOBAL_NAME 的作用主要是在分布式事务中,分布式事务的各个数据库应该有相同的 GLOBAL_NAME。 DB_DOMAIN DB_DOMAIN 是分布式数据库中的一个概念,它是 GLOBAL_NAME 的一部分。DB_DOMAIN 的作用主要是在分布式事务...

    Java_分布式SQL事务查询引擎,适用于任何数据库上的数据分片、扩展、加密等.zip

    ShardingSphere作为此领域的代表,提供了一种高效、灵活的方式来处理这些问题,使得应用程序能够轻松地在各种数据库系统上实现分布式事务。 **一、数据分片** 数据分片是将大型数据库拆分为多个较小的、独立的...

    基于Oracle的GIS数据库的分布式设计与实现 (1).pdf

    Oracle Rdbms提供了分布式查询、单点事务、多点更新和节点自治等功能。SQL*NET允许应用程序同时访问本地和远程数据库,实现了跨网络的数据传输和转换。SQL*CONNECT则作为一个桥梁,使得Oracle能够与其他数据库管理...

    TiDB&MySql&Oracle介绍及区别

    (3) 分布式事务:TiDB 支持 ACID 事务,确保在分布式环境下数据的一致性和完整性。 (4) 真正金融级高可用:通过多副本机制和故障切换,提供高可用性保障,满足金融行业对稳定性的严苛需求。 (5) 一站式 HTAP 解决...

    ORACLE数据库学习总结可用.pdf

    本文将对Oracle数据库的主要方面进行总结,包括其发展历程、体系结构、SQL*Plus常用命令以及基本的SQL查询操作。 一、Oracle简介 Oracle数据库自诞生以来经历了多个版本的迭代。Oracle 8引入了对Internet的支持,...

    sqlserver2008链接ORACLE服务器驱动.rar

    对于复杂的企业级应用,还可能涉及到分布式事务处理和性能优化,这些都需要对SQL Server和Oracle都有深入的理解。 总结来说,"sqlserver2008链接ORACLE服务器驱动.rar"这个资源提供了实现SQL Server 2008与Oracle...

Global site tag (gtag.js) - Google Analytics