摘  要: HWM(High Water Mark)是表中已经使用过的存储空间与未使用过的存储空间之间的分界线，HWM对全表扫描的性能有非常大的影响。当全表扫描时，Oracle会读取HWM下所有的块，即使这些块中有很多是空块，空块的存在，也即是表中碎片的存在，必将增加全表扫描额外的物理I/O开销及CPU开销，严重降低访问Oracle数据表的性能。通过对Oracle中关于表中HWM的原理及性能优化问题的讨论，针对HWM下的碎片问题提出相关的优化策略，并对其空间重组前后进行性能对比测试。
关键词: Oracle; HWM; 性能优化

    Web2.0与Web3.0的发展都离不开后台支持数据库，数据库运行的好坏、快慢，直接影响到使用者的应用，因而本文将重点研究信息资源建设中后台数据库的优化策略。Oracle 数据库是具有高可靠性、高安全性、高兼容性的大型关系型数据库，是信息化建设的重要基础平台。网络中的信息资源数据库具有异构、数据量大、多媒体内容多、查询频繁等特点，伴随网络不断深入的应用，其存储在数据库中的数据量越来越多，而传统的数据库设计方法使得数据库随着访问数据量的增大其性能明显地降低[1]。Oracle的逻辑空间管理是Oracle管理和优化的重要部分，ASSM段空间自动管理下的HWM问题对Oracle的存储管理和性能优化有重大影响。本文在探讨Oracle 10g逻辑存储管理的基础上,针对HWM下的碎片问题提出了相关的优化策略，并对其空间重组前后进行了性能测试。
1 Oracle存储管理
1.1 Oracle逻辑存储管理
    Oracle在逻辑存储上分4个粒度,如图1所示。

    (1) Block(块)：粒度最小的存储单位，标准默认大小是8 KB，Oracle每一次I/O操作都是按Block来进行的。
    (2) Extent(区)：由一系列相邻的Block组成，是Oracle空间分配的基本单位[2]，Oracle是以Extent为单位进行扩展的。
    (3) Segment(段)：由一系列的Extents所组成[2]，当创建一个对象时(表或索引)，就会分配一个Segment给这个对象。
    (4) Tablespace(表空间):包括Segment、Extent和Block，Tablespace的数据物理上存储在其所在的数据文件中，一个数据库最少要有一个Tablespace。
1.2 HWM
    高水标记HWM(High-Water Mark)这个概念在Segment的存储内容中是比较重要的。简单来说，HWM代表一个表使用的最大(top limit)块(如图2所示)，就是一个Segment中已使用和未来使用的Block的分界线[3]。图2显示了HWM首先位于新创建表的第一个块中，随着数据的插入和更新，使用了越来越多的块，当现有空间不足而进行空间扩展时HWM会随之向上移。如果删除一部分行数据，可能会有许多块不再包含数据，但HWM不会往下移，被占用的最高空间称为HWM。

     Oracle在做全表扫描时会读取HWM下的所有Blocks，即使其中不包含任何数据，Oracle都会一一读取，这会大大影响系统的性能，特别是当HWM之下的大多数块都为空时。
     如果一个OLTP系统(即联机事务处理，就是常说的关系数据库，对记录进行增、删、改、查)应用频繁地对某个表里的记录进行DML(Data Manipulation Language)操作(即数据操纵语言，一种命令使用户能够查询数据库以及操作已有数据库中的数据的计算机语言)，会造成Block中数据分布稀疏,导致HWM下存在大量的碎片,浪费大量的空间。当做全表扫描时，Oracle会读取HWM之下的所有块，即使其中不包含数据[3]。对于HWM以下表的碎片,做全表访问时必然增加一致性读，因而影响到响应时间，降低系统性能。
2 优化策略
    对于增、删、改操作比较频繁的表，尤其是删除操作比较频繁的表，一般表的高水位HWM值会偏高，也就是表中数据块碎片高，虽然ASSM的自动空间管理能提高DML操作并发访问的性能，但是HWM下高碎片的产生会大大影响访问效率，而减少碎片、降低对象的HWM可提高对象的访问效率，从而达到性能优化，大大提高数据的访问效率。表对象可以通过shrink或move方法实现重组、减少碎片、降低HWM，进行性能优化；索引对象可以提供rebuild的方法来实现重组、减少碎片、降低HWM，进行性能优化。当然，在对表及索引进行shrink或move及rebuild操作时，最好选择在非业务高峰时进行，避免影响业务的正常运转。
    shrink与move操作有一些不同，但都可以完成表中碎片的整理，在此可做一些比较：
    (1) move的执行效率比shrink高，因为shrink会产生redo log、undo log；
    (2) shrink对数据的移动是从后往前的，所以shrink不需要使用额外的空闲空间，而move是需要额外空闲空间的；
    (3) 对带有索引的表进行shrink操作时，索引是不需要重建的；而对带有索引的表进行move操作时，索引是需要rebuild重建的，否则索引不可用；
    (4) 对表进行shrink操作时，必须打开表的行迁移属性。
    shrink和move都会对操作的表加表级独占锁，因此其他session对此表执行 DML操作时，存在锁等待；当shrink或move操作执行完成，锁释放。
    索引的rebuild是可以在线完成的，比较适合在高可用环境下完成。
    另外，shrink是10g的新特性，仅对ASSM管理表空间有效。
    具体命令操作如下：
    shrink命令：
    Alter table XXX enable row movement(打开表XXX的行迁移属性);
    Alter table XXX shrink space(仅仅对表XXX进行缩小，不对表中的索引进行空间缩小);
    Alter table XXX shrink space cascade(缩表的同时，也对表中的索引进行缩小);
    Alter table XXX disable row movement(缩表完成后，关闭表XXX的行迁移属性)。
    move命令：
    Alter table XXX move(对表进行move);
    Alter index YYY rebuild(如果表有索引，则需要对表的索引进行重建)。
