Oracle高水标记详解.docx
《Oracle高水标记详解.docx》由会员分享，可在线阅读，更多相关《Oracle高水标记详解.docx（16页珍藏版）》请在冰点文库上搜索。
Oracle高水标记详解
2008年10月天津oracle的高水位标记
说到HWM,我们首先要简要的谈谈ORACLE的逻辑存储管理.我们知道,ORACLE在逻辑存储上分4个粒度:
表空间,段,区和块.
（1）块:
是粒度最小的存储单位,现在标准的块大小是8K,ORACLE每一次I/O操作也是按块来操作的,也就是说当ORACLE从数据文件读数据时,是读取多少个块,而不是多少行.
（2）区:
由一系列相邻的块而组成,这也是ORACLE空间分配的基本单位,举个例子来说,当我们创建一个表PM_USER时,首先ORACLE会分配一区的空间给这个表,随着不断的INSERT数据到PM_USER,原来的这个区容不下插入的数据时,ORACLE是以区为单位进行扩展的,也就是说再分配多少个区给PM_USER,而不是多少个块.
（3）段:
是由一系列的区所组成,一般来说,当创建一个对象时（表,索引）,就会分配一个段给这个对象.所以从某种意义上来说,段就是某种特定的数据.如CREATETABLEPM_USER,这个段就是数据段,而CREATEINDEXONPM_USER（NAME）,ORACLE同样会分配一个段给这个索引,但这是一个索引段了.查询段的信息可以通过数据字典:
SELECT*FROMUSER_SEGMENTS来获得,
（4）表空间:
包含段,区及块.表空间的数据物理上储存在其所在的数据文件中.一个数据库至少要有一个表空间.
OK,我们现在回到HWM上来,那么,什么是高水位标记呢?
这就跟ORACLE的段空间管理相关了.
（一）ORACLE用HWM来界定一个段中使用的块和未使用的块.
举个例子来说,当我们创建一个表:
PT_SCHE_DETAIL时,ORACLE就会为这个对象分配一个段.在这个段中,即使我们未插入任何记录,也至少有一个区被分配,第一个区的第一个块就称为段头（SEGMENTHEADE）,段头中就储存了一些信息,基中HWM的信息就存储在此.此时,因为第一个区的第一块用于存储段头的一些信息,虽然没有存储任何实际的记录,但也算是被使用,此时HWM是位于第2个块.当我们不断插入数据到PM_USER后,第1个块已经放不下后面新插入的数据,此时,ORACLE将高水位之上的块用于存储新增数据,同时,HWM本身也向上移.也就是说,当我们不断插入数据时,HWM会往不断上移,这样,在HWM之下的,就表示使用过的块,HWM之上的就表示已分配但从未使用过的块.
（二）HWM在插入数据时,当现有空间不足而进行空间的扩展时会向上移,但删除数据时不会往下移.
这就好比是水库的水位,当涨水时,水位往上移,当水退出后,最高水位的痕迹还是清淅可见.
（三）HWM的信息存储在段头当中.
HWM本身的信息是储存在段头.在段空间是手工管理方式时,ORACLE是通过FREELIST（一个单向链表）来管理段内的空间分配.在段空间是自动管理方式时（ASSM）,ORACLE是通过BITMAP来管理段内的空间分配.
（四）ORACLE的全表扫描是读取高水位标记（HWM）以下的所有块.
所以问题就产生了（一直不解为何ORACLE会采用这种不合理的方式）.当用户发出一个全表扫描时，ORACLE始终必须从段一直扫描到HWM，即使它什么也没有发现。
该任务延长了全表扫描的时间。
（五）当用直接路径插入行时—例如，通过直接加载插入（用APPEND提示插入）或通过SQL*LOADER直接路径—数据块直接置于HWM之上。
它下面的空间就浪费掉了。
我们来分析这两个问题,后者只是带来空间的浪费,但前者不仅是空间的浪费,而且会带来严重的性能问题.我们来看看下面的例子:
（A）我们先来搭建测试的环境,第一步先创建一个段空间为手工管理的表空间:
CREATETABLESPACE"RAINNY"
LOGGING
DATAFILE'D:
\ORACLE_HOME\ORADATA\RAINNY\RAINNY.ORA'SIZE5M
AUTOEXTEND
ONNEXT10MMAXSIZEUNLIMITEDEXTENTMANAGEMENTLOCAL
SEGMENTSPACEMANAGEMENTMANUAL;
B）创建一个表,注意,此表的第二个字段我故意设成是CHAR（100）,以让此表在插入1千万条记录后,空间有足够大:
CREATETABLETEST_TAB（C1NUMBER（10）,C2CHAR（100））TABLESPACERAINNY;
插入记录
DECLARE
INUMBER（10）;
BEGIN
FORIIN1..10000000LOOP
INSERTINTOTEST_TABVALUES（I,'TESTSTRING'）;
ENDLOOP;
COMMIT;
END;
（C）我们来查询一下,看在插入一千万条记录后所访问的块数和查询所用时间:
SQL>SETTIMINGON
SQL>SETAUTOTRACETRACEONLY
SQL>SELECTCOUNT（*）FROMTEST_TAB;
ELAPSED:
00:
01:
03.05
EXECUTIONPLAN
----------------------------------------------------------
0SELECTSTATEMENTOPTIMIZER=CHOOSE（COST=15056CARD=1）
10SORT（AGGREGATE）
21TABLEACCESS（FULL）OF'TEST_TAB'（COST=15056CARD=10000
000）
STATISTICS
----------------------------------------------------------
0RECURSIVECALLS
0DBBLOCKGETS
156310CONSISTENTGETS
154239PHYSICALREADS
0REDOSIZE
379BYTESSENTVIASQL*NETTOCLIENT
503BYTESRECEIVEDVIASQL*NETFROMCLIENT
2SQL*NETROUNDTRIPSTO/FROMCLIENT
0SORTS（MEMORY）
0SORTS（DISK）
1ROWSPROCESSED
SQL>
我们来看上面的执行计划,这句SQL总供耗时是:
1分3秒.访问方式是采用全表扫描方式（FTS）,逻辑读了156310个BLOCK,物理读了154239个BLOCK.
我们来分析一下这个表:
BEGIN
DBMS_STATS.GATHER_TABLE_STATS（OWNNAME=>'TEST',
TABNAME=>'TEST_TAB',
PARTNAME=>NULL）;
END;
发现这个表目前使用的BLOCK有:
156532,未使用的BLOCK（EMPTY_BLOCKS）为:
0,总行数为（NUM_ROWS）:
10000000
（D）接下来我们把此表的记录用DELETE方式删掉,然后再来看看SELECTCOUNT（*）FROMTEST_TAB所花的时间:
DELETEFROMTEST_TAB;
COMMIT;
SQL>SELECTCOUNT（*）FROMTEST_TAB;
ELAPSED:
00:
01:
04.03
EXECUTIONPLAN
----------------------------------------------------------
0SELECTSTATEMENTOPTIMIZER=CHOOSE（COST=15056CARD=1）
10SORT（AGGREGATE）
21TABLEACCESS（FULL）OF'TEST_TAB'（COST=15056CARD=1）
STATISTICS
----------------------------------------------------------
0RECURSIVECALLS
0DBBLOCKGETS
156310CONSISTENTGETS
155565PHYSICALREADS
0REDOSIZE
378BYTESSENTVIASQL*NETTOCLIENT
503BYTESRECEIVEDVIASQL*NETFROMCLIENT
2SQL*NETROUNDTRIPSTO/FROMCLIENT
0SORTS（MEMORY）
0SORTS（DISK）
1ROWSPROCESSED
SQL>
大家来看,在DELETE表后,此时表中已没有一条记录,为什么SELECTCOUNT（*）FROMTEST_TAB花的时间为1分4秒,反而比有记录稍微长点,这是为什么呢?
而且大家看,其逻辑读了156310个BLOCK,跟之前有一千万行记录时差不多,ORACLE怎么会这么笨啊?
我们在DELETE表后再次分析表,看看有什么变化:
这时,TEST_TAB表目前使用的BLOCK是:
156532,未使用的BLOCK（EMPTY_BLOCKS）为:
0,总行数为（NUM_ROWS）已变成:
0
为什么表目前使的BLOCK数还是156532呢?
问题的根源就在于ORACLE的HWM.也就是说,在新增记录时,HWM会慢慢往上移,但是在删除记录后,HWM却不会往下移,也就是说,DELETE一千万条记录后,此表的HWM根本没移动,还在原来的那个位置,所以,HWM以下的块数同样也是一样的.ORACLE的全表扫描是读取ORACLE高水位标记下的所有BLOCK,也就是说,不管HWM下的BLOCK现在实际有没有存放数据,ORACLE都会一一读取,这样,大家可想而知,在我们DELETE表后,ORACLE读了大量的空块,耗去了大量的时间.
我们再来看DELETE表后段空间实际使用的状况:
setserveroutputon
VARTOTAL_BLOCKSNUMBER
VARTOTAL_BYTESNUMBER
VARUNUSED_BLOCKSNUMBER
VARUNUSED_BYTESNUMBER
VARLAST_USED_EXTENT_FILE_IDNUMBER
VARLAST_USED_EXTENT_BLOCK_IDNUMBER
VARLAST_USED_BLOCKNUMBER
EXECDBMS_SPACE.UNUSED_SPACE（'TEST','TEST_TAB','TABLE',:
TOTAL_BLOCKS,:
TOTAL_BYTES,:
UNUSED_BLOCKS,:
UNUSED_BYTES,:
LAST_USED_EXTENT_FILE_ID,:
LAST_USED_EXTENT_BLOCK_ID,:
LAST_USED_BLOCK）;
PRINTTOTAL_BLOCKS
PRINTTOTAL_BYTES
PRINTUNUSED_BLOCKS
PRINTUNUSED_BYTES
PRINTLAST_USED_EXTENT_FILE_ID
PRINTLAST_USED_EXTENT_BLOCK_ID
PRINTLAST_USED_BLOCK
输出结果为:
PL/SQLPROCEDURESUCCESSFULLYCOMPLETED
TOTAL_BLOCKS
----------------------------------------------------------------------
164352
TOTAL_BYTES
----------------------------------------------------------------------
1346371584
UNUSED_BLOCKS
----------------------------------------------------------------------
7168
UNUSED_BYTES
----------------------------------------------------------------------
58720256
LAST_USED_EXTENT_FILE_ID
----------------------------------------------------------------------
9
LAST_USED_EXTENT_BLOCK_ID
----------------------------------------------------------------------
158856
LAST_USED_BLOCK
----------------------------------------------------------------------
1024
我们再来看看SHOW_SPACE显示的数据:
SQL>EXECSHOW_SPACE（'TEST_TAB','TEST'）;
TOTALBLOCKS............................164352--总共164352块
TOTALBYTES.............................1346371584
UNUSEDBLOCKS...........................7168--有7168块没有用过,也就是在HWM上面的块数
UNUSEDBYTES............................58720256
LASTUSEDEXTFILEID....................9
LASTUSEDEXTBLOCKID...................158856---BLOCKID是针对数据文件来编号的，表示最后使用的一个EXTENT的第一个BLOCK的编号
LASTUSEDBLOCK.........................1024在最后使用的一个EXTENT中一共用了1024块
PL/SQLPROCEDURESUCCESSFULLYCOMPLETED
总共用了164352块，除了一个SEGMENTHEADER,实际总共用了164351个块，有7168块从来没有使用过。
LASTUSEDBLOCK表示在最后一个使用的EXTENT中使用的BLOCK,结合 LASTUSEDEXTBLOCKID可以计算 HWM位置:
LASTUSEDEXTBLOCKID+LASTUSEDBLOCK-1=HWM所在的数据文件的BLOCK编号
代入得出:
158856+1024-1=159879,这个就是HWM所有的BLOCK编号
HWM所在的块:
TOTALBLOCKS-UNUSEDBLOCKS=164352-7168=157184,也就是说,HWM在第157184个块,其BLOCKID是159879
（E）结下来,我们再做几个试验:
第一步:
执行ALTERTABLETEST_TABDEALLOCATEUNUSED;
我们看看段空间的使用状况:
SQL>EXECSHOW_SPACE（'TEST_TAB','TEST'）;
TOTALBLOCKS............................157184
TOTALBYTES.............................1287651328
UNUSEDBLOCKS...........................0
UNUSEDBYTES............................0
LASTUSEDEXTFILEID....................9
LASTUSEDEXTBLOCKID...................158856
LASTUSEDBLOCK.........................1024
PL/SQLPROCEDURESUCCESSFULLYCOMPLETED
SQL>
此时我们再代入上面的公式,算出HWM的位置:
157184-0=157184HWM所在的BLOCKID是158856+1024-1=159879,跟刚刚的没有变化,也就是说执行ALTERTABLETEST_TABDEALLOCATEUNUSED后,段的高水位标记的位置没有改变,但是大家看看UNUSEDBLOCKS变为0了,总的块数减少到157184,这证明,DEALLOCATEUNUSED为释放HWM上面的未使用空间,但是并不会释放HWM下面的自由空间,也不会移动HWM的位置.
第二步:
我们再来看看执行ALTERTABLETEST_TABMOVE后段空间的使用状况:
SQL>EXECSHOW_SPACE（'TEST_TAB','TEST'）;
TOTALBLOCKS............................8
TOTALBYTES.............................65536
UNUSEDBLOCKS...........................5
UNUSEDBYTES............................40960
LASTUSEDEXTFILEID....................9
LASTUSEDEXTBLOCKID...................2632
LASTUSEDBLOCK.........................3
PL/SQLPROCEDURESUCCESSFULLYCOMPLETED
SQL>
此时,总共用到的块数已变为8,我们再代入上面的公式,算出HWM的位置:
8-5=3HWM所在的BLOCKID是2632+3-1=2634,
OK,我们发现,此时HWM的位置已经发生变化,现在HWM的位置是在第3个BLOCK,其BLOCKID是2634,所有数据文件的ID是9（这个没有发生变化,数据文件还是原来的那个数据文件,只是释放了原来的自由空间）,最后使用的块数也变为3,也就是说已经使用了3块,HWM就是在最后一个使用的块上,即第3个块上.大家可能会觉得奇怪,为什么释放空间后,未使用的块还有5个啊?
也就是说HWM之上还是有5个已分配但从未使用的块.答案就跟HWM移动的规律有关.当我们在插入数据时,ORACLE首先在HWM之下的块当中定位自由空间（通过自由列表FREELIST）,如果FREELIST当中没有自由块了,ORACLE就开始往上扩展,而HWM也跟着往上移,每5块移动一次.我们来看ORACLE的说明:
Thehighwatermarkis:
-Recordedinthesegmentheaderblock
-Settothebeginningofthesegmentonthecreation
-Incrementedinfive-blockincrementsasrowsareinserted
-Resetbythetruncatecommand
-Neverresetbythedeletecommand
-Spaceabovethehigh-water-markcanbereclaimedatthetablelevelbyusingthefollowingcommand:
ALTERTABLEDEALLOCATEUNUSED…
我们再来看看:
SELECTCOUNT（*）FROMTEST_TAB所花的时间:
SQL>SELECTCOUNT（*）FROMTEST_TAB;
ELAPSED:
00:
00:
00.00
EXECUTIONPLAN
----------------------------------------------------------
0SELECTSTATEMENTOPTIMIZER=CHOOSE
10SORT（AGGREGATE）
21TABLEACCESS（FULL）OF'TEST_TAB'
STATISTICS
----------------------------------------------------------
0RECURSIVECALLS
0DBBLOCKGETS
3CONSISTENTGETS
0PHYSICALREADS
0REDOSIZE
378BYTESSENTVIASQL*NETTOCLIENT
503BYTESRECEIVEDVIASQL*NETFROMCLIENT
2SQL*NETROUNDTRIPSTO/FROMCLIENT
0SORTS（MEMORY）
0SORTS（DISK）
1ROWSPROCESSED
SQL>
很快,不到1秒.
我们最后再来对表作一次分析,此时这个表目前使用的BLOCK为:
0,未使用的BLOCK（EMPTY_BLOCKS）为:
0,总行数为（NUM_ROWS）:
0
从中我们也可以发现,分析表和SHOW_SPACE显示的数据有点不一致.那么哪个是准的呢?
其实这两个都是准的,只不过计算的方法有点不同.事实上,当你创建了一个对象如表以后,不管你有没有插入数据,它都会占用一些块,ORACLE也会给它分配必要的空间.同样,用ALTERTABLEMOVE释放自由空间后,还是保留了一些空间给这个表.
最后,我们再来执行TRUNCATE命令,截断这个表,看看段空间的使用状况:
TRUNCATETABLETEST_TAB;
SQL>EXECSHOW_SPACE（'TEST_TAB','TEST'）;
TOTALBLOCKS............................8
TOTALBYTES.............................65536
UNUSEDBLOCKS...........................5
UNU
升级会员 