DUMP数据文件中的FLAG标志含义

[复制链接]
查看11 | 回复8 | 2005-2-28 12:57:00 | 显示全部楼层 |阅读模式
请问ORACLE9I中DUMP数据文件的FLAG有3个值,COMMIT,COMMIT UPPER BOUND,ACTIVE AS CSC,
请问这个COMMIT UPPER BOUND是什么意思呀和COMMIT有什么区别呢? 谢!
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
COMMIT UPPER BOUND ---------- commit 的时候没有来得及更改这个block(delayblockcleanout) ,事后cleanout 的时候已经找不到当时对应的scn了,但是,从回滚段中可以得到一个最小的提交scn并且 该事务已经提交肯定小于这个从回滚段中还存在的最小scn。 那么oracle给这个 cleanout 的事务分配一个 从回滚段中找到的最小事务scn。这虽然不准确,但是是安全的,对于数据访问也不构成影响。所以叫 upper bound ,猜测的一个scn的上限。
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
哦 谢谢版主
但是从下可以看出 U的那两行的SCN为0x0000. 并没有从回滚段中分配一个最小的SCN呀,从以上版主的解释可以看出,U的那两行应该不影响任何操作了,也就是说LCK为1仅仅表示那个事务曾经影响是1行,并不表示现在还锁着那1行吧(从数据库上找不出锁)。
还有从一下也可以看出这个DUMP出来的块是坏块(scn: 0x0000.00000000)-数据库也报错1578坏块,但是DBV工具检查仅仅说该块被标识为坏块,但是没有检查有坏块,不知为何。
scn: 0x0000.00000000 seq: 0xff flg: 0x04 tail: 0x000006ff --这个TAIL标识好像也不对,怎么那个06的标识和FLAG的04不对,而且这个FLAG标识应该为06才对吧

scn: 0x0000.00000000 seq: 0xff flg: 0x04 tail: 0x000006ff
frmt: 0x02 chkval: 0xfc28 type: 0x06=trans data
Block header dump:0x62c34d7f
Object id on Block? Y
seg/obj: 0x16ed8csc: 0x715.6a6e03dfitc: 20flg: Etyp: 1 - DATA
brn: 0bdba: 0x62c34d0a ver: 0x01
inc: 0exflg: 0
Itl Xid
Uba FlagLckScn/Fsc
0x01 0x0002.023.000642d80x0182affc.60f3.22C---0scn 0x0714.c8d5580e
0x02 0x0019.00e.00043a2d0x010258ca.4b51.20C---0scn 0x0714.c8d55882
0x03 0x001a.01b.0003e7790x014257e8.4623.0aC---0scn 0x0714.c8d55880
0x04 0x0003.00d.0005237a0x018258f2.5757.2eC---0scn 0x0714.c8d558fb
0x05 0x0006.005.0004ae310x0144c5e4.5843.19C---0scn 0x0714.c8d56531
0x06 0x0017.02c.00080e970x010194be.54a3.05C---0scn 0x0714.ceed95f8
0x07 0x001d.02a.0005bb9c0x0080584e.5a44.05C---0scn 0x0715.0ce25bce
0x08 0x0008.008.000860d30x00806e4a.7bc7.47C---0scn 0x0715.1ddaccf7
0x09 0x0026.013.00024e220x0143d9ed.281c.0cC---0scn 0x0715.20b445d1
0x0a 0x001e.022.0004e7b40x63c10ac4.564a.3aC---0scn 0x0715.3ab13617
0x0b 0x0010.02a.000a660e0x008012f0.909a.2aC---0scn 0x0715.5166bcb6
0x0c 0x0021.025.000434d60x0101dc63.4915.46C---0scn 0x0715.51682c61
0x0d 0x000e.00c.000a79ce0x01007225.9a08.0dC---0scn 0x0715.6a3ab981
0x0e 0x0004.027.0007cd350x01009c4a.8fb9.1aC---0scn 0x0715.6a3abaa2
0x0f 0x0025.018.00030a190x00804d8f.3a40.16C---0scn 0x0715.6a3abaa1
0x10 0x0016.019.000bb76a0x0100f505.9970.0c--U-1fsc 0x0000.6a6e03e6
0x11 0x0003.017.000830d70x00c0ccbc.8eb3.02--U-1fsc 0x0000.6a6e03e5
0x12 0x0019.012.0003e78d0x010353f4.45bf.0fC---0scn 0x0714.ba2a9b4e
0x13 0x0014.00e.000660ae0x0102120d.5a24.19C---0scn 0x0714.c21c1066
0x14 0x0005.013.0004aa440x01803b1b.58d7.1dC---0scn 0x0714.c21c1067
data_block_dump,data header at 0x110290214
===============
tsiz: 0x1de8
hsiz: 0x74
pbl: 0x110290214
bdba: 0x62c34d7f
76543210
flag=--------
ntab=1
nrow=49
frre=-1
fsbo=0x74
fseo=0x7f3
avsp=0x77f
tosp=0x77f
0xe

ti[0]nrow=49 offs=0
0x12

ri[0] offs=0x1d77
0x14

ri[1] offs=0x1d07
0x16

ri[2] offs=0x1c99
0x18

ri[3] offs=0x1c29
0x1a

ri[4] offs=0x1bb8
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
0x10 0x0016.019.000bb76a 0x0100f505.9970.0c --U- 1 fsc 0x0000.6a6e03e6
0x11 0x0003.017.000830d7 0x00c0ccbc.8eb3.02 --U- 1 fsc 0x0000.6a6e03e5
scn 是0x0000.6a6e03e6and 0x0000.6a6e03e5
0x0000是scn的高2位字节,后面4个字节是低4位字节。这样看起来这个itl被使用的历史很久远了。
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
嗯 从以上头部信息可以看出好像整个都不对,seq的值为0XFF--这个是逻辑坏块的标志之一吧(如果正常的话,应该这个最大的值应该减1吧),还有DBV工具是否只检测块头和块尾是否一致,对于块头信息是否正确就不管了?
scn: 0x0000.00000000 seq: 0xff flg: 0x04 tail: 0x000006ff
frmt: 0x02 chkval: 0xfc28 type: 0x06=trans data
Block header dump: 0x62c34d7f
Object id on Block? Y
seg/obj: 0x16ed8 csc: 0x715.6a6e03df itc: 20 flg: E typ: 1 - DATA
brn: 0 bdba: 0x62c34d0a ver: 0x01
inc: 0 exflg: 0
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
seq: 0xff-----是坏块是一种可能吧,假如这个块从来没有被使用过也是一种可能

至于dbv 的校验算法和数据,我没有考究过,不清楚。
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
还有查资料发现块头的Flg含义: Flag (as defined in kcbh.h)
#define KCBHFNEW 0x01 /* new block - zeroed data area */
#define KCBHFDLC 0x02 /* Delayed Logging Change advance SCN/seq */--延迟??
#define KCBHFCKV 0x04 /* ChecK Value saved-block xor's to zero */---??
#define KCBHFTMP 0x08 /* Temporary block
而上面贴出的块头的信息和块尾的TAIL标志是一致的,所以DBV检查不出问题,但是事实上块头的SCN为0,所以报1578的块物理损坏的错误。
但是我又DUMP另一个数据块,发现块头的FLG还有0X06的情况,和资料不符,呵呵
buffer tsn: 7 rdba: 0x62c34d80 (395/216448)
scn: 0x0715.3f5927c3 seq: 0x01 flg: 0x06 tail: 0x27c30601
frmt: 0x02 chkval: 0xa3af type: 0x06=trans data
Block header dump:0x62c34d80
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
高,学习!
回复

使用道具 举报

千问 | 2005-2-28 12:57:00 | 显示全部楼层
Looks like you've done a great deal of research. I took some time to study this (Christmas holiday, plenty of free time to kill!). You may have read Bug:3859770 "ORA-1578 IN-MEMORY BUFFER CORRUPTION". It says "seq: 0xff0x04 + 0x02 { Check Value stored in the block + Delayed Logging Change }
但是不知他的确实含义是什么?
When Oracle first read the block in the Buffer , it detected that this block was fractured an
d hence corrupt.
The block was corrupt because the tail of the block was not in sync with the head of the block in the cache layer.
Oracle then attempted to reread the same block again and still found the corrupt.
At this time , the block was already in the Buffer Cache and as you had db_block_checksum enabled { Fla
g = 0x06 } ,
it marked the block as corrupt so that a subsequent access of the same block should also fail.
The way Oracle marks the block as corrupt is by setting the Sequence Flag to 0xff { Invalid value } and also setting
the SCN of the block to 0x00000000.
Since DBV finds that this block has already been corrupted by the Oracle software in Memory , it does not report this
block as corrupt under the "Total Blocks Corrupt" section.
以上是ORACLE的解释
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行