ITPub博客

首页 > 数据库 > Oracle > 深入了解oracle的高水位(HWM)

深入了解oracle的高水位(HWM)

原创 Oracle 作者:jolly10 时间:2008-07-17 16:04:07 0 删除 编辑

转自http://tolywang.itpub.net/post/48/307529

说到HWM,我们首先要简要的谈谈ORACLE的逻辑存储管理.我们知道,ORACLE在逻辑存储上分4个粒度:表空间,,区和块.

[@more@]

(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的段空间管理相关了.

()ORACLEHWM来界定一个段中使用的块和未使用的块.

举个例子来说,当我们创建一个表: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会采用这种不合理的方式).当用户发出一个全表扫描时,ORACLE 始终必须从段一直扫描到 HWM,即使它什么也没有发现。该任务延长了全表扫描的时间。

()当用直接路径插入行时 例如,通过直接加载插入(用 APPEND 提示插入)或通过 SQL*LOADER 直接路径 数据块直接置于 HWM 之上。它下面的空间就浪费掉了。

我们来分析这两个问题,后者只是带来空间的浪费,但前者不仅是空间的浪费,而且会带来严重的性能问题.我们来看看下面的例子:

(A)我们先来搭建测试的环境,第一步先创建一个段空间为手工管理的表空间:

CREATE TABLESPACE "RAINNY" LOGGING DATAFILE 'D:ORACLE_HOMEORADATARAINNYRAINNY.ORA' SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT MANUAL;

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

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

插入记录DECLARE
I
NUMBER(10);BEGINFOR I IN 1..10000000 LOOPINSERT 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;

ELAPSED: 00:01:03.05

EXECUTION PLAN

----------------------------------------------------------

0 SELECT STATEMENT OPTIMIZER=CHOOSE (COST=15056 CARD=1)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF 'TEST_TAB' (COST=15056 CARD=10000

000)

STATISTICS

----------------------------------------------------------

0 RECURSIVE CALLS

0 DB BLOCK GETS

156310 CONSISTENT GETS

154239 PHYSICAL READS

0 REDO SIZE

379 BYTES SENT VIA SQL*NET TO CLIENT

503 BYTES RECEIVED VIA SQL*NET FROM CLIENT

2 SQL*NET ROUNDTRIPS TO/FROM CLIENT

0 SORTS (MEMORY)

0 SORTS (DISK)

1 ROWS PROCESSED

SQL>

我们来看上面的执行计划,这句SQL总供耗时是:13.访问方式是采用全表扫描方式(FTS),读了156310BLOCK,物理读了154239BLOCK.

我们来分析一下这个表:

BEGIN
DBMS_STATS.GATHER_TABLE_STATS
(OWNNAME=> 'TEST',
TABNAME
=> 'TEST_TAB',

PARTNAME
=> NULL);END;

发现这个表目前使用的BLOCK: 156532,未使用的BLOCK(EMPTY_BLOCKS):0,总行数为(NUM_ROWS):1000 0000

(D)接下来我们把此表的记录用DELETE方式删掉,然后再来看看SELECT COUNT(*) FROM TEST_TAB所花的时间:

DELETE FROM TEST_TAB;

COMMIT;

SQL> SELECT COUNT(*) FROM TEST_TAB;

ELAPSED: 00:01:04.03

EXECUTION PLAN

----------------------------------------------------------

0 SELECT STATEMENT OPTIMIZER=CHOOSE (COST=15056 CARD=1)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF 'TEST_TAB' (COST=15056 CARD=1)

STATISTICS

----------------------------------------------------------

0 RECURSIVE CALLS

0 DB BLOCK GETS

156310 CONSISTENT GETS

155565 PHYSICAL READS

0 REDO SIZE

378 BYTES SENT VIA SQL*NET TO CLIENT

503 BYTES RECEIVED VIA SQL*NET FROM CLIENT

2 SQL*NET ROUNDTRIPS TO/FROM CLIENT

0 SORTS (MEMORY)

0 SORTS (DISK)

1 ROWS PROCESSED

SQL>

大家来看,DELETE表后,此时表中已没有一条记录,为什么SELECT COUNT(*) FROM TEST_TAB花的时间为14,

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/271283/viewspace-1007425/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-02-20

  • 博文量
    263
  • 访问量
    761490