Oracle高水位线(HWM)及性能优化

转[url]http://blog.csdn.net/wanglinchuan/archive/2008/11/21/3344552.aspx
[/url]
说到HWM,我们首先要简要的谈谈ORACLE的逻辑存储管理.我们知道,ORACLE在逻辑存储上分4个粒度:表空间,段,区和块.
(1)块:是粒度最小的存储单位,现在标准的块大小是8K,ORACLE每一次I/O操作也是按块来操作的,也就是说当ORACLE从数据文件读数据时,是读取多少个块,而不是多少行.
(2)区:由一系列相邻的块而组成,这也是ORACLE空间分配的基本单位,举个例子来说,当我们创建一个表PM_USER时,首先ORACLE会分配一区的空间给这个表,随着不断的INSERT数据到PM_USER,原来的这个区容不下插入的数据时,ORACLE是以区为单位进行扩展的,也就是说再分配多少个区给PM_USER,而不是多少个块.
(3)段:是由一系列的区所组成,一般来说,当创建一个对象时(表,索引),就会分配一个段给这个对象.所以从某种意义上来说,段就是某种特定的数据.如CREATE TABLE PM_USER,这个段就是数据段,而CREATE INDEX ON PM_USER(NAME),ORACLE同样会分配一个段给这个索引,但这是一个索引段了.查询段的信息可以通过数据字典: SELECT * FROM USER_SEGMENTS来获得,
(4)表空间:包含段,区及块.表空间的数据物理上储存在其所在的数据文件中.一个数据库至少要有一个表空间.OK,我们现在回到HWM上来,那么,什么是高水位标记呢?这就跟ORACLE的段空间管理相关了.
(一)ORACLE用HWM来界定一个段中使用的块和未使用的块.
举个例子来说,当我们创建一个表:PT_SCHE_DETAIL时,ORACLE就会为这个对象分配一个段.在这个段中,即使我们未插入任何记录,也至少有一个区被分配,第一个区的第一个块就称为段头(SEGMENT HEADE),段头中就储存了一些信息,基中HWM的信息就存储在此.此时,因为第一个区的第一块用于存储段头的一些信息,虽然没有存储任何实际的记录,但也算是被使用,此时HWM是位于第2个块.当我们不断插入数据到PM_USER后,第1个块已经放不下后面新插入的数据,此时,ORACLE将高水位之上的块用于存储新增数据,同时,HWM本身也向上移.也就是说,当我们不断插入数据时,HWM会往不断上移,这样,在HWM之下的,就表示使用过的块,HWM之上的就表示已分配但从未使用过的块.
(二)HWM在插入数据时,当现有空间不足而进行空间的扩展时会向上移,但删除数据时不会往下移.这就好比是水库的水位,当涨水时,水位往上移,当水退出后,最高水位的痕迹还是清淅可见.
考虑让我们看一个段，如一张表，其中填满了块，如图 1 所示。在正常操作过程中，删除了一些行，如图 2 所示。现有就有了许多浪费的空间：(I) 在表的上一个末端和现有的块之间，以及 (II) 在块内部，其中还有一些没有删除的行。


图1：分配给该表的块。用灰色正方形表示行
ORACLE 不会释放空间以供其他对象使用，有一条简单的理由：由于空间是为新插入的行保留的，并且要适应现有行的增长。被占用的最高空间称为最高使用标记 (HWM)，如图 2 所示。



  图2：行后面的块已经删除了；HWM 仍保持不变
(三)HWM的信息存储在段头当中.
HWM本身的信息是储存在段头.在段空间是手工管理方式时,ORACLE是通过FREELIST(一个单向链表)来管理段内的空间分配.在段空间是自动管理方式时(ASSM),ORACLE是通过BITMAP来管理段内的空间分配.
(四)ORACLE的全表扫描是读取高水位标记(HWM)以下的所有块.
所以问题就产生了.当用户发出一个全表扫描时，ORACLE 始终必须从段一直扫描到 HWM，即使它什么也没有发现。该任务延长了全表扫描的时间。
(五)当用直接路径插入行时 —
例如，通过直接加载插入（用 APPEND 提示插入）或通过 SQL*LOADER 直接路径 — 数据块直接置于 HWM 之上。它下面的空间就浪费掉了。我们来分析这两个问题,后者只是带来空间的浪费,但前者不仅是空间的浪费,而且会带来严重的性能问题.我们来看看下面的例子:
(A)我们先来搭建测试的环境,第一步先创建一个段空间为手工管理的表空间:

create tablespace li
logging
datafile 'F:\oracle\product\10.1.0\oradata\liweiwei\li.dbf' size 5M
autoextend
on next 10M MAXSIZE   UNLIMITED EXTENT MANAGEMENT LOCAL 
SEGMENT SPACE MANAGEMENT MANUAL;

(B)创建一个表,注意,此表的第二个字段我故意设成是CHAR(100),以让此表在插入三百万条记录后,空间有足够大:

CREATE TABLE TEST_TAB(C1 NUMBER(10),C2 CHAR(100)) TABLESPACE li; 

插入记录

DECLARE
  I NUMBER(10);
BEGIN
  FOR I IN 1 .. 3000000 LOOP
    INSERT INTO TEST_TAB VALUES (I, 'TESTSTRING');
  END LOOP;
  COMMIT;
END;

(C)我们来查询一下,看在插入一千万条记录后所访问的块数和查询所用时间:

引用

SQL> set timing on
SQL> set autotrace traceonly
SQL> select count(*) from test_tab;

已用时间:  00: 00: 29.04

执行计划
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=10265 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'TEST_TAB' (TABLE) (Cost=10265 Ca
          rd=2615205)





统计信息
----------------------------------------------------------
         28  recursive calls
          0  db block gets
      93353  consistent gets
      45920  physical reads
    3368004  redo size
        390  bytes sent via SQL*Net to client
        512  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

我们来看上面的执行计划,这句SQL总供耗时是:29秒.访问方式是采用全表扫描方式(FTS),逻辑读了93353个BLOCK,物理读了45920个BLOCK.
我们来分析一下这个表:

BEGIN
  DBMS_STATS.GATHER_TABLE_STATS(OWNNAME  => 'sys',
                                TABNAME  => 'TEST_TAB',
                                PARTNAME => NULL);
END;

执行上面的存储过程之后
可以在这些表中查询到相关的统计数据

引用

user_tables;
user_tab_columns;
user_indexes;
user_tab_statistics;
user_tab_col_statistics;
USER_HISTOGRAMS;

select * from user_tables t where t.table_name='TEST_TAB'

发现这个表目前使用的BLOCK有: 46634,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS):3000511
(D)接下来我们把此表的记录用DELETE方式删掉,然后再来看看SELECT COUNT(*) FROM TEST_TAB所花的时间:

引用

SQL> delete from test_tab;

已删除3000000行。

已用时间:  00: 03: 50.23

执行计划
----------------------------------------------------------
   0      DELETE STATEMENT Optimizer=ALL_ROWS (Cost=10270 Card=3000511
          )

   1    0   DELETE OF 'TEST_TAB'
   2    1     TABLE ACCESS (FULL) OF 'TEST_TAB' (TABLE) (Cost=10270 Ca
          rd=3000511)





统计信息
----------------------------------------------------------
      10100  recursive calls
    3267476  db block gets
      55241  consistent gets
      46789  physical reads
1047538036  redo size
        811  bytes sent via SQL*Net to client
        806  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
    3000000  rows processed

SQL> commit;

提交完成。

已用时间:  00: 00: 00.04

引用

SQL> SELECT COUNT(*) FROM TEST_TAB;

已用时间:  00: 00: 31.42

执行计划
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=10270 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'TEST_TAB' (TABLE) (Cost=10270 Ca
          rd=3000511)





统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      93281  consistent gets
      46164  physical reads
    3368312  redo size
        389  bytes sent via SQL*Net to client
        512  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

大家来看,在DELETE表后,此时表中已没有一条记录,为什么SELECT COUNT(*) FROM TEST_TAB花的时间为31秒, 这是为什么呢?而且大家看,其逻辑读了93281个 BLOCK,跟之前有三百万行记录时差不多,ORACLE怎么会这么笨啊?
我们在DELETE表后再次分析表,看看有什么变化:
这时, TEST_TAB表目前使用的BLOCK是: 46634,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS)已变成:0为什么表目前使的BLOCK数还是46634呢?
问题的根源就在于ORACLE的HWM.也就是说,在新增记录时,HWM会慢慢往上移,但是在删除记录后,HWM却不会往下移,也就是说,DELETE三百万条记录后,此表的HWM根本没移动,还在原来的那个位置,所以,HWM以下的块数同样也是一样的.ORACLE的全表扫描是读取ORACLE高水位标记下的所有BLOCK,也就是说,不管HWM下的BLOCK现在实际有没有存放数据,ORACLE都会一一读取,这样,大家可想而知,在我们DELETE表后,ORACLE读了大量的空块,耗去了大量的时间.

引用

SQL> EXEC SHOW_SPACE('TEST_TAB');
Total Blocks............................47104--总共47104块
Total Bytes.............................385875968
Unused Blocks...........................469--有469块没有用过,也就是在HWM上面的块数
Unused Bytes............................3842048
Last Used Ext FileId....................11
Last Used Ext BlockId...................46089-- BLOCK ID 是针对数据文件来编号的，表示最后使用的一个EXTENT的第一个BLOCK的编号
Last Used Block.........................555 --在最后使用的一个EXTENT 中一共用了555 块

PL/SQL 过程已成功完成。

已用时间:  00: 00: 00.07

总共用了47104块，除了一个SEGMENT HEADER,实际总共用了47103个块，有469块从来没有使用过。LAST USED BLOCK表示在最后一个使用的EXTENT 中使用的BLOCK, 结合　LAST USED EXT BLOCK ID可以计算　HWM 位置 :
LAST USED EXT BLOCK ID + LAST USED BLOCK -1 = HWM 所在的数据文件的BLOCK编号代入得出: 46089+555-1=46643,这个就是HWM所有的BLOCK编号
HWM所在的块:TOTAL BLOCKS- UNUSED BLOCKS=47104-469=46635,也就是说,HWM在第46635个块,其BLOCKID是46643
(E)结下来,我们再做几个试验:

引用

SQL> alter table test_tab deallocate unused;

表已更改。

已用时间:  00: 00: 00.07
SQL> EXEC SHOW_SPACE('TEST_TAB');
Total Blocks............................46640
Total Bytes.............................382074880
Unused Blocks...........................5
Unused Bytes............................40960
Last Used Ext FileId....................11
Last Used Ext BlockId...................46089
Last Used Block.........................555

PL/SQL 过程已成功完成。

已用时间:  00: 00: 00.01

此时我们再代入上面的公式,算出HWM的位置: 46640-5=46635 HWM所在的BLOCK ID是46089+555-1=46643,跟刚刚的没有变化,也就是说执行ALTER TABLE TEST_TAB DEALLOCATE UNUSED后,段的高水位标记的位置没有改变,但是大家看看UNUSED BLOCKS变为5了,总的块数减少到46640,这证明,DEALLOCATE UNUSED为释放HWM上面的未使用空间,但是并不会释放HWM下面的自由空间,也不会移动HWM的位置.

引用

SQL> alter table test_tab move;

表已更改。

已用时间:  00: 00: 07.98
SQL> EXEC SHOW_SPACE('TEST_TAB');
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................7
Unused Bytes............................57344
Last Used Ext FileId....................11
Last Used Ext BlockId...................46649
Last Used Block.........................1

PL/SQL 过程已成功完成。

已用时间:  00: 00: 00.04

此时,总共用到的块数已变为8, 我们再代入上面的公式,算出HWM的位置: 8-7=1 HWM所在的BLOCK ID是46649+1-1=46649, OK,我们发现,此时HWM的位置已经发生变化,现在HWM的位置是在第1个BLOCK,其BLOCK ID是46649,所有数据文件的ID是11(这个没有发生变化,数据文件还是原来的那个数据文件,只是释放了原来的自由空间),最后使用的块数也变为1,也就是说已经使用了1块,HWM就是在最后一个使用的块上,即第1个块上.大家可能会觉得奇怪,为什么释放空间后,未使用的块还有7个啊?也就是说HWM之上还是有7个已分配但从未使用的块.答案就跟HWM移动的规律有关.当我们在插入数据时,ORACLE首先在HWM之下的块当中定位自由空间(通过自由列表FREELIST),如果FREELIST当中没有自由块了,ORACLE就开始往上扩展,而HWM也跟着往上移,每5块移动一次.我们来看ORACLE的说明:
The high water mark is:
-Recorded in the segment header block
-Set to the beginning of the segment on the creation
-Incremented in five-block increments as rows are inserted
-Reset by the truncate command
-Never reset by the delete command
-Space above the high-water-mark can be reclaimed at the table level by using the following command:
ALTER TABLE DEALLOCATE UNUSED…
我们再来看看:SELECT COUNT(*) FROM TEST_TAB所花的时间:

引用

SQL> SELECT COUNT(*) FROM TEST_TAB;

已用时间:  00: 00: 00.00

执行计划
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'TEST_TAB' (TABLE) (Cost=2 Card=1
          )





统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        389  bytes sent via SQL*Net to client
        512  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

很快,不到1秒. 我们最后再来对表作一次分析, 此时这个表目前使用的BLOCK为: 0,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS):0
从中我们也可以发现,分析表和SHOW_SPACE显示的数据有点不一致.那么哪个是准的呢?其实这两个都是准的,只不过计算的方法有点不同.事实上,当你创建了一个对象如表以后,不管你有没有插入数据,它都会占用一些块,ORACLE也会给它分配必要的空间.同样,用ALTER TABLE MOVE释放自由空间后,还是保留了一些空间给这个表.
最后,我们再来执行TRUNCATE命令,截断这个表,看看段空间的使用状况:

引用

SQL> TRUNCATE TABLE TEST_TAB;

表已截断。

已用时间:  00: 00: 00.15
SQL> EXEC SHOW_SPACE('TEST_TAB');
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................7
Unused Bytes............................57344
Last Used Ext FileId....................11
Last Used Ext BlockId...................46649
Last Used Block.........................1

PL/SQL 过程已成功完成。

已用时间:  00: 00: 00.07

我们发现TRUNCATE后和MOVE没有什么变化.
为了,最终验证一下我上面的观点,我再DROP一下表,然后新建这个表,看看这时在没有插入任何数据之前,是否ORACLE确实有给这个对象分配必要的空间:

引用

SQL> DROP TABLE TEST_TAB;

表已删除。

已用时间:  00: 00: 00.06
SQL> CREATE TABLE TEST_TAB(C1 NUMBER(10),C2 CHAR(100)) TABLESPACE li
;
表已创建。

已用时间:  00: 00: 00.07
SQL> EXEC SHOW_SPACE('TEST_TAB');
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................7
Unused Bytes............................57344
Last Used Ext FileId....................11
Last Used Ext BlockId...................46601
Last Used Block.........................1

PL/SQL 过程已成功完成。

已用时间:  00: 00: 00.09

大家看,即使我没有插入任何一行记录,ORACLE还是给它分配了8个块.当然这个跟建表语句的INITIAL 参数及MINEXTENTS参数有关:请看TEST_TAB的存储参数:

引用

STORAGE
(
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
);

也就是说,在这个对象创建以后,ORACLE至少给它分配一个区,初始大小是64K,一个标准块的大小是8K,刚好是8个BLOCK.
总结:
在9I中:
(1)如果MINEXTENT 可以使ALTER TABLE TABLENAME DEALLOCATE UNUSED将HWM以上所有没使用的空间释放
(2)如果MINEXTENT >HWM 则释放MINEXTENTS 以上的空间。如果要释放HWM以上的空间则使用KEEP 0。
ALTER TABLE TABLESNAME DEALLOCATE UNUSED KEEP 0;
(3) TRUNCATE TABLE DROP STORAGE(缺省值)命令可以将MINEXTENT 之上的空间完全释放(交还给操作系统),并且重置HWM。
(4)如果仅是要移动HWM,而不想让表长时间锁住,可以用TRUNCATE TABLE REUSE STORAGE,仅将HWM重置。
(5)ALTER TABLE MOVE会将HWM移动,但在MOVE时需要双倍的表空间,而且如果表上有索引的话,需要重构索引
(6)DELETE表不会重置HWM,也不会释放自由的空间(也就是说DELETE空出来的空间只能给对象本身将来的INSERT/UPDATE使用,不能给其它的对象使用)
在ORACLE 10G:
可以使用ALTER TABLE TEST_TAB SHRINK SPACE命令来联机移动HWM,
如果要同时压缩表的索引,可以发布:ALTER TABLE TEST_TAB SHRINK SPACE CASCADE
注意:在使用此命令时需要先使行可迁移row movement(具体见例子)。
         与使用ALTER TABLE MOVE 不同的是执行此命令后并不需要重构索引。