itspace
- 浏览: 960941 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
孤星119：
好熟悉的数据库字段啊， 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace：
quxiaoyong 写道遇到个问题，网上一搜，全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong：
遇到个问题，网上一搜，全他妈这篇文章。你转来转去的有意思吗？
数据库连接错误ORA-28547 -
hctech：
关于version count过高的问题，不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace：
invalid 写道写的不错，我根据这个来安装，有点理解错误了 ...
AIX 配置vncserver
顾名思义，Oracle 进行direct path read和direct path write操作时，将会绕过buffer_cache，直接将数据读至PGA中。Oracle官方文档也似乎这么说。
但事实果真是这样吗？
接下来分2部分测试，首先测试direct path read，我们知道Oracle并行读时将会产生进行direct path read
SQL> alter system flush buffer_cache;
System altered.
SQL> select /*+ parallel(a 10)*/ * from zhoultest a;
835328 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1476512502
--------------------------------------------------------------------------------
-------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| TQ |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------
-------------------------------
| 0 | SELECT STATEMENT | | 832K| 62M| 405 (2)| 00:00:05
| | | |
| 1 | PX COORDINATOR | | | | |
| | | |
| 2 | PX SEND QC (RANDOM)| :TQ10000 | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | PCWC | |
| 4 | TABLE ACCESS FULL| ZHOULTEST | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | PCWP | |
--------------------------------------------------------------------------------
-------------------------------
可以看到buffer_cache中只有segment head
SQL> select a.FILE#,a.BLOCK#,b.EXTENT_ID,b.BLOCK_ID,b.blocks,a.DIRTY from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free';
2
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 5131 0 5129 8 N
SQL> select header_file,header_block from dba_segments where owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST';
HEADER_FILE HEADER_BLOCK
----------- ------------
7 5131
进一步dump segment head
SQL> alter system dump datafile 7 block 5131;
System altered.
可以看到segment head中有HighWater Mark和Extent Map，而Oracle全表扫描时，正是通过Extent Map定位数据块，扫描至高水位以下位置。需要注意的是当表格extent很多时，
不足以放在同一个block中时，就会出现多个区位图块（小表的区位图块和segment head是同一个数据块，如本例），这时就需要一个指针指向下一个区位图块。
用Map Header:: next 0x00000000可以看出，本例中下一个区位图块为空，即只有一个区位图块。
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 118 #blocks: 32896
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0e609 ext#: 117 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32896
mapblk 0x00000000 offset: 117
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0e609 ext#: 117 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32896
mapblk 0x00000000 offset: 117
Level 1 BMB for High HWM block: 0x01c0e20c
Level 1 BMB for Low HWM block: 0x01c0e20c
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01c0140a
Last Level 1 BMB: 0x01c0e20c
Last Level II BMB: 0x01c0140a
Last Level III BMB: 0x00000000
Map Header:: next 0x00000000 #extents: 118 obj#: 72659 flag: 0x10000000
Inc # 0
Extent Map
-----------------------------------------------------------------
0x01c01409 length: 8
0x01c01411 length: 8
0x01c01419 length: 8
0x01c01421 length: 8
。。。
通过以上测试我们可以推断出，Oracle在进行并行表格扫描时，需要将表格头和区位图块载入buffer_cache中，通过读取表格头的高水位标记位
和区位图块的区信息，从而定位表格数据块在数据文件中的位置，进而读取数据。
在测试中我们还同时发现了另外两个现象：
（1）Oracel扫描dba_extents(最终对x$ktfbue表格扫描)时，其实就是去读取区位图块的区信息，通过以下测试可以说明这一点。
通过bbed物理修改位图块信息
BBED> modify 0x0a
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /oradata/mcstar/zhoul01.dbf (0)
Block: 5131 Offsets: 284 to 795 Dba:0x00000000
------------------------------------------------------------------------
0a000000 1114c001 08000000 1914c001 08000000 2114c001 08000000 2914c001
再次查询dba_extents视图，可以观察到数据发生了变化
SQL> select EXTENT_ID,FILE_ID,BLOCK_ID,BLOCKS from dba_extents where SEGMENT_NAME='ZHOULTEST' and OWNER='ZHOUL' order by 1;
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 7 5129 10
（2）Oracle在并行扫描时，将会进行表格级别的checkpoint。
Oracle使用direct path read进行并行查询，即直接从数据文件读取数据至PGA，如果有数据存在于buffer_cache时，势必会影响数据的一致性。所以在在并行扫描时，将会进行表格级别的checkpoint。
以下测试证明了这一点。
首先改变一些数据块
SQL> update zhoultest set name=lower(name) where rownum<10000;
9999 rows updated.
SQL> commit;
Commit complete.
SQL> select count(*) from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
2 and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free' and a.dirty='Y';
COUNT(*)
----------
116
发起一个并行查询
select /*+ parallel(a 10)*/ * from zhoultest a where rownum<0;
再次查询，可以看到dirty数据块已经从buffer_cache中刷往数据文件中。
SQL> /
COUNT(*)
----------
0
进一步dump buffer_cache中，我们注意到了objq，正是通过这个objq，Oracle加快了在buffer_cache中搜索对象的速度，同理ckptq的存在加快了增量checkpoint的内存搜索效率，
fileq的存在加快了表空间checkpoint的内存搜索效率。
SQL> ALTER SESSION SET EVENTS 'immediate trace name buffers level 2';
Session altered.
BH (0x213f5030) file#: 7 rdba: 0x01c0390c (7/14604) class: 1 ba: 0x2128e000
set: 6 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 0 obj: 76226 objn: 76226 tsn: 8 afn: 7
hash: [20fedda0,2a693b68] lru: [22fefd88,213f23b8]
obj-flags: object_ckpt_list
ckptq: [22fed090,2a6e3260] fileq: [2a6e32ec,2a6e32ec] objq: [2603ca30,2603ca30]
st: XCURRENT md: NULL tch: 1
flags: buffer_dirty gotten_in_current_mode redo_since_read
LRBA: [0x9331.ede6.0] HSCN: [0xa00.e7f7af9] HSUB: [1]
buffer tsn: 8 rdba: 0x01c0390c (7/14604)
scn: 0x0a00.0e7f7af9 seq: 0x02 flg: 0x02 tail: 0x7af90602
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
需要注意的是，在Oracle 9i中，并没有objq存在
BH (0x0x53fc77ac) file#: 9 rdba: 0x02410873 (9/67699) class 1 ba: 0x0x5360a000
set: 6 dbwrid: 0 obj: 44558 objn: 44558
hash: [83519fa8,83519fa8] lru: [53fc767c,53fc796c]
LRU flags: moved_to_tail
ckptq: [NULL] fileq: [NULL]
st: XCURRENT md: NULL rsop: 0x(nil) tch: 0
flags: only_sequential_access
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]
buffer tsn: 9 rdba: 0x02410873 (9/67699)
scn: 0x0a00.06200be8 seq: 0x01 flg: 0x04 tail: 0x0be80601
frmt: 0x02 chkval: 0x4d10 type: 0x06=trans data
我们知道drop table时，也会进行表格级别ckpt，当drop table时，需要在buffer_cache中搜寻和这张表格相关的数据块，如果在高并发Oracle9i环境下，极易引起latch争用，
如lacth：cache buffer chain等。
我们知道在insert时，加hint:/*+ append*/将会执行direct path write，即Oracle绕过buffer_cache，直接写往数据文件。是不是Oracle所有的
数据块都绕过buffer_cache都写往数据文件呢？
接下来继续测试direct path write。
为避免干扰，我们从sys.t1读取内容插往zhoultest表格
SQL> explain plan for insert /*+ append*/ into zhoultest select * from sys.t1;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1069440229
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 51050 | 63M| 143 (4)| 00:00:02 |
| 1 | LOAD AS SELECT | ZHOULTEST | | | | |
| 2 | TABLE ACCESS FULL| T1 | 51050 | 63M| 143 (4)| 00:00:02 |
--------------------------------------------------------------------------------
9 rows selected.
SQL> alter system flush buffer_cache;
System altered.
SQL> insert /*+ append*/ into zhoultest select * from sys.t1;
420896 rows created.
SQL> commit;
Commit complete.
我们看到在buffer_cache中除了segment head还出现了其他数据块。
SQL> select a.FILE#,a.BLOCK#,b.EXTENT_ID,b.BLOCK_ID,b.blocks,a.DIRTY from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free';
2
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 5131 0 5129 8 Y
7 5130 0 5129 8 Y
7 24844 101 24841 1024 Y
7 29962 102 29961 1024 Y
7 29964 102 29961 1024 Y
7 29961 102 29961 1024 Y
7 29963 102 29961 1024 Y
7 30986 103 30985 1024 Y
7 30988 103 30985 1024 Y
7 30985 103 30985 1024 Y
7 30987 103 30985 1024 Y
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 32010 104 32009 1024 Y
7 32012 104 32009 1024 Y
7 32009 104 32009 1024 Y
7 32011 104 32009 1024 Y
7 33036 105 33033 1024 Y
7 33033 105 33033 1024 Y
7 33035 105 33033 1024 Y
7 33034 105 33033 1024 Y
7 34057 106 34057 1024 Y
7 34059 106 34057 1024 Y
7 34058 106 34057 1024 Y
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 34060 106 34057 1024 Y
23 rows selected.
进一步dump数据块，可以看出是2级位图块
Dump of Second Level Bitmap Block
number: 230 nfree: 21 ffree: 138 pdba: 0x01c0140b
Inc #: 0 Objd: 72659
opcode:0
xid:
L1 Ranges :
--------------------------------------------------------
0x01c01409 Free: 1 Inst: 1
0x01c01419 Free: 1 Inst: 1
0x01c01429 Free: 1 Inst: 1
0x01c01439 Free: 1 Inst: 1
0x01c01449 Free: 1 Inst: 1
。。。
继续dump其他数据块，看出是1级位图块
SQL> alter system dump datafile 7 block 34060;
System altered.
Dump of First Level Bitmap Block
--------------------------------
nbits : 4 nranges: 1 parent dba: 0x01c0140a poffset: 185
unformatted: 97 total: 256 first useful block: 0
owning instance : 1
instance ownership changed at
Last successful Search
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
Extent Map Block Offset: 4294967295
First free datablock : 159
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Inc #: 0 Objd: 72659
HWM Flag: HWM Set
Highwater:: 0x01c088a8 ext#: 106 blk#: 927 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 21535
mapblk 0x00000000 offset: 106
。。。
通过以上测试我们可以得出以上推论，在进行direct path write时，由于要改变数据块内容，Oracle需要将反映数据块位置状态的L3，L2，L1，SEGMENT_HEAD读至buffer_cache中。
需要注意的是当进行direct path write时，Oracle会将segment的low hwm至high hwm未格式化的block进行格式化操作，即low hwm=high hwm，然后在high hwm之后插数据
直接路径插入之前
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 119 #blocks: 33920
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0f309 ext#: 118 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33916
mapblk 0x00000000 offset: 118
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0ef19 ext#: 118 blk#: 16 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32908
mapblk 0x00000000 offset: 118
Level 1 BMB for High HWM block: 0x01c0ef0c
Level 1 BMB for Low HWM block: 0x01c0ef09
仅直接路径插入一行数据
SQL> insert /*+ append*/ into zhoultest select * from sys.t1 where rownum<2;
1 row created.
SQL> commit;
Commit complete.
再次查看segment head，可以看到high Highwater mask= Low HighWater Mark
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 120 #blocks: 34944
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0f40e ext#: 119 blk#: 5 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33925
mapblk 0x00000000 offset: 119
Disk Lock:: Locked by xid: 0x002a.021.00000822
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0f40e ext#: 119 blk#: 5 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33925
mapblk 0x00000000 offset: 119
Level 1 BMB for High HWM block: 0x01c0f409
Level 1 BMB for Low HWM block: 0x01c0f409
但事实果真是这样吗？
接下来分2部分测试，首先测试direct path read，我们知道Oracle并行读时将会产生进行direct path read
SQL> alter system flush buffer_cache;
System altered.
SQL> select /*+ parallel(a 10)*/ * from zhoultest a;
835328 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1476512502
--------------------------------------------------------------------------------
-------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| TQ |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------
-------------------------------
| 0 | SELECT STATEMENT | | 832K| 62M| 405 (2)| 00:00:05
| | | |
| 1 | PX COORDINATOR | | | | |
| | | |
| 2 | PX SEND QC (RANDOM)| :TQ10000 | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | PCWC | |
| 4 | TABLE ACCESS FULL| ZHOULTEST | 832K| 62M| 405 (2)| 00:00:05
| Q1,00 | PCWP | |
--------------------------------------------------------------------------------
-------------------------------
可以看到buffer_cache中只有segment head
SQL> select a.FILE#,a.BLOCK#,b.EXTENT_ID,b.BLOCK_ID,b.blocks,a.DIRTY from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free';
2
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 5131 0 5129 8 N
SQL> select header_file,header_block from dba_segments where owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST';
HEADER_FILE HEADER_BLOCK
----------- ------------
7 5131
进一步dump segment head
SQL> alter system dump datafile 7 block 5131;
System altered.
可以看到segment head中有HighWater Mark和Extent Map，而Oracle全表扫描时，正是通过Extent Map定位数据块，扫描至高水位以下位置。需要注意的是当表格extent很多时，
不足以放在同一个block中时，就会出现多个区位图块（小表的区位图块和segment head是同一个数据块，如本例），这时就需要一个指针指向下一个区位图块。
用Map Header:: next 0x00000000可以看出，本例中下一个区位图块为空，即只有一个区位图块。
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 118 #blocks: 32896
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0e609 ext#: 117 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32896
mapblk 0x00000000 offset: 117
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0e609 ext#: 117 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32896
mapblk 0x00000000 offset: 117
Level 1 BMB for High HWM block: 0x01c0e20c
Level 1 BMB for Low HWM block: 0x01c0e20c
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01c0140a
Last Level 1 BMB: 0x01c0e20c
Last Level II BMB: 0x01c0140a
Last Level III BMB: 0x00000000
Map Header:: next 0x00000000 #extents: 118 obj#: 72659 flag: 0x10000000
Inc # 0
Extent Map
-----------------------------------------------------------------
0x01c01409 length: 8
0x01c01411 length: 8
0x01c01419 length: 8
0x01c01421 length: 8
。。。
通过以上测试我们可以推断出，Oracle在进行并行表格扫描时，需要将表格头和区位图块载入buffer_cache中，通过读取表格头的高水位标记位
和区位图块的区信息，从而定位表格数据块在数据文件中的位置，进而读取数据。
在测试中我们还同时发现了另外两个现象：
（1）Oracel扫描dba_extents(最终对x$ktfbue表格扫描)时，其实就是去读取区位图块的区信息，通过以下测试可以说明这一点。
通过bbed物理修改位图块信息
BBED> modify 0x0a
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /oradata/mcstar/zhoul01.dbf (0)
Block: 5131 Offsets: 284 to 795 Dba:0x00000000
------------------------------------------------------------------------
0a000000 1114c001 08000000 1914c001 08000000 2114c001 08000000 2914c001
再次查询dba_extents视图，可以观察到数据发生了变化
SQL> select EXTENT_ID,FILE_ID,BLOCK_ID,BLOCKS from dba_extents where SEGMENT_NAME='ZHOULTEST' and OWNER='ZHOUL' order by 1;
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 7 5129 10
（2）Oracle在并行扫描时，将会进行表格级别的checkpoint。
Oracle使用direct path read进行并行查询，即直接从数据文件读取数据至PGA，如果有数据存在于buffer_cache时，势必会影响数据的一致性。所以在在并行扫描时，将会进行表格级别的checkpoint。
以下测试证明了这一点。
首先改变一些数据块
SQL> update zhoultest set name=lower(name) where rownum<10000;
9999 rows updated.
SQL> commit;
Commit complete.
SQL> select count(*) from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
2 and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free' and a.dirty='Y';
COUNT(*)
----------
116
发起一个并行查询
select /*+ parallel(a 10)*/ * from zhoultest a where rownum<0;
再次查询，可以看到dirty数据块已经从buffer_cache中刷往数据文件中。
SQL> /
COUNT(*)
----------
0
进一步dump buffer_cache中，我们注意到了objq，正是通过这个objq，Oracle加快了在buffer_cache中搜索对象的速度，同理ckptq的存在加快了增量checkpoint的内存搜索效率，
fileq的存在加快了表空间checkpoint的内存搜索效率。
SQL> ALTER SESSION SET EVENTS 'immediate trace name buffers level 2';
Session altered.
BH (0x213f5030) file#: 7 rdba: 0x01c0390c (7/14604) class: 1 ba: 0x2128e000
set: 6 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 0 obj: 76226 objn: 76226 tsn: 8 afn: 7
hash: [20fedda0,2a693b68] lru: [22fefd88,213f23b8]
obj-flags: object_ckpt_list
ckptq: [22fed090,2a6e3260] fileq: [2a6e32ec,2a6e32ec] objq: [2603ca30,2603ca30]
st: XCURRENT md: NULL tch: 1
flags: buffer_dirty gotten_in_current_mode redo_since_read
LRBA: [0x9331.ede6.0] HSCN: [0xa00.e7f7af9] HSUB: [1]
buffer tsn: 8 rdba: 0x01c0390c (7/14604)
scn: 0x0a00.0e7f7af9 seq: 0x02 flg: 0x02 tail: 0x7af90602
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
需要注意的是，在Oracle 9i中，并没有objq存在
BH (0x0x53fc77ac) file#: 9 rdba: 0x02410873 (9/67699) class 1 ba: 0x0x5360a000
set: 6 dbwrid: 0 obj: 44558 objn: 44558
hash: [83519fa8,83519fa8] lru: [53fc767c,53fc796c]
LRU flags: moved_to_tail
ckptq: [NULL] fileq: [NULL]
st: XCURRENT md: NULL rsop: 0x(nil) tch: 0
flags: only_sequential_access
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]
buffer tsn: 9 rdba: 0x02410873 (9/67699)
scn: 0x0a00.06200be8 seq: 0x01 flg: 0x04 tail: 0x0be80601
frmt: 0x02 chkval: 0x4d10 type: 0x06=trans data
我们知道drop table时，也会进行表格级别ckpt，当drop table时，需要在buffer_cache中搜寻和这张表格相关的数据块，如果在高并发Oracle9i环境下，极易引起latch争用，
如lacth：cache buffer chain等。
我们知道在insert时，加hint:/*+ append*/将会执行direct path write，即Oracle绕过buffer_cache，直接写往数据文件。是不是Oracle所有的
数据块都绕过buffer_cache都写往数据文件呢？
接下来继续测试direct path write。
为避免干扰，我们从sys.t1读取内容插往zhoultest表格
SQL> explain plan for insert /*+ append*/ into zhoultest select * from sys.t1;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1069440229
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 51050 | 63M| 143 (4)| 00:00:02 |
| 1 | LOAD AS SELECT | ZHOULTEST | | | | |
| 2 | TABLE ACCESS FULL| T1 | 51050 | 63M| 143 (4)| 00:00:02 |
--------------------------------------------------------------------------------
9 rows selected.
SQL> alter system flush buffer_cache;
System altered.
SQL> insert /*+ append*/ into zhoultest select * from sys.t1;
420896 rows created.
SQL> commit;
Commit complete.
我们看到在buffer_cache中除了segment head还出现了其他数据块。
SQL> select a.FILE#,a.BLOCK#,b.EXTENT_ID,b.BLOCK_ID,b.blocks,a.DIRTY from v$bh a, dba_extents b where a.file#=b.file_id and a.block# between b.block_id and b.block_id+b.blocks-1
and owner='ZHOUL' and SEGMENT_NAME='ZHOULTEST' and a.status<>'free';
2
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 5131 0 5129 8 Y
7 5130 0 5129 8 Y
7 24844 101 24841 1024 Y
7 29962 102 29961 1024 Y
7 29964 102 29961 1024 Y
7 29961 102 29961 1024 Y
7 29963 102 29961 1024 Y
7 30986 103 30985 1024 Y
7 30988 103 30985 1024 Y
7 30985 103 30985 1024 Y
7 30987 103 30985 1024 Y
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 32010 104 32009 1024 Y
7 32012 104 32009 1024 Y
7 32009 104 32009 1024 Y
7 32011 104 32009 1024 Y
7 33036 105 33033 1024 Y
7 33033 105 33033 1024 Y
7 33035 105 33033 1024 Y
7 33034 105 33033 1024 Y
7 34057 106 34057 1024 Y
7 34059 106 34057 1024 Y
7 34058 106 34057 1024 Y
FILE# BLOCK# EXTENT_ID BLOCK_ID BLOCKS D
---------- ---------- ---------- ---------- ---------- -
7 34060 106 34057 1024 Y
23 rows selected.
进一步dump数据块，可以看出是2级位图块
Dump of Second Level Bitmap Block
number: 230 nfree: 21 ffree: 138 pdba: 0x01c0140b
Inc #: 0 Objd: 72659
opcode:0
xid:
L1 Ranges :
--------------------------------------------------------
0x01c01409 Free: 1 Inst: 1
0x01c01419 Free: 1 Inst: 1
0x01c01429 Free: 1 Inst: 1
0x01c01439 Free: 1 Inst: 1
0x01c01449 Free: 1 Inst: 1
。。。
继续dump其他数据块，看出是1级位图块
SQL> alter system dump datafile 7 block 34060;
System altered.
Dump of First Level Bitmap Block
--------------------------------
nbits : 4 nranges: 1 parent dba: 0x01c0140a poffset: 185
unformatted: 97 total: 256 first useful block: 0
owning instance : 1
instance ownership changed at
Last successful Search
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
Extent Map Block Offset: 4294967295
First free datablock : 159
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Inc #: 0 Objd: 72659
HWM Flag: HWM Set
Highwater:: 0x01c088a8 ext#: 106 blk#: 927 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 21535
mapblk 0x00000000 offset: 106
。。。
通过以上测试我们可以得出以上推论，在进行direct path write时，由于要改变数据块内容，Oracle需要将反映数据块位置状态的L3，L2，L1，SEGMENT_HEAD读至buffer_cache中。
需要注意的是当进行direct path write时，Oracle会将segment的low hwm至high hwm未格式化的block进行格式化操作，即low hwm=high hwm，然后在high hwm之后插数据
直接路径插入之前
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 119 #blocks: 33920
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0f309 ext#: 118 blk#: 1024 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33916
mapblk 0x00000000 offset: 118
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0ef19 ext#: 118 blk#: 16 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 32908
mapblk 0x00000000 offset: 118
Level 1 BMB for High HWM block: 0x01c0ef0c
Level 1 BMB for Low HWM block: 0x01c0ef09
仅直接路径插入一行数据
SQL> insert /*+ append*/ into zhoultest select * from sys.t1 where rownum<2;
1 row created.
SQL> commit;
Commit complete.
再次查看segment head，可以看到high Highwater mask= Low HighWater Mark
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 120 #blocks: 34944
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c0f40e ext#: 119 blk#: 5 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33925
mapblk 0x00000000 offset: 119
Disk Lock:: Locked by xid: 0x002a.021.00000822
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c0f40e ext#: 119 blk#: 5 ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 33925
mapblk 0x00000000 offset: 119
Level 1 BMB for High HWM block: 0x01c0f409
Level 1 BMB for Low HWM block: 0x01c0f409
分享到：
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 522BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 442Oracle管理云服务（OMC）的大数据平台，自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 4242019年7月22日，受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 787某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1367性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 478从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 1928数据库的启动是一个相当复杂的过程。比如，Oracle在启动之前 ... -
怎么样彻底删除数据库？
2018-09-18 11:10 557Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 816LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1198“一朝被蛇咬，十年怕井绳”。在没被“蛇”咬之前，很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1092在DTCC 2018发表《如何落地智能化运维》演讲，主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 534问题一：ping不通问题 在虚拟机上安装好linux系统后， ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 896即日起，不定期更新《OracleDBA实战攻略》一书电子版，请 ... -
Oracle 12c新特性
2018-05-11 10:33 860查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3931操作系统：RHEL6.5 数据库版本：11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 63511g rac安装在二节点跑脚本一般会报此错误： 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 761故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2492由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1682数据库中的log file sync等待事件指的是，当user ...
相关推荐
utility that moves data from flat files to a running instance of Oracle 9i using the Oracle Call Interface (OCI) Direct Path API.
Direct.Oracle.Access.v4.1.1.0.Full.Source.Delphi12.ccrun.158517.rar
#Core session logical reads ...direct path read direct path write #Network Traffic bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client
连接oracle数据库控件!
Direct Oracle Access Delphi数据连接控件 v4.1，简称doa，被公认为是最好的oracle 数据库访问控件，也是最快的数据库访问控件，可以解决你不少的数据库连接方面的问题，希望对你的编程有帮助。控件包括全部的源码。
w Increase batch performance with Array DML or Direct Path Loading w Easily execute SQL scripts similar to SQL*Plus through the TOracleScript component w Monitor database access information with the ...
Direct_Oracle_Access_v4.1.3.1_XE2_FS_CPP_and_Delphi.7z 包括两个目录： Direct Oracle Access 4.1.3.1 XE2 Delphi Direct Oracle Access 4.1.3.1 XE2 CPP {$DEFINE CompilerVersion3} // Define for Delphi 3...
If you are using Borland's Delphi or C++Builder to develop Oracle applications, then the Direct Oracle Access component set can help you to make a seamless integration between this great development ...
1 、确定数据库的sid 和db_name \u3000sid='hsj' db_name='hsj' 2、设置环境变量env ORACLE_BASE=/u01/app ORACLE_HOME=$ORACLE_BASE/oracle ORACLE_SID=hsj PATH=$ORACLE_HOEM/bin:$PATH; LD_...
Direct Oracle Access控件 v4.1适用 Delphi2009，含有文档和安装程序，比较完整的Delphi控件包，面向Delphi2009版本。
Direct Oracle Access 组件有两种版本，Direct Oracle Access Standard version 和 Direct Oracle Access Object version Object版允许你通过TOracleObject和TOracleReference 对象使用 Oracle8的对象扩展。 如果...
DataX-Oracle新增writeMode支持update的两个jar包已经修改好，使用方法可以看https://blog.csdn.net/qq_36802726/article/details/137118015
通过OCI直接访问Oralce的控件，和PL/SQL Developer同意公司出品，可以配合使用
大名鼎鼎的Oracle数据库访问控件，可以不要Oracle客户端访问数据库。
1
深刻理解Oracle数据库的启动和关闭,深刻理解Oracle数据库的启动和关闭
oracle连接失败 解决方案 超详细 挺有用的
Oracle p6880880_112000_MSWIN-x86-64，数据库补丁程序
通过实例比较了 SYS_CONNECT_BY_PATH 和 CONNECT_BY_ROOT 的异同,和返回树形的数据结构
Oracle Clusterware 安装手册