Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

1

好友

10

主题
1#
发表于 2013-11-12 18:55:36 | 查看: 5901| 回复: 2
本帖最后由 xia 于 2013-11-12 19:04 编辑

这两天alter 日志中出现了DISTRIB TRAN * 的提示,但未有错误提示;我把相关的日志截取一段,因为日志中除了归档日志就这 DISTRIB TRAN *了,不明白为什么会出现 DISTRIB TRAN * 这样的日志提示,是oracle系统自动的还是人工做了某些事务的修改呢(如程序开发人员改变了应用程序)?请帮忙看一下;谢谢



Tue Nov 12 14:30:19 2013
DISTRIB TRAN PORTALDB.6d88f872.51.69.5057
  is local tran 51.69.5057 (hex=33.45.13c1)
  insert pending committed tran, scn=512468179 (hex=0.1e8ba4d3)
Tue Nov 12 14:30:19 2013
DISTRIB TRAN PORTALDB.6d88f872.51.69.5057
  is local tran 51.69.5057 (hex=33.45.13c1))
  delete pending committed tran, scn=512468179 (hex=0.1e8ba4d3)
Tue Nov 12 14:30:48 2013
Thread 1 advanced to log sequence 2664 (LGWR switch)
  Current log# 105 seq# 2664 mem# 0: +ORADATA/portaldb/redo105.log
Tue Nov 12 14:30:49 2013
Archived Log entry 5604 added for thread 1 sequence 2663 ID 0x279002d6 dest 1:
Tue Nov 12 14:31:17 2013
DISTRIB TRAN PORTALDB.6d88f872.52.9.8450
  is local tran 52.9.8450 (hex=34.09.2102)
  insert pending committed tran, scn=512809517 (hex=0.1e90da2d)
Tue Nov 12 14:31:17 2013
DISTRIB TRAN PORTALDB.6d88f872.52.9.8450
  is local tran 52.9.8450 (hex=34.09.2102))
  delete pending committed tran, scn=512809517 (hex=0.1e90da2d)
DISTRIB TRAN PORTALDB.6d88f872.10.42.154757
  is local tran 10.42.154757 (hex=0a.2a.25c85)
  insert pending committed tran, scn=512814214 (hex=0.1e90ec86)
DISTRIB TRAN PORTALDB.6d88f872.10.42.154757
  is local tran 10.42.154757 (hex=0a.2a.25c85))
  delete pending committed tran, scn=512814214 (hex=0.1e90ec86)
Tue Nov 12 14:33:42 2013
Thread 1 advanced to log sequence 2665 (LGWR switch)

  Current log# 101 seq# 2665 mem# 0: +ORADATA/portaldb/redo01.log
Tue Nov 12 14:33:43 2013
Archived Log entry 5605 added for thread 1 sequence 2664 ID 0x279002d6 dest 1:
Tue Nov 12 14:39:33 2013
Thread 1 advanced to log sequence 2666 (LGWR switch)
  Current log# 102 seq# 2666 mem# 0: +ORADATA/portaldb/redo02.log
Tue Nov 12 14:39:34 2013
Archived Log entry 5607 added for thread 1 sequence 2665 ID 0x279002d6 dest 1:
Tue Nov 12 14:44:57 2013
Thread 1 advanced to log sequence 2667 (LGWR switch)
  Current log# 103 seq# 2667 mem# 0: +ORADATA/portaldb/redo103.log
Tue Nov 12 14:44:58 2013
Archived Log entry 5610 added for thread 1 sequence 2666 ID 0x279002d6 dest 1:
Tue Nov 12 14:47:36 2013
Thread 1 advanced to log sequence 2668 (LGWR switch)
  Current log# 104 seq# 2668 mem# 0: +ORADATA/portaldb/redo104.log
Tue Nov 12 14:47:37 2013
Archived Log entry 5611 added for thread 1 sequence 2667 ID 0x279002d6 dest 1:
Tue Nov 12 14:49:39 2013
Thread 1 advanced to log sequence 2669 (LGWR switch)
  Current log# 105 seq# 2669 mem# 0: +ORADATA/portaldb/redo105.log
Tue Nov 12 14:49:40 2013
Archived Log entry 5612 added for thread 1 sequence 2668 ID 0x279002d6 dest 1:
Tue Nov 12 14:51:18 2013
Thread 1 advanced to log sequence 2670 (LGWR switch)
  Current log# 101 seq# 2670 mem# 0: +ORADATA/portaldb/redo01.log
Tue Nov 12 14:51:19 2013
Archived Log entry 5614 added for thread 1 sequence 2669 ID 0x279002d6 dest 1:
Tue Nov 12 14:53:03 2013
Thread 1 advanced to log sequence 2671 (LGWR switch)
  Current log# 102 seq# 2671 mem# 0: +ORADATA/portaldb/redo02.log
Tue Nov 12 14:53:04 2013
Archived Log entry 5615 added for thread 1 sequence 2670 ID 0x279002d6 dest 1:
Tue Nov 12 14:54:42 2013
Thread 1 advanced to log sequence 2672 (LGWR switch)
  Current log# 103 seq# 2672 mem# 0: +ORADATA/portaldb/redo103.log
Tue Nov 12 14:54:43 2013
Archived Log entry 5616 added for thread 1 sequence 2671 ID 0x279002d6 dest 1:
Tue Nov 12 14:56:24 2013
Thread 1 advanced to log sequence 2673 (LGWR switch)
  Current log# 104 seq# 2673 mem# 0: +ORADATA/portaldb/redo104.log
Tue Nov 12 14:56:25 2013
Archived Log entry 5618 added for thread 1 sequence 2672 ID 0x279002d6 dest 1:
Tue Nov 12 14:58:18 2013
Thread 1 advanced to log sequence 2674 (LGWR switch)
  Current log# 105 seq# 2674 mem# 0: +ORADATA/portaldb/redo105.log
Tue Nov 12 14:58:19 2013
Archived Log entry 5619 added for thread 1 sequence 2673 ID 0x279002d6 dest 1:
Tue Nov 12 15:00:12 2013
Thread 1 advanced to log sequence 2675 (LGWR switch)
  Current log# 101 seq# 2675 mem# 0: +ORADATA/portaldb/redo01.log
Tue Nov 12 15:00:13 2013
Archived Log entry 5621 added for thread 1 sequence 2674 ID 0x279002d6 dest 1:
Tue Nov 12 15:03:33 2013
Thread 1 advanced to log sequence 2676 (LGWR switch)
  Current log# 102 seq# 2676 mem# 0: +ORADATA/portaldb/redo02.log
Tue Nov 12 15:03:34 2013
Archived Log entry 5622 added for thread 1 sequence 2675 ID 0x279002d6 dest 1:
Tue Nov 12 15:41:45 2013
Thread 1 advanced to log sequence 2677 (LGWR switch)
  Current log# 103 seq# 2677 mem# 0: +ORADATA/portaldb/redo103.log
Tue Nov 12 15:41:47 2013
Archived Log entry 5624 added for thread 1 sequence 2676 ID 0x279002d6 dest 1:
Tue Nov 12 15:49:41 2013
DISTRIB TRAN PORTALDB.6d88f872.53.6.20872
  is local tran 53.6.20872 (hex=35.06.5188)
  insert pending committed tran, scn=524090225 (hex=0.1f3cfb71)
Tue Nov 12 15:49:41 2013
DISTRIB TRAN PORTALDB.6d88f872.53.6.20872
  is local tran 53.6.20872 (hex=35.06.5188))
  delete pending committed tran, scn=524090225 (hex=0.1f3cfb71)

Tue Nov 12 16:16:36 2013
Thread 1 advanced to log sequence 2678 (LGWR switch)




18:05:47 sys@PORTALDB> SELECT * FROM dba_2pc_pending;

no rows selected

Elapsed: 00:00:00.00
18:34:10 sys@PORTALDB> show parameter distributed

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
distributed_lock_timeout             integer     60

2#
发表于 2013-11-12 20:29:05
PREPARE PHASE:
1) COMMIT POINT SITE IS PARANOID
The global coordinator will already know what the
commit point strength of each node prior to the commit.
Read-only nodes are not included.
2) All nodes except for PARANOID is asked to prepare.
3) HAWAII, the local coordinator, is responsible to ask her
dependent nodes to prepare before she prepares. In this
case, PARANOID is a commit point site; thus, it is ignored.
4) The highest SCN is sent to LOCAL node via the
local coordinators. The highest SCN is 1000.
5) All nodes which PREPARED will flush entries of the
transaction to the redo logs if not already done.
If any of the nodes send an “ABORT” message back, then the transaction is
rolled back at this time. Any failure after the PREPARE phase will result
with “in-doubt” transactions.
COMMIT PHASE:
1) PARANOID IS ASKED TO COMMIT OR ROLLBACK BY THE LOCAL (GC).
2) PARANOID commits at a SCN greater than 1000.
a) Redo is flushed.
b) Locks are released.
c) outcome is relayed back to the LOCAL node (GC).
Assume success:
3) AFter receiving the information, GC will commit at the
same SCN and pass the information to its dependents.
a) commit flushed to redo logs.
b) data locks are released.
c) GC will pass the information to HAWAII and HQ.
(1) They, in turn, will commit and HAWAII
will pass the information to PARANOID.
If all is successful, every statement will commit with the same SCN and then
RECO will delete the entries from “dba_2pc_pending” and “dba_2pc_neighbors”
tables. Afterwards, the nodes will “forget” the transaction.

回复 只看该作者 道具 举报

3#
发表于 2013-11-12 20:29:54
如果再次遇到该问题 建议你 通过http://www.askmaclean.com/archiv ... onding-tm-lock.html中的脚本收集数据

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 10:28 , Processed in 0.050017 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569