简单分析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.TRCThu 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了.
========