Oracle Dump 分析学习总结

简单分析dump出来的oracle数据块

一．dump数据块
oracle的rowid中包含着这条数据对象号，数据文件号，数据文件中的块号以及块中的行号，并且这些都


可以通过dbms_rowid这个包转成具体的数字出来
 
SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid) as file#,dbms_rowid.ROWID_BLOCK_NUMBER


(rowid) as block#,dbms_rowid.ROWID_ROW_NUMBER(rowid) as row#,a.* from paololiu.test1 a; 
 
     FILE#     BLOCK#    ROW# AAA   BBB
---------- ---------- ---------- ----- --------------------------------------------------
 6  131       0 abc   abc
 6  131       1 111   111
 6  131       2 ab12  ab12
 
可以看tset1表中的三条记录都在第6号文件的131号块上，并分别在这个块的第0,1,2行上。
通过dump命令就可以把这整个块都dump出来的：
 
SQL> alter system dump datafile 6 block 131;
 
System altered.
 
dump出来的文件在user_dump_dest参数设定的目录内，以_ora_.trc为格式的名字。其中spid指当前sid


所对应的操作系统的进程号，可以通过以下语句获得：
 
SQL> select p.spid from v$session s,v$process p where s.paddr=p.addr and s.sid in (select 


userenv('sid') from dual);
 
SPID
------------------------
2413
 
通过vi就可以打开刚才dump出来的trc文件了，在最下面就可以看到那三条记录了
 
block_row_dump:
tab 0, row 0, @0x1f8b
tl: 13 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 5]  61 62 63 20 20
col  1: [ 3]  61 62 63
tab 0, row 1, @0x1f7e
tl: 13 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 5]  31 31 31 20 20
col  1: [ 3]  31 31 31
tab 0, row 2, @0x1f70
tl: 14 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 5]  61 62 31 32 20
col  1: [ 4]  61 62 31 32
end_of_block_dump
 
另外同样也可以通过dump函数来获得这些二进制文件的值（前面trc文件显示的是16进制的，这里显示的


是10进制的）：
 
SQL> select a.*,dump(aaa) as dump1,dump(bbb) as dump2 from test1 a;
 
AAA   BBB DUMP1  DUMP2
----- ---------- -------------------------------- --------------------------------
abc   abc Typ=96 Len=5: 97,98,99,32,32  Typ=1 Len=3: 97,98,99
111   111 Typ=96 Len=5: 49,49,49,32,32  Typ=1 Len=3: 49,49,49
ab12  ab12 Typ=96 Len=5: 97,98,49,50,32  Typ=1 Len=4: 97,98,49,50
 
二．分析dump出来的数值
 
刚才那张表的数据结构如下：
SQL> desc test1;
 Name   Null?    Type
 ----------------------------------------- -------- ----------------------------
 AAA    CHAR(5)
 BBB    VARCHAR2(50)
 
这里可以看到typ=96代表char类型，而typ=1代表varchar2类型。后面的数值则对应的是ascii表的值，


其中97是a,98是b,99是c，49是1,50是2。还有可以看到char类型后面还有一些32则对应的是空格，填充


剩余字符串长度。
 
这里显示的是字符串，而数值型就相对比较复杂了
 
1.数值：123456
SQL> select dump(123456) as dump1 from dual;
 
DUMP1
--------------------------------
Typ=2 Len=4: 195,13,35,57
 
195-193=2
193是个常数值，第一位的数字195去减193得到一个指数值2


13-1=12,12*100^2=120000
35-1=34,34*100^1=3400
57-1=56,56*100^0=56
这里-1前面的就是dump出来的后面几位的值，依次分别是13,35,57，用他们减掉一个常数值1以后再依次


乘以100的递减指数倍
 
sum=120000+3400+56=123456
再将它们相加就可以得到原来的值了
 
 
 
2.数值：123456.789
SQL> select dump(123456.789) as dump1 from dual;
 
DUMP1
--------------------------------
Typ=2 Len=6: 195,13,35,57,79,91
 
其实小数的算法和前面的整数一样的：
a.用第一位195减掉193得到指数值
195-194=2
 
b.后面几位分别乘以相对应的100的递减的指数倍
13-1=12；12*100^2=120000
35-1=34；34*100^1=3400
57-1=56；56*100^0=56
79-1=78；78*100^-1=0.78
91-1=90；90*100^-2=0.09
 
c.最后相加
120000+3400+56+0.78+0.9=123456.789
 
 
3.数值：-98765.4321
SQL> select dump(-98765.4321) as dump1 from dual;
 
DUMP1
------------------------------------------------------------
Typ=2 Len=7: 60,92,14,36,58,80,102
 
负数的算法和前面的正数差不多，只是几个常数需要换一下
a.指数算法稍有区别：用常数62减去第一位等到指数值
62-60=2
 
b.后面的是减去常数101后再乘以100的递减指数倍
92-101=-9；-9*100^2=-90000
14-101=-87；-87*100^1=-8700
36-101=-65；-65*100^0=-65
58-101=-43；-43*100^-1=-0.43
80-101=-21；-21*100^-2=-0.0021
最后一位102放弃
 
c.相加后得到相应的数值：
-90000-8700-65-0.43-0.0021=-98765.4321
========

DUMP块的分析

Dump file C:\oracle\admin\ORCL\udump\ORA03560.TRC
Thu Mar 12 15:45:29 2009
ORACLE V8.1.7.0.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Instance name: orcl


Redo thread mounted by this instance: 1


Oracle process number: 16


Windows thread id: 3560, image: ORACLE.EXE




*** 2009-03-12 15:45:29.687
*** SESSION ID:(17.1166) 2009-03-12 15:45:29.671
Start dump data blocks tsn: 0 file#: 1 minblk 60446 maxblk 60446
buffer tsn: 0 rdba: 0x0040ec1e (1/60446)


-- tsn 是表空间号  rdba是相对数据地址（转成二进制 前十位是相对文件号，后22位是数据块号）


scn: 0x0000.0008d355 seq: 0x03 flg: 0x04 tail: 0xd3550603


--SCN为SCN Base=0008,SCN Wrap=d355,seq：scn的变化序列
--尾区版本号为tail: 0xd3550603(tail=SCN Wrap: d355  + type: 0x06+ seq: 0x03)


frmt: 0x02 chkval: 0x3f39 type: 0x06=trans data
-- frmt: 0x02 代表该BLOC是UNDO BLOCK 
--flg：标识：   0x01  new block  - zeroed  data area
                0x02  delayed logging change advanced  scn/seq
                0x04  check value saved -block xor's to zero
                0x08  temporary block
 
Block header dump:  0x0040ec1e
 Object id on Block? Y
 seg/obj: 0x60f7  csc: 0x00.8d355  itc: 1  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
     
 ---seg/obj 对象ID值 
 --csc(SCN at last Block CleanOut): 0x00.8d355表示最后一次块清除(Block CleanOut)时候的SCN
 --itc 表示Number of itl slots  对应v$transaction 中的XINDUSN
 
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   xid:  0x0001.022.00000389    uba: 0x008012f0.0186.16  ----    3  fsc 0x0000.00000000


---xid = XINDUSN+ XINSLOT+XIDSQN V$transaction中的字段）
--uba = 0x008012f0.UBASQN.UBAREC 前面的一个16进制数可以用来计算得到UBAFILE，UBABLK
--DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(TO_NUMBER('0x008012f0','XXXXXXXXXX'))
--dbms_utility.data_block_address_block(to_number('0x008012f0','xxxxxxxx')) 
--Lck 应该是锁定的行数


data_block_dump
===============
tsiz: 0xfb8
hsiz: 0x18
pbl: 0x0e4c6c44
bdba: 0x0040ec1e
flag=-----------
ntab=1
nrow=3
frre=-1
fsbo=0x18
fseo=0xe4a
avsp=0xee9
tosp=0xee9
0xe:pti[0] nrow=3 offs=0
0x12:pri[0] offs=0xec3
0x14:pri[1] offs=0xe88
0x16:pri[2] offs=0xe4a
block_row_dump:
tab 0, row 0, @0xec3
tl: 62 fb: --H-FL-- lb: 0x1 cc: 4
col  0: [10]  50 73 79 63 68 6f 6c 6f 67 79
col  1: [14]  49 72 65 6e 65 20 46 72 69 65 64 6d 61 6e
col  2: [15]  46 75 6c 74 6f 6e 20 48 61 6c 6c 20 31 33 33
col  3: [16]  77 61 eb 56 a4 95 4d 5d a1 25 72 a5 e8 21 8d 5d
tab 0, row 1, @0xe88
tl: 59 fb: --H-FL-- lb: 0x1 cc: 4
col  0: [ 7]  48 69 73 74 6f 72 79
col  1: [11]  4a 6f 68 6e 20 57 68 61 6c 65 6e
col  2: [18]  41 70 70 6c 65 67 61 74 65 20 48 61 6c 6c 20 31 34 32
col  3: [16]  1c 69 7d a9 4c 0c 45 a9 9f bb de 31 79 77 29 76
tab 0, row 2, @0xe4a
tl: 62 fb: --H-FL-- lb: 0x1 cc: 4
col  0: [ 7]  45 6e 67 6c 69 73 68
col  1: [13]  4c 79 6e 6e 20 53 61 75 6e 64 65 72 73
col  2: [19]  42 72 65 61 6b 73 74 6f 6e 65 20 48 61 6c 6c 20 32 30 35
col  3: [16]  26 1d a8 2e d8 c1 41 ed ad 73 6a 31 4d 51 76 94
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 60446 maxblk 60446
========

ORACLE SYSTEMDUMP分析

   某日一数据库已经hang住不动了,数据库的版本是oracle 12.1.0.1.发现通过sqlplus正常的连接已经


无法使用了.
整个实例hang住了，如下
[oracle@rac1 ~]$ sqlplus /nolog
SQL*Plus: Release 12.1.0.1.0 Production on Sun Jul 20 01:41:11 2014
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
SQL> conn / as sysdba;
connect命令hang住，无法正常连接


查看alert.log发现很长时间内没有日志抛出了.
Fri Jul 18 09:11:45 2014
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file 


for more details.
Fri Jul 18 10:14:33 2014
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file 


for more details.
Fri Jul 18 13:00:46 2014
Thread 1 advanced to log sequence 42 (LGWR switch)
  Current log# 2 seq# 42 mem# 0: +DATA/tt/redo02.log
Fri Jul 18 15:22:20 2014
Active Session History (ASH) performed an emergency flush. This may mean that ASH is 


undersized. If emergency flushes are a recurring issue, you may consider increasing ASH 


size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size 


is 4194304 bytes. Both ASH size and the total number of emergency flushes since instance 


startup can be monitored by running the following query:
 select total_size,awr_flush_emergency_count from v$ash_info;
Fri Jul 18 22:00:03 2014
 
[oracle@rac1 trace]$ date
Fri Jul 18 23:47:48 CST 2014
 
还好sqlplus提供了一个prelim选项可以连接实例


[oracle@rac1 ~]$ sqlplus -prelim / as sysdba;
SQL*Plus: Release 12.1.0.1.0 Production on Sun Jul 20 01:48:37 2014
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
SQL>
 
对系统进行两次systemdump 266。


[oracle@rac1 ~]$ sqlplus -prelim / as sysdba;
SQL*Plus: Release 12.1.0.1.0 Production on Sun Jul 20 01:48:37 2014
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug dump systemdump 266;
等待90秒
SQL> oradebug dump systemdump 266;
 
[oracle@localhost ~]$ awk -f ass109.awk tt1_ora_2806.trc
Starting Systemstate 1
....................................................................
Starting Systemstate 2
...................................................................
Ass.Awk Version 1.0.9 - Processing tt1_ora_2806.trc
System State 1
~~~~~~~~~~~~~~~~
1:                     
51:                                     
52:                                     
53:                                     
54:                                     
55:                                     
56:                                     
57: 0: waiting for 'Streams AQ: qmn coordinator idle wait' 
58: 0: waiting for 'cursor: pin S'      
     Cmd: Select
59: 0: waiting for 'Streams AQ: qmn slave idle wait' 
60: 0: waiting for 'SQL*Net message from client' 
61: 0: waiting for 'gc freelist'        
     Cmd: Select
62: 0: waiting for 'REPL Capture/Apply: RAC AQ qmn coordinator' 
63: 2: waited for 'Streams AQ: waiting for time management or cleanup tasks' 
64: 0: waiting for 'Streams AQ: load balancer idle' 
69: 0: waiting for 'Space Manager: slave idle wait' 
70: 0: waiting for 'gc freelist'        
     Cmd: Select
71: 0: waiting for 'gc freelist'        
     Cmd: Select
74: 0: waiting for 'gc freelist'        
Blockers
~~~~~~~~
        Above is a list of all the processes. If they are waiting for a resource
        then it will be given in square brackets. Below is a summary of the
        waited upon resources, together with the holder of that resource.
        Notes:
        ~~~~~
         o A process id of '???' implies that the holder was not found in the
           systemstate.
                    Resource Holder State
        Latch sent-location:    ??? Blocker
Object Names
~~~~~~~~~~~~
Latch sent-location:                  last post sent-location: kji.h LINE:
在使用了awk脚本分析后，发现没有很明显的阻塞，看来先只能提SR了.
========