谈谈Oracle direct path read和direct path write
顾名思义，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