3 性能优化测试
    对于碎片较多的表，可以通过shrink或move操作降低表中HWM高水位的值来进行性能优化。下面以shrink命令为例子进行测试。
3.1 对TEST表进行分析
     (1) 表大小
    SQL> select segment_name, bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
    SEGMENT_NAME           表大小MB
    TEST                                5.632
    (2) 表的实际数据大小：2.439 MB
    SQL>select table_name, AVG_ROW_LEN ,NUM_ROWS,AVG_ROW_LEN*NUM_ROWS/1024/1024 表实际大小MB,LAST_ANALYZED from dba_tables where table_name=′TEST′;
TABLE_NAME AVG_ROW_LEN NUM_ROWS 表实际大小MB   LAST_ANALYZED
    TEST  157  16290    2.439     2012-12-01 00:13:12
    (3)根据表实际大小公式可得出该表的碎片率为：56.7%
    (1-表实际数据大小/表大小)×100/%=(1-2.439/5.632)×100%=56.7%碎片率：56.7%
    (4)执行SQL语句:select * from test；
    查询表test中所有记录，查询所需时间为2 s。
    SQL的解释计划如下:
    Execution Plan
    |Id|Operation |Name |Rows | Cost (%CPU)| Time|
    |0| SELECT STATEMENT |  |   | 141   (0)|    |
    |1| TABLE ACCESS FULL|TEST|16290|141(0)|00:00:02|
    从以上的SQL解释计划来看,SQL采用的是全表扫描读的方式访问,SQL将读取表的高水位HWM以下的所有数据块。
    由上可知: (1)表TEST的大小为5.632 MB， 但实际数据大小约为2.439 MB，碎片率约为56.7%，表TEST中存在大量的碎片; (2)查询该表所有记录所需要的时间为2 s。
3.2 碎片重组  优化处理
    通过shrink方式对表TEST作碎片重组实现对表的优化处理。
    SQL> select segment_name, bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
    segment_name                表大小MB
        TEST                         5.632
    SQL>alter table test enable row movement;
    SQL>alter table test shrink space;
    SQL>alter table test disable row movement;
    SQL>select segment_name，bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
    SEGMENT_NAME               表大小MB
        TEST                            3.072
    通过对上对TEST表进行优化处理后可以看到:(1) shrink缩表操作后TEST表的大小从5.632 MB缩小到3.072 MB,缩小了近一半,从而降低了表TEST的HWM值； (2)再次执行全表扫描的查询SQL:select * from test;查询时间缩短为1 s，SQL执行速度大大提高。
3.3 测试结论
    在对高碎片表进行全表扫描读的访问方式时,碎片增加了不必要的物理读与内存读,也就增加了不必要的物理I/O与CPU的消耗，最终降低了对表数据的访问速度，即影响了SQL语句的响应时间。通过shrink或者move操作对表碎片空间进行重组，可以有效降低表中的HWM值，提高表的访问效率，进而提高block的命中率，在一定程度上，可以起到系统优化的作用。
    本文针对HWM下碎片问题对性能的影响，探讨减少碎片空间的优化策略，通过对碎片空间的重组来减少碎片的产生，以提高访问效率。
    数据库性能优化是一项复杂的系统工程，是一个循序渐进的过程，应该针对Oracle运行过程中出现的各种问题，找出性能瓶颈，有针对性地对系统进行调整，保证数据库高效可靠的运行。
参考文献
[1] 高敬媛, 赵克宝.校园网数据库性能优化技术[J].煤炭技术,2011,30(07):226-228.
[2] KYTE T, ORACLE E, Signature edition programming techniques and solutions for Oracle 7.3 through 8.1.7 (Expert One-On-One)[M]. New York: Apress，2010.
[3] KYTE T. Expert Oracle database architecture: 9i and 10g  programming techniques and solutions[M]. 2006，San Bernardino: Macsource press，2006.