redo log dump

Graham Thornton在这篇文章中讲述了他亲身经历的两件事，第一件事是这样的：
技术支持部门接到用户电话，在我们的BS应用程序中，页面上保存数据时报错，错误原因是主键冲突。
开发人员认为主键是在打开页面时，从数据库取的一个序列值sequence，开发人员认为oracle数据库发神经了，取的序列重复了，否则不可能主键冲突。[不可能，绝对不可能！][@more@]
作者开始处理这件事情。
这个业务表名是order_lines，在数据库中的对象ID，可以通过OBJ$视图查询到；（9i中可以查dba_objects）是38342；
技术支持部门接到用户电话的时间是15:21
通过这个时间点，作者确定了应该去分析哪一个重做日志；
select * from v$loghist where first_time......;
然后倒出日志文件
alter system dump logfile 。。。；

在trace文件中，搜索关键字“objn: 38342”(obj: in Oracle 7, objn: in Oracle 8 )
找到以下内容：
REDO RECORD - Thread:1 RBA:0x000c66.00000002.012c LEN: 0x01f4 VLD: 0x01
SCN scn: 0x0000.008a710b 07/19/00 15:18:54
CHANGE #1 TYP:0 CLS:15 AFN:2 DBA:0x00800002SCN:0x0000.008a7104 SEQ: 1 OP:5.2
ktudh redo: slt: 0x0003 sqn: 0x00002ec8flg: 0x0012 siz: 84 fbi: 0
uba: 0x00801199.2fd9.10 pxid: xid:0x0000.000.00000000
CHANGE #2 TYP:0 CLS:16 AFN:2 DBA:0x00801199SCN:0x0000.008a7103 SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 724 flg: 0x0012seq: 0x2fd9 rec: 0x10
xid: 0x0002.003.00002ec8
ktubl redo: slt: 3 rci: 0 opc: 11.1 objn: 38342objd: 38342 tsn: 2
Undo type: Regular undo Begin trans Lastbuffer split: No
Temp Object: No
rdba: 0x00000000 prev ctl uba:0x00801199.2fd9.0f
prev ctl max cmt scn: 0x0000.008a22c0 prevtx cmt scn: 0x0000.008a22c2
KDO undo record:
KTB Redo
op: 0x03 ver: 0x01
op: Z
KDO Op code: QMD xtype: XA bdba: 0x00c070a3hdba: 0x00c070a2
itli: 1 ispac: 0 maxfr: 1177
tabn: 0 lock: 0 nrow: 1
slot[0]: 0
CHANGE #3 TYP:0 CLS: 1 AFN:3 DBA:0x00c070a3SCN:0x0000.008a710b SEQ: 4
OP:11.11
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0002.003.00002ec8 uba:0x00801199.2fd9.10
KDO Op code: QMI xtype: XA bdba: 0x00c070a3hdba: 0x00c070a2
itli: 1 ispac: 0 maxfr: 1177
tabn: 0 lock: 1 nrow: 1
slot[0]: 0
tl: 31 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 4] c3 0d 17 4b
col 1: [ 2] c1 02
col 2: [ 5] 30 36 32 31 35
col 3: [ 2] 31 33
col 4: [ 2] 30 31
col 5: [ 2] 34 38
col 6: [ 2] c1 03
col 7: [ 1] 31

注意上面的几个要素，时间15:18:54 表ID38342 前两列是联合主键，内容要转换成数字。

c3 0d 17 4b ----&gt12274
c1 02 ----&gt 1

即在15：18：54 有一条记录保存到这个表中；

接着向下继续搜索，又发现了情况：
REDO RECORD - Thread:1 RBA:0x000c66.00000004.0010 LEN: 0x00ec VLD: 0x01
SCN scn: 0x0000.008a710b 07/19/00 15:19:00
CHANGE #1 TYP:0 CLS:16 AFN:2 DBA:0x00801199SCN:0x0000.008a710b SEQ: 2 OP:5.1
ktudb redo: siz: 68 spc: 568 flg: 0x0022seq: 0x2fd9 rec: 0x12
xid: 0x0002.003.00002ec8
ktubu redo: slt: 3 rci: 17 opc: 11.1 objn: 38342 objd: 38342 tsn: 2
Undo type: Regular undo Last buffer split:No
rdba: 0x00000000
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
op: C uba: 0x00801199.2fd9.10
KDO Op code: QMD xtype: XA bdba: 0x00c070a3hdba: 0x00c070a2
itli: 1 ispac: 0 maxfr: 1177
tabn: 0 lock: 0 nrow: 1
slot[0]: 1
CHANGE #2 TYP:0 CLS: 1 AFN:3 DBA:0x00c070a3SCN:0x0000.008a710b SEQ: 5
OP:11.11
KTB Redo
op: 0x02 ver: 0x01
op: C uba: 0x00801199.2fd9.12
KDO Op code: QMI xtype: XA bdba: 0x00c070a3hdba: 0x00c070a2
itli: 1 ispac: 0 maxfr: 1177
tabn: 0 lock: 1 nrow: 1
slot[0]: 1
tl: 31 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 4] c3 0d 17 4b
col 1: [ 2] c1 02
col 2: [ 5] 30 36 32 31 35
col 3: [ 2] 31 33
col 4: [ 2] 30 31
col 5: [ 2] 34 38
col 6: [ 2] c1 03
col 7: [ 1] 31

同样的数据，在6秒钟后，再次进行insert,因此报主键冲突。
然后和开发人员一起去查问题，开发人员发现页面上的"保存"按钮在点击之后，成功反馈之前，还可以继续点击，终端用户认为没有保存上，继续点击“保存”按钮，导致数据重复提交。
原因即明，修改相当容易。问题得以解决。

现在来看这个案例，大家认为确实是个小问题，redolog的有益功能也由此可见一斑。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/271063/viewspace-1060936/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/271063/viewspace-1060936/