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

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

35

积分

0

好友

3

主题
1#
发表于 2012-8-7 17:27:45 | 查看: 6288| 回复: 3
老大,有个疑问:


Block header dump:  0x01800087
Object id on Block? Y
seg/obj: 0x1233f  csc: 0x00.d47d7  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1800080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.018.000001f6  0x00c0298b.007e.1e   C---    0  scn 0x0000.000cf7a5
0x02   0x0005.00e.00000299  0x00c0290b.0087.11  C---    0  scn 0x0000.000cf797


BBED> p ktbbhitl
struct ktbbhitl[0], 24 bytes                @44      
   struct ktbitxid, 8 bytes                 @44      
      ub2 kxidusn                           @44       0x0007
      ub2 kxidslt                           @46       0x0018
      ub4 kxidsqn                           @48       0x000001f6
   struct ktbituba, 8 bytes                 @52      
      ub4 kubadba                           @52       0x00c0298b
      ub2 kubaseq                           @56       0x007e
      ub1 kubarec                           @58       0x1e
   ub2 ktbitflg                             @60       0x8000 (KTBFCOM)
   union _ktbitun, 2 bytes                  @62      
      sb2 _ktbitfsc                         @62       0
      ub2 _ktbitwrp                         @62       0x0000
   ub4 ktbitbas                             @64       0x000cf7a5
struct ktbbhitl[1], 24 bytes                @68      
   struct ktbitxid, 8 bytes                 @68      
      ub2 kxidusn                           @68       0x0002
      ub2 kxidslt                           @70       0x0020
      ub4 kxidsqn                           @72       0x000002a4
   struct ktbituba, 8 bytes                 @76      
      ub4 kubadba                           @76       0x00c02634
      ub2 kubaseq                           @80       0x00d4
      ub1 kubarec                           @82       0x17
   ub2 ktbitflg                             @84       0x8000 (KTBFCOM)
   union _ktbitun, 2 bytes                  @86      
      sb2 _ktbitfsc                         @86       22
      ub2 _ktbitwrp                         @86       0x0016
   ub4 ktbitbas                             @88       0x000cf7a7


DUMP出的数据块ITL中的FLAG标志"C---" ,通过BBED查看ktbitflg  为0X8000

通过“C---” 怎么得出的这个0X8000


SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production


3Q。
2#
发表于 2012-8-7 20:54:13
FLAG – status of the txn, ie., commit, uncommitted etc.,

. If the cleanout was performed; that is, the block was modified: The block is flagged as containing delayed-logging cleanout (the flag KTBFUPB in ktbitflg indicates in this case a cleanout at commit time)

Flag – Transaction flag
----         = Uncommitted
        -B--        = The UBA (Undo Block Address) contains undo for this ITL
        --U-        = Committed by fast commits & delayed block cleanout has not occurred
        ---T        = Transaction active at block cleanout SCN
        -C-U- = Block cleaned by delayed block cleanout, and rollback segment info is    overwritten.


必须使用块修改工具BBED来修改存在问题的数据块将ITL事务槽的FLAG从U修改为C(Commit)。

TRANSACTION_COMMITED = 0×08;
TRANSACTION_UPBOUND = 0×02;
TRANSACTION_ACTIVE = 0×01;

Flag= –U- 即TRANSACTION_UPBOUND时flag所占字节为0×02,需要将该字节修改为TRANSACTION_COMMITED = 0×08;


在little endian 下    0x8000 其实 是 0x08  0x00 , 即 C---
你的测试环境是Linux 即little endian

回复 只看该作者 道具 举报

3#
发表于 2012-8-8 09:55:13
多谢 老大      我看看

回复 只看该作者 道具 举报

4#
发表于 2013-7-2 10:03:08
本帖最后由 thinking.qi 于 2013-7-2 10:51 编辑

ML ,最近我也有关于delayed cleanout 的问题,今天搜到这贴了,请问下:
1.itl 的commit flag :“ub2 ktbitflg   @60       0x2001 (KTBFUPB)”  它的最后一位01代表什么呢?
2.关于block 最后一次cleanout scn:
  struct ktbbhcsc, 8 bytes                 @28      
      ub4 kscnbas                           @28       0x0055c92a
      ub2 kscnwrp                           @32       0x0000
这个kscnbas 是最后一次cleanout scn. 我的理解是无论是fast 还是delayed 的cleanout block,这个位置的scn是在块发生改变之前cleanout 时的scn,那么它的值永远 <= block scn(ora_rowscn) ,是这样的吗?

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-29 17:01 , Processed in 0.054152 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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