求助 事务回滚 startTransjava commit rollbackk commit

嵌套事务的回滚与提交_百度文库
两大类热门资源免费畅读
续费一年阅读会员,立省24元!
嵌套事务的回滚与提交
上传于||文档简介
&&S​q​l​ ​s​e​r​v​e​r​ ​嵌​套​事​务​的​回​滚​与​提​交
阅读已结束,如果下载本文需要使用0下载券
想免费下载更多文档?
定制HR最喜欢的简历
下载文档到电脑,查找使用更方便
还剩7页未读,继续阅读
定制HR最喜欢的简历
你可能喜欢BeginTrans,CommitTrans 与RollbackTrans_百度文库
两大类热门资源免费畅读
续费一年阅读会员,立省24元!
BeginTrans,CommitTrans 与RollbackTrans
上传于||文档简介
&&B​e​g​i​n​T​r​a​n​s​,​C​o​m​m​i​t​T​r​a​n​s​ ​与​R​o​l​l​b​a​c​k​T​r​a​n​s
阅读已结束,如果下载本文需要使用1下载券
想免费下载本文?
定制HR最喜欢的简历
你可能喜欢<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员,您的IP地址所在网段被ITeye拒绝服务,这可能是以下两种情况导致:
一、您所在的网段内有网络爬虫大量抓取ITeye网页,为保证其他人流畅的访问ITeye,该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站,该代理服务器被网络爬虫利用,大量抓取ITeye网页
请您点击按钮解除封锁&Phone: 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务
Categories
Tag Cloud 3D
WP Cumulus Flash tag cloud by
9 or better.
最新评论国内圈子
oracle security
本站文章除注明转载外,均为本站原创: 转载自
本文链接地址:
昨天凌晨被电话吵醒,某客户的一套11gR2 RAC出现异常,正常启动之后很快就crash掉,并伴随相关ora-00600错误。
通过alert log发现如下信息:
Wed Dec 25 06:21:05 2013
QMNC started with pid=50, OS id=9481
Completed: ALTER DATABASE OPEN /* db agent *//* {0:5:77} */
Wed Dec 25 06:21:05 2013
Dumping diagnostic data in directory=[cdmp_05], requested by (instance=2, osid=9294 (SMON)), summary=[incident=180659].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ORACLE Instance xxxx2 (pid = 32) - Error 600 encountered while recovering transaction (114, 16) on object 25736.
Errors in file /opt/oracle/app/diag/rdbms/xxxx/xxxx2/trace/xxxx2_smon_9294.trc:
ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], []
Thread 2 advanced to log sequence 153071 (LGWR switch)
Current log# 11 seq# 153071 mem# 0: /yx_oradata1/redo11.log
。。。。。。
ORACLE Instance xxxx2 (pid = 32) - Error 600 encountered while recovering transaction (117, 21) on object 25738.
Errors in file /opt/oracle/app/diag/rdbms/xxxx/xxxx2/trace/xxxx2_smon_9294.trc:
ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], []
Dumping diagnostic data in directory=[cdmp_14], requested by (instance=2, osid=9294 (SMON)), summary=[incident=180662].
Errors in file /opt/oracle/app/diag/rdbms/xxxx/xxxx2/trace/xxxx2_smon_9294.trc
(incident=180663):
ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/app/diag/rdbms/xxxx/xxxx2/incident/incdir_180663/xxxx2_smon_.trc
Wed Dec 25 06:21:27 2013
PMON (ospid: 9220): terminating the instance due to error 474
Wed Dec 25 06:21:27 2013
System state dump requested by (instance=2, osid=9220 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /opt/oracle/app/diag/rdbms/xxxx/xxxx2/trace/xxxx2_diag_9230.trc
Wed Dec 25 06:21:30 2013
ORA-1092 : opitsk aborting process
Non critical error ORA-48913 caught while writing to trace file "/opt/oracle/app/diag/rdbms/xxxx/xxxx2/trace/xxxx2_diag_9230.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [5000000] reached
Writing to the above trace file is disabled for now on...
Wed Dec 25 06:21:31 2013
ORA-1092 : opitsk aborting process
Wed Dec 25 06:21:31 2013
License high water mark = 33
Dumping diagnostic data in directory=[cdmp_27], requested by (instance=2, osid=9220 (PMON)), summary=[abnormal instance termination].
Instance terminated by PMON, pid = 9220
从上面的信息我们可以看出,smon进程在对object进行事务rollback时,事务(例如114,16)存在异常,导致smon无法进行正常的工作,进而导致smon进程dead,最后pmon 进程将实例终止掉。
这里我们以最开始的一个事务(114,16) 进行举例分析。
通过查看trace 文件我们发现,该事务信息存在异常,如下:
*** ACTION NAME:()
06:21:03.816
Incorrect next uba in kturCurrBackoutOneChg while backing out xid: 0x6fa20 uba: 0x95.20
Undo record:
ktubu redo: slt: 16 rci: 31 opc: 10.22 objn: 25736 objd: 605630 tsn: 4
Undo type:
Regular undo
Undo type:
Last buffer split:
Tablespace Undo:
index undo for leaf key operations
compat bit: 4 (post-11) padding: 1
Dump kdilk : itl=44, kdxlkflg=0x1 sdc= indexid=0x5402d1e block=0x
(kdxlpu): purge leaf row
07 c6 02 16 37 18 4c 21 06 04 c0 1c cf 00 1b
Undo block: tsn 0xe rdba: 0x3288715c
Dump of buffer cache at level 4 for tsn=14, rdba=
BH (0x833dc08e0) file#: 202 rdba: 0x3288715c (202/553308) class: 244 ba: 0x833a70000
set: 144 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
dbwrid: 7 obj: -1 objn: 0 tsn: 14 afn: 202 hint: f
hash: [0x9cd25d2b8,0x9cd25d2b8] lru: [0x833dc0b40,0x9d24f9da8]
ckptq: [NULL] fileq: [NULL] objq: [0x833dc0b68,0x9a7c8aaf0] objaq: [0x833dc0b78,0x9a7c8aae0]
st: SCURRENT md: NULL tch: 1 atm: ,
flags: affinity_lock
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
Data block dump: tsn: 0x4 rdba: 0x5403053
Dump of buffer cache at level 3 for tsn=4, rdba=
BH (0x833b46e18) file#: 21 rdba: 0x/12371) class: 1 ba: 0x
set: 150 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
dbwrid: 5 obj: 605630 objn: 25736 tsn: 4 afn: 21 hint: f
hash: [0x9d5eed5ee3068] lru: [0x833bd24fc7a8]
ckptq: [NULL] fileq: [NULL] objq: [0xx] objaq: [0xx]
st: XCURRENT md: NULL tch: 1 atm: ,
flags: affinity_lock
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 4 rdba: 0x/12371)
scn: 0x0c25.0952cb4d seq: 0x02 flg: 0x04 tail: 0xcb4d0602
frmt: 0x02 chkval: 0xb93c type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
从trace的内容我们可以看出smon 进程rollback时,发现该事务回滚时访问的uba的地址跟需要信息不匹配或者相关信息不正确,即该undo block中的信息可能异常异常。 XID和UBA的结构解释如下:
0&#215;6fa20
:回滚段编号,转换后为114,说明该事务使用的回滚段是第114号回滚段
:事务槽编号(slot),转换后为16,说明对应undo segment header中的transaction table记录中的index是16
0006fa20 :序号(同一个事务可能具有多个SCN,用于区分一个事务中的多个操作)
uba: 0x95.20
3288715c: undo block地址,为16进制,转换为10进制为,即(202/553308)
sequence number
undo record编号
根据前面的信息判断,Oracle 利用undo block对事务进行rollback时,发现undo block中对应的记录不对,因此抛出ora-00600 [ktubko_1] 错误。我们知道Oracle 中的事务,必须保持其完整性,即一个事务要么成功,要么失败,不能只完成其中的部分操作(如果一个事务涉及到多个操作的 话)。那么能否实现只对事务中的部分操作进行rollback呢? 如果这个case中,能实现部分操作的rollback,那么就可以顺利打开数据库。当然这里我的处理方式是通过100513 event来屏蔽Smon进程的rollback操作,open之后再去维护相关的Index。
我们知道smon 在对一个事务进行回滚时,如果该事务涉及到多个操作,那么如何去保证顺序的回滚呢 ?其实是根据undo chain来的。
当rollback到rci为0时就结束该事务的rollback。 这里我举个测试例子,针对分区表带索引的操作。 当分区表的数据操作时,
那么必然会维护Index,因此同一个操作,在undo record中应该有2个record记录,下面我们来测试下,能否是否只回滚该事务
的部分操作,如下是我的测试例子,生产库不要随便玩~~~~
针对分区表的delete操作,如上述的例子,很简单,由于客户这里遇到的情况是insert,下面我来看下insert的情况。
++++测试delete
SQL& create table test_1227 partition by hash(object_id) partitions 5 as select * from dba_
Table created.
SQL& create unique index pk_test_1227
on test_1227 (object_id)
Index created.
SQL& select object_id,data_object_id from dba_objects where object_name=upper('test_1227');
OBJECT_ID DATA_OBJECT_ID
---------- --------------
6 rows selected.
select object_id,data_object_id from dba_objects where object_name=upper('pk_test_1227');
OBJECT_ID DATA_OBJECT_ID
---------- --------------
6 rows selected.
SQL& select count(1) from test_1227 where object_id&10;
----------
SQL& select
dbms_rowid.rowid_block_number(rowid) blk# from test_1227
where object_id & 10;
----------
8 rows selected.
select distinct dbms_rowid.rowid_relative_fno(rowid) file# from test_1227;
----------
delete from test_1227 where object_id & 10;
8 rows deleted.
SQL& alter system flush buffer_
System altered.
select xidusn,xidslot,xidsqn,ubablk,ubafil,ubarec,start_scn from v$
---------- ---------- ---------- ---------- ---------- ---------- ----------
我们可以看到该事务涉及的undo block为file 6 block 420.
+++++session 2
SQL& conn /as sysdba
Connected.
SQL& oradebug setmypid
Statement processed.
SQL& alter session set tracefile_identifier=10;
Session altered.
SQL& alter system dump datafile 6 block 420;
System altered.
SQL& oradebug tracefile_name
/home/ora11g/diag/rdbms/roger/roger/trace/roger_ora_25146_10.trc
该undo block的信息如下:
********************************************************************************
xid: 0x00af0
seq: 0xea4 cnt: 0xf
flg: 0x0000
Rec Offset
Rec Offset
Rec Offset
Rec Offset
Rec Offset
---------------------------------------------------------------------------
0x01 0x1f60
0x02 0x1ed4
0x03 0x1e6c
0x04 0x1d68
0x05 0x1c90
0x06 0x1bc0
0x07 0x1aec
0x08 0x1a0c
0x09 0x193c
0x0a 0x1868
0x0b 0x1790
0x0c 0x172c
0x0d 0x16c8
0x0e 0x1638
0x0f 0x15a8
...........
...........省略部分内容
*-----------------------------
* Rec #0xd
objn: 14636)
objd: 83510
tblspc: 6(0x)
10 (Index)
Undo type:
Regular undo
Last buffer split:
Temp Object:
Tablespace Undo:
*-----------------------------
index undo for leaf key operations
compat bit: 4 (post-11) padding: 1
0xffff.000. uba: 0x0.00
scn: 0x0000.00bce6df
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x14077ca block=0x014077cc
(kdxlre): restore leaf row (clear leaf delete flags)
keydata/bitmap: (6):
01 40 80 12 00 03
*-----------------------------
* Rec #0xe
objn: 14637)
objd: 83511
tblspc: 6(0x)
10 (Index)
Undo type:
Regular undo
Last buffer split:
Temp Object:
Tablespace Undo:
*-----------------------------
index undo for leaf key operations
compat bit: 4 (post-11) padding: 1
0xffff.000. uba: 0x0.00
scn: 0x0000.00bce6ee
Dump kdilk : itl=2, kdxlkflg=0x25 sdc=0 indexid=0x14077fa block=0x014077fc
(kdxlre): restore leaf row (clear leaf delete flags)
number of keys: 3
key sizes:
02 c1 03 02 c1 06 02 c1 09
keydata/bitmap: (18):
01 40 78 12 00 0d 01 40 78 12 00 06 01 40 78 12 00 0a
selflock: (1):
bitmap: (1):
*-----------------------------
* Rec #0xf
objn: 14638)
objd: 83512
tblspc: 6(0x)
10 (Index)
Undo type:
Regular undo
Last buffer split:
Temp Object:
Tablespace Undo:
*-----------------------------
index undo for leaf key operations
compat bit: 4 (post-11) padding: 1
0xffff.000. uba: 0x0.00
scn: 0x0000.00bce6fd
Dump kdilk : itl=2, kdxlkflg=0x25 sdc=0 indexid=0x1408c2a block=0x01408c2c
(kdxlre): restore leaf row (clear leaf delete flags)
number of keys: 3
key sizes:
02 c1 04 02 c1 05 02 c1 08
keydata/bitmap: (18):
01 40 84 12 00 02 01 40 84 12 00 0f 01 40 84 12 00 05
selflock: (1):
bitmap: (1):
End dump data blocks tsn: 8 file#: 6 minblk 420 maxblk 420
+++++++测试insert
--session 1
SQL& insert into test_1227 select * from dba_objects where object_id=5;
1 row created.
SQL& select xidusn,xidslot,xidsqn,ubablk,ubafil,ubarec,start_scn from v$
---------- ---------- ---------- ---------- ---------- ---------- ----------
SQL& alter system flush buffer_
System altered.
---session 2
SQL& alter session set tracefile_identifier=20;
Session altered.
alter system dump datafile 6 block 307;
System altered.
oradebug tracefile_name
/home/ora11g/diag/rdbms/roger/roger/trace/roger_ora_25146_20.trc
此时该undo block的dump如下:
tart dump data blocks tsn: 8 file#:6 minblk 307 maxblk 307
Block dump from cache:
Dump of buffer cache at level 4 for tsn=8, rdba=
BH (0x24ff9164) file#: 6 rdba: 0x/307) class: 52 ba: 0x24f7e000
set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
dbwrid: 0 obj: -1 objn: 0 tsn: 8 afn: 6 hint: f
hash: [0x314b81d8,0x314b81d8] lru: [0x247e4e44,0x21bf7440]
lru-flags: on_auxiliary_list
ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
st: FREE md: NULL tch: 0 lfb: 33
cr pin refcnt: 0 sh pin refcnt: 0
Block dump from disk:
buffer tsn: 8 rdba: 0x/307)
scn: 0x0000.00bceb5f seq: 0x02 flg: 0x00 tail: 0xeb5f0202
frmt: 0x02 chkval: 0x0000 type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
*-----------------------------
* Rec #0x33
objn: 14631)
objd: 83505
tblspc: 6(0x)
Undo type:
Regular undo
Begin trans
Last buffer split:
Temp Object:
Tablespace Undo:
rdba: 0xExt idx: 0
*-----------------------------
uba: 0xe8e.31 ctl max scn: 0x0000.00bce7df prv tx scn: 0x0000.00bce80b
txn start scn: scn: 0x0000.00bceb5f logon user: 86
prev brb: 0 prev bcl: 0
KDO undo record:
compat bit: 4 (post-11) padding: 1
KDO Op code: QMD row dependencies Disabled
xtype: XA flags: 0x
maxfr: 4858
tabn: 0 lock: 0 nrow: 1
slot[0]: 0
*-----------------------------
* Rec #0x34
objn: 14637)
objd: 83511
tblspc: 6(0x)
10 (Index)
Undo type:
Regular undo
Last buffer split:
Temp Object:
Tablespace Undo:
*-----------------------------
index undo for leaf key operations
compat bit: 4 (post-11) padding: 1
0x00af0 uba: 0x.0ea4.0e
---这里的uba不是当前的,是上一次的。
scn: 0x0000.00bce966
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x14077fa block=0x014077fc
----indexid是段头block,后面的block是当前记录所在的block.
(kdxlpu): purge leaf row
既然我们知道Oracle是根据rci进行回滚的,那么针对该事务,涉及到2个操作,第1个是Rec 0&#215;34是针对index的操作。
第2个操作是Rec 0&#215;33,这是针对该index所在的分区表的操作。 我们知道这是一个完整的事务,那么能否实现只回滚第1个操作,因为后面的
record 可能存在问题或异常,导致smon无法正常完成。 如果能实现只回滚部分事务,那么就可以顺利打开数据库。
实际上要实现这一点,很简单,我们仅仅需要修改rci值即可实现,当然,这样操作,实际上就牺牲了事务的完整性.
BBED& set dba 0x
BBED& map /v
File: /home/ora11g/cheshi_bbed/undotbs.dbf (6)
Block: 307
------------------------------------------------------------
struct kcbh, 20 bytes
ub1 type_kcbh
ub1 frmt_kcbh
ub1 spare1_kcbh
ub1 spare2_kcbh
ub4 rdba_kcbh
ub4 bas_kcbh
ub2 wrp_kcbh
ub1 seq_kcbh
ub1 flg_kcbh
ub2 chkval_kcbh
ub2 spare3_kcbh
struct ktubh, 120 bytes
struct ktubhxid, 8 bytes
ub2 ktubhseq
ub1 ktubhcnt
ub1 ktubhirb
ub1 ktubhicl
ub1 ktubhflg
ub2 ktubhidx[53]
ub1 freespace[1272]
ub1 undodata[6776]
ub4 tailchk
BBED& d /v offset 1412 count 92
File: /home/ora11g/cheshi_bbed/undotbs.dbf (6)
Block: 307
Offsets: 1412 to 1503
-------------------------------------------------------
l .... .....ge7F..
++++374601 表示objn
00 0a160f33 l 7F.............3
++++374601 表示objd,
06: 表示tblspc,即使表空间编号
l ..............
++++a0000 表示XID
f00a1 a40e0e00
l ..........
++++ae0e 表示UBA
fa774001 fc774001 l f榧.....鷚@.黽@.
++++fc774001 为该Index block的DBA地址
0b7bf 02c1066d
l ......房.m
++++02c106为键值的前镜像
&16 bytes per line&
对我们来讲关键的地方是:0a160f33 正确的顺序是:330f160a 其中,33表示rci值,0f是slot,16是opcode,0a表示Layer 编号值. 下面我们来试试,能否实现我们的需求:
BBED& modify /x 00 offset 1443
File: /home/ora11g/cheshi_bbed/undotbs.dbf (6)
Block: 307
Offsets: 1443 to 1474
------------------------------------------------------------------------
000000cb 0a040d00 a00 00ae0e
&32 bytes per line&
BBED& sum apply
Check value for File 6, Block 307:
current = 0x0c06, required = 0x0c06
BBED& verify
DBVERIFY - Verification starting
FILE = /home/ora11g/cheshi_bbed/undotbs.dbf
BLOCK = 307
DBVERIFY - Verification complete
Total Blocks Examined
Total Blocks Processed (Data) : 0
Total Blocks Failing
(Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing
(Index): 0
Total Blocks Empty
Total Blocks Marked Corrupt
Total Blocks Influx
Message 531
product=RDBMS; facility=BBED
++++将文件copy到ASM磁盘组中,启动数据库.
ASMCMD& cp /home/ora11g/cheshi_bbed/undotbs.dbf +DATA1/roger/undotbs.dbf
copying /home/ora11g/cheshi_bbed/undotbs.dbf -& +DATA1/roger/undotbs.dbf
++++启动数据库
Database altered.
SQL& conn roger/roger
Connected.
SQL& @?/rdbms/admin/utlvalid.sql
Table created.
analyze table test_1227 validat
analyze table test_1227 validate structure cascade
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
SQL& set autot off
SQL& select /*+full(t) */ * from test_1227 t where object_id=5;
------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
SUBOBJECT_NAME
OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE
------------------------------ ---------- -------------- -------------------
LAST_DDL_ TIMESTAMP
--------- --------- ------------------- ------- - - - ----------
EDITION_NAME
------------------------------
------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
SUBOBJECT_NAME
OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE
------------------------------ ---------- -------------- -------------------
LAST_DDL_ TIMESTAMP
--------- --------- ------------------- ------- - - - ----------
EDITION_NAME
------------------------------
05-SEP-10 05-SEP-10 :15:39:54 VALID
SQL& set autot on
select * from test_1227 where object_id=5;
no rows selected
Execution Plan
----------------------------------------------------------
Plan hash value:
-------------------------------------------------------------------------------------------------------------------
| Operation
| Bytes | Cost (%CPU)| Time
| Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------
0 | SELECT STATEMENT
(0)| 00:00:01 |
PARTITION HASH SINGLE
(0)| 00:00:01 |
TABLE ACCESS BY LOCAL INDEX ROWID| TEST_1227
(0)| 00:00:01 |
INDEX UNIQUE SCAN
| PK_TEST_1227 |
(0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("OBJECT_ID"=5)
Statistics
----------------------------------------------------------
recursive calls
db block gets
consistent gets
physical reads
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
我们可以看到,顺利打开数据库。 你会发现我们前面最开始insert了一条记录,通过全表扫描能够查询到,如果
走Index就不行。因为Index 中的记录被smon 进程rollback掉了。注意,如果在最开始的操作中,如果没有flush buffer_cache,
那么可能记录没有写到table中去,仍然会查询不到。
如果然而这种情况下,如果你去对表进行校验,会出现错误类似如下。我们正确的做法是,
将Index 进行重建,建议进行drop,然后create。 当然,这里如下你去看trace,会看到类似如下的内容:
row not found in index tsn: 6 rdba: 0x014077fa
env [0xbfe0cec8]: (scn: 0xc5
xid: 0x00000
uba: 0x0.00
statement num=0
parent xid: 0x00000
st-scn: 0x0
i-scn: 0x0
ma-scn: 0xbeb
col 0; len 2; (2):
Block header dump:
Object id on Block? Y
seg/obj: 0x14631
csc: 0x00.bd4044
typ: 1 - DATA
bdba: 0x1407804 ver: 0x01 opc: 0
data_block_dump,data header at 0x
===============
tsiz: 0x1f98
hsiz: 0x14
flag=--------
fseo=0x1f4c
avsp=0x1f38
tosp=0x1f38
0xe:pti[0]
0x12:pri[0]
offs=0x1f4c
block_row_dump:
tab 0, row 0, @0x1f4c
tl: 76 fb: --H-FL-- lb: 0x0
43 4c 55 24
54 41 42 4c 45
78 6e 09 05 10 28 37
78 6e 09 05 10 28 37
32 30 31 30 2d 30 39 2d 30 35 3a 31 35 3a 33 39 3a 35 34
56 41 4c 49 44
col 10: [ 1]
col 11: [ 1]
col 12: [ 1]
col 13: [ 2]
end_of_block_dump
kdgDump: tsn=6 tabn=0
Current Row Piece: rdba=0x slot=0
Head Row Piece:
rdba=0x slot=0
kdgDumpRedo: dump redo on table/index mismatch:
table block tsn=6 rdba=0x index objn=83511
head rowid 0x0
*************************************
很明显,牺牲事务的完整性之后,这个table和Index的信息不一致了。当然,我们要做的仅仅是重构Index即可。
如果是有针对table的操作,那么可能会丢失数据,需要权衡。
Tags: , , , , ,
Posted in ,
on 十二月 27, 2013}

我要回帖

更多关于 commit后如何rollback 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信