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

Yong Huang

最初由 oraclerain 发布
[B]Flag = 0x06 ==> 0x04 + 0x02 { Check Value stored in the block + Delayed Logging Change }
但是不知他的确实含义是什么？
...
The block was corrupt because the tail of the block was not in sync with the head of the block in the cache layer.
...[/B]

Thanks. But I thought OP (original poster) oraclerain's message showed that head and tail of the block did match.

Why not tell us what Oracle document (Note ID or Bug report ID) you quoted that from?

Yong Huang

oraclerain

ok 我觉得METALINK上交流不是很顺畅 https://metalink.oracle.com/meta ... ODE:4998315.992,156 －这是那个链接 ，看看版主高见

Yong Huang

最初由 oraclerain 发布
[B]https://metalink.oracle.com/meta ... ODE:4998315.992,156 [/B]

I think you have some higher privilege to access Metalink documents. When I click the link, I get "ERROR: A valid Support Identifier (CSI) is required for this action."

Is it OK you email me the document? yong321@yahoo.com.

Yong Huang

biti_rainy

最初由 Yong Huang 发布
[B]

I think you have some higher privilege to access Metalink documents. When I click the link, I get "ERROR: A valid Support Identifier (CSI) is required for this action."

Is it OK you email me the document? yong321@yahoo.com.

Yong Huang [/B]

那是楼主自己开的一个 SR

oraclerain

嗯 由于版主对此不是很清楚 所以在METALINK上开了一个SR  现在METALINK还没完全解释清楚，不过他有的解释和开始我所推论的有些类似

Yong Huang

最初由 oraclerain 发布
[B]还有从一下也可以看出这个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
[/B]

I took another look at your header dump. According to "Scaling Oracle8i" pp.365-6 (http://www.scaleabilities.co.uk/content/view/21/50) or other sources:

(1) last 2 bytes of SCN should match first 2 bytes of tail;
(2) the 3rd byte of tail should be equal to type;
(3) the last byte of tail should be equal to seq;

You interpreted (1) and (2) correctly. But you thought the last byte of tail should be equal to flg, not seq. Where do you get that info from?

I don't know what you mean by "DBV工具检查仅仅说该块被标识为坏块，但是没有检查有坏块". Why not show us exactly what dbv says? I'm guessing the reason dbv can't find the bad block is that the three rules listed above are all met. But at the same time, dbv also detects this block is bad according to the other two criteria:

(4) SCN is completely 0's;
(5) seq and therefore the last byte of tail are 0xff.

(4) and (5) are secondary, in the sense that the block was found corrupt first by a process according to rules (1)-(3). The process modifies SCN and seq (and the last byte of tail). Subsequent check of the block only needs to go by rules (4) and (5). Once SCN and seq are modified, we no longer know what the original values were like.

This is all my understanding. May well be wrong.

Yong Huang

d.c.b.a

[php]
ub1  matchBlockTail(BLOCK *block)
{
  switch(block->order)
  {
    case BYTE_ORDER_LITTLE:
      if(block->buf[0x0e] == block->buf[block->size - 4] &&
         block->buf[0x00] == block->buf[block->size - 3] &&
         block->buf[0x08] == block->buf[block->size - 2] &&
         block->buf[0x09] == block->buf[block->size - 1] )
        return 0;
      break;
    case BYTE_ORDER_BIG:
      if(block->buf[0x0e] == block->buf[block->size - 1] &&
         block->buf[0x00] == block->buf[block->size - 2] &&
         block->buf[0x0b] == block->buf[block->size - 3] &&
         block->buf[0x0a] == block->buf[block->size - 4] )
        return 0;
      break;
  }
  return 1;
}
[/php]

这个函数返回值为0时是match的, 这是我AUL中的代码.

oraclerain

(1) last 2 bytes of SCN should match first 2 bytes of tail;
(2) the 3rd byte of tail should be equal to type;
(3) the last byte of tail should be equal to seq;
－－－YES
所以tail标记和块头的三个字段组合是相等的（开始我以为中间的那个TYPE FLAG是块头的那个FLG=0X04的那个，实际上是type: 0x06=trans data）

I don't know what you mean by "DBV工具检查仅仅说该块被标识为坏块，但是没有检查有坏块". Why not show us exactly what dbv says? I'm guessing the reason dbv can't find the bad block is that the three rules listed above are all met. But at the same time, dbv also detects this block is bad according to the other two criteria:

(4) SCN is completely 0's;
(5) seq and therefore the last byte of tail are 0xff.

(4) and (5) are secondary, in the sense that the block was found corrupt first by a process according to rules (1)-(3). The process modifies SCN and seq (and the last byte of tail). Subsequent check of the block only needs to go by rules (4) and (5). Once SCN and seq are modified, we no longer know what the original values were like.
－－－你这个就和我猜测的类似，所以想证实

oracle@GCRMDBRcv:/oraclelog/bosscrm1/bdump>dbv file=/dev/rcrm1vg1_4_147 blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Wed Dec 21 10:26:19 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

DBVERIFY - Verification starting : FILE = /dev/rcrm1vg1_4_147

DBV-00200: Block, dba 1656966527, already marked corrupted


DBVERIFY - Verification complete

Total Pages Examined         : 524032
Total Pages Processed (Data) : 518075
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 3551
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2406
Total Pages Marked Corrupt   : 0  －－－这个地方为0了，如果确实有逻辑坏块的就有数字了
Total Pages Influx           : 0
Highest block SCN            : 7788561635836 (1813.1785928188)
oracle@GCRMDBRcv:/oraclelog/bosscrm1/bdump>

Yong Huang

最初由 d.c.b.a 发布
[B][php]
ub1  matchBlockTail(BLOCK *block)
...[/php]

这个函数返回值为0时是match的, 这是我AUL中的代码. [/B]

Thanks for showing your source code. Your conclusion is equivalent to dbv's

Total Pages Marked Corrupt : 0

and it's not equivalent to

DBV-00200: Block, dba 1656966527, already marked corrupted

That is, if SCN is all 0's and seq is 0xff, your code still thinks it's OK. Perhaps somewhere else in your AUL has that logic?

Yong Huang

d.c.b.a

最初由 Yong Huang 发布
[B]

Thanks for showing your source code. Your conclusion is equivalent to dbv's

Total Pages Marked Corrupt : 0

and it's not equivalent to

DBV-00200: Block, dba 1656966527, already marked corrupted

That is, if SCN is all 0's and seq is 0xff, your code still thinks it's OK. Perhaps somewhere else in your AUL has that logic?

Yong Huang [/B]

I did not check the seq value, I should add it to my code.

But I have another question for block checking. I think oracle will check the checksum value before check the seq byte, checksum value is more important to check the block infracture.

http://www.anysql.net/2005/12/dbblock_check_01.html