一、查询表大小，块多少语句
Select SEGMENT_Name,BYTES,BLOCKS,Extents From dba_segments Where
segment_name In('BAI_NEW_SESSION_HISTORY2') order by segment_name;
（2）查表空间
Select Tablespace_Name, Sum(bytes)/1024/1024 From Dba_Segments group By Tablespace_Name
（3）可以用输入变量值的查询，以前没遇到过
SELECT TABLESPACE_NAME,TO_CHAR(SUM(BYTES)/(1024*1024),'999G999D999') CNT_MB FROM DBA_EXTENTS
WHERE OWNER='&OWNER' AND SEGMENT_NAME='&TABLE_NAME' AND SEGMENT_TYPE LIKE 'TABLE%' GROUP BY TABLESPACE_NAME;
二、转载的博客（解惑啊）
http://hi.baidu.com/xbnh0217/item/f0b3d20c74d8fb7cbee97ea1
代码部门又出问题了，上次是页面查询响应很慢，这次是页面更新速度很慢，开发人员提交了SQL语句到我这里，
看了一下，这个语句非常简单，update tbl set ... = ... where mobile=..and sp_id=..，他影响的只有一行，这个
语句能慢？？？？
我在现场数据库中手工执行了这个语句，大概需要3分钟，影响行数：1，马上断定：表数据量庞大，定位这一行
使用了FULL SCAN，于是建议他们在关键字段建立索引，结果开发人员告诉我这个表只有2000多条记录，没必要建立索引，
有点不大相信，看下数据先，select count(*)，大概花了4分钟，数据量：2087，晕死，2087行的表，我选个总数用了
4分钟，你ORACLE干什么吃的？？？
思考中。。。
查看数据库的锁定情况，在这个表上并没有TX或TM类型的锁，看来不是事务阻塞了，那为什么出现这种奇怪的事情呢？
生成了一个statspack性能报告，这条更新语句是名列前茅，够强哦，逻辑读有2万多次，真是晕了
思考中。。。
干脆分析下这个UPDATE语句，看看查询计划究竟做了什么
set autotrace on
的确是走的全表扫描，有两个地方引起了我的注意，其实这个在statspack报告中就可以看出来，逻辑读是2万多次，
物理读2万多次，进行了很多物理IO，速度下降是肯定的，但怎么会有这么多的物理IO呢？难道这个表真的有2万多个数据块？
查看下先，select blocks from user_segments where segment_name = 'tbl',果然，258333个数据块，每个数据块是8K，
这样每次UPDATE需要扫描近200M的空间，并且这些空间中99.999999%的是空闲的，难怪更新这么慢，于是和他们工程部的
人协商，暂时停掉操作页面，然后我将表数据备份到一张临时表，truncate原表，在将数据导入，启动页面，马上更新快
起来了，查看表数据块，由原来的258333变成了20，现在表只有160K
这个问题的解决涉及到ORACLE的空间管理，在ORACLE的表上存在着高水位标记（HWM），他是一个分界线，当扫描
表时，ORACLE只会扫描位于HWM以下的数据块（不考虑回滚段中的数据前映象），随着表数据量的不断增加，需要的*块
就越多，当表需要*块时，会在表本身的*列表freelist里面去定位，随着数据块上数据的增加，到某种程度时这个数据块
就会在freelist中失去他的记载（由pctfree决定）如果freelist中已经没有空闲块，则提高HWM，容纳更多的*块
到freelist中，当表的数据块上的内容被删除时，就有了空间，他们又会回到*列表中（PCTUSE指定什么时候该回去），
这个过程循环进行，HWM会被渐渐抬高，当表的数据被DELETE掉时，数据没了，数据块都返还到freelist了，但此时HWM并没有
下去，或者他只是下去了一点点，这样扫描表时，可能你的记录是0，但HWM下的数据块却很庞大，就会产生大量的空块读取，
使表的HWM下降的方法是TRUNCATE表或是删除重建，或是ALTER TABLE TBL MOVE TABLESPACE ANOTHER_SPACE,另外ASSM表空间
管理模式可能很少出现这种情况，我这里采用的是TRUNCATE的方法，比较笨拙，事后询问了他们工程部的人，这个表以前有好
几百万的数据，后来清除了许多，现场表他们清除是不敢用TRUNCATE的，所以原因是在清楚不过了，下面我们通过实验来证实
我的说法，创建一个大表，选择出其记录总数，看看花多长时间，然后DELETE表后再选择记录数看花多长时间，最后TRUNCATE
表再选择，看花多长时间
--创建mytest表
SQL> create table mytest nologging as select * from duizhang_toboss;
Table created
SQL> set timing on --显示消耗时间
SQL> select count(*) from mytest; --记录数12522708，耗时19秒，已经不小拉
COUNT(*)
----------
12522708
Executed in 19 seconds
SQL> delete from mytest; --删除表的所有数据，这个过程太长了，涉及到回滚数据的创建，库也不是我一个人在折腾
12522708 rows deleted
Executed in 903.031 seconds
SQL> commit; --提交变更
Commit complete
Executed in 0 seconds
SQL> select count(*) from mytest; --表已经空了，但没有想象中快速完成查询，用时57秒，这不大正常，但证明HWM确实没有下去，在执行不必要的空块读取
COUNT(*)
----------
0
Executed in 57.046 seconds
SQL> truncate table mytest; --TUNCATE重置HWM，扫描数据块大大降低，很快过去
Table truncated
Executed in 0.406 seconds
现在大家应该明白其中的来龙去脉了吧，大家看到，DELETE对HWM基本没起什么作用，TRUNCATE才降低了水位，这就是为什么同是
空表，扫描时间却大不相同的原因了，就写到这里，头又叫我了，呵呵！！！！！
222222222222222222222222222
深入了解oracle的高水位(HWM)
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在插入数据时,当现有空间不足而进行空间的扩展时会向上移,但删除数据时不会往下移.
这就好比是水库的水位,当涨水时,水位往上移,当水退出后,最高水位的痕迹还是清淅可见.
考虑让看一个段，如一张表，其中填满了块，。在正常操作过程中，删除了一些行。现有就有了许多浪费的空间：
ORACLE 不会释放空间以供其他对象使用，有一条简单的理由：由于空间是为新插入的行保留的，并且要适应现有行的增长。被占用的最高空间称为最高使用标记 (HWM)
(三)HWM的信息存储在段头当中.
HWM本身的信息是储存在段头.在段空间是手工管理方式时,ORACLE是通过FREELIST(一个单向链表)来管理段内的空间分配.在段空间是自动管理方式时(ASSM),ORACLE是通过BITMAP来管理段内的空间分配.
(四)ORACLE的全表扫描是读取高水位标记(HWM)以下的所有块.
所以问题就产生了(一直不解为何ORACLE会采用这种不合理的方式).当用户发出一个全表扫描时，ORACLE 始终必须从段一直扫描到 HWM，即使它什么也没有发现。该任务延长了全表扫描的时间。
(五)当用直接路径插入行时 — 例如，通过直接加载插入（用 APPEND 提示插入）或通过 SQL*LOADER 直接路径 — 数据块直接置于 HWM 之上。它下面的空间就浪费掉了。
来分析这两个问题,后者只是带来空间的浪费,但前者不仅是空间的浪费,而且会带来严重的性能问题.来看看下面的例子:
(A)先来搭建测试的环境(172.17.8.202,Linux,ORACLE 版本：1002000100),第一步先创建一个段空间为手工管理的表空间:
CREATE TABLESPACE "SEC"
LOGGING
DATAFILE '/u01/app/oracle/oradata/TSH1/SEC.DBF' 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 SEC;
插入记录
DECLARE
I NUMBER(10);
BEGIN
FOR I IN 1..10000000 LOOP
INSERT INTO TEST_TAB VALUES(I,'TESTSTRING');
END LOOP;
COMMIT;
END ;
/
使用了1.3G的表空间，好大！
(C)来查询一下,看在插入一千万条记录后所访问的块数和查询所用时间:
conn /as sysdba
SET TIMING ON
SET AUTOTRACE TRACEONLY
SELECT COUNT(*) FROM sec.TEST_TAB;
SQL> SELECT COUNT(*) FROM sec.TEST_TAB;
Elapsed: 00:01:36.04
Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 34513 (2)| 00:06:55 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_TAB | 10M| 34513 (2)| 00:06:55 |
-----------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
5 recursive calls
0 db block gets
312025 consistent gets
154253 physical reads
11233336 redo size
411 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
这句SQL总供耗时是:1分36秒.访问方式是采用全表扫描方式(FTS),逻辑读了 312025 个BLOCK,物理读了 154253 个BLOCK.
来分析一下这个表:
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=> 'SEC',
TABNAME=> 'TEST_TAB',
PARTNAME=> NULL);END;
/
PL/SQL procedure successfully completed.
Elapsed: 00:01:58.63
SQL> select NUM_ROWS,BLOCKS,EMPTY_BLOCKS from dba_tables where table_name = 'TEST_TAB';
NUM_ROWS BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
10004718 156011 0
发现这个表目前使用的BLOCK有: 156011,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS):10004718
再查询一下结果：
SQL> SELECT COUNT(*) FROM sec.TEST_TAB;
Elapsed: 00:00:40.67
Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 34500 (2)| 00:06:54 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_TAB | 10M| 34500 (2)| 00:06:54 |
-----------------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
156034 consistent gets
152544 physical reads
0 redo size
411 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
这句SQL总供耗时是:40秒.访问方式是采用全表扫描方式(FTS),逻辑读了 156034 个BLOCK,物理读了 152544 个BLOCK.
(D)接下来把此表的记录用DELETE方式删掉,然后再来看看SELECT COUNT(*) FROM TEST_TAB所花的时间:
SQL> DELETE FROM sec.test_tab;
10000000 rows deleted.
Elapsed: 00:10:22.64
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT COUNT(*) FROM sec.TEST_TAB;
Elapsed: 00:01:32.12
Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 34500 (2)| 00:06:54 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_TAB | 10M| 34500 (2)| 00:06:54 |
-----------------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
156034 consistent gets
154379 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 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(*)
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表后段空间实际使用的状况:
VAR TOTAL_BLOCKS NUMBER
VAR TOTAL_BYTES NUMBER
VAR UNUSED_BLOCKS NUMBER
VAR UNUSED_BYTES NUMBER
VAR LAST_USED_EXTENT_FILE_ID NUMBER
VAR LAST_USED_EXTENT_BLOCK_ID NUMBER
VAR LAST_USED_BLOCK NUMBER
EXEC
DBMS_SPACE.UNUSED_SPACE('SEC','TEST_TAB','TABLE',:TOTAL_BLOCKS,:TOTAL_BYTES,:UNUSED_BLOCKS,:UNUSED_BYTES,:LAST_USED_EXTENT_FILE_ID,:LAST_USED_EXTENT_BLOCK_ID,:LAST_USED_BLOCK);
PRINT TOTAL_BLOCKS
PRINT TOTAL_BYTES
PRINT UNUSED_BLOCKS
PRINT UNUSED_BYTES
PRINT LAST_USED_EXTENT_FILE_ID
PRINT LAST_USED_EXTENT_BLOCK_ID
PRINT LAST_USED_BLOCK
输出结果为:
TOTAL_BLOCKS ------------ 156544 --总共164352块
TOTAL_BYTES ------------ 1282408448
UNUSED_BLOCKS ------------ 532 --有7168块没有用过,也就是在HWM上面的块数
UNUSED_BYTES ------------ 4358144
LAST_USED_EXTENT_FILE_ID ------------ 6
LAST_USED_EXTENT_BLOCK_ID ------------ 148489 --- BLOCK ID 是针对数据文件来编号的，表示最后使用的一个EXTENT的第一个BLOCK的编号
LAST_USED_BLOCK ------------ 7660 ---在最后使用的一个EXTENT 中一共用了1024块
总
共用了164352块，除了一个SEGMENT HEADER,实际总共用了164351个块，有7168块从来没有使用过。LAST USED
BLOCK表示在最后一个使用的EXTENT 中使用的BLOCK, 结合 LAST USED EXT BLOCK ID可以计算 HWM 位置
:LAST USED EXT BLOCK ID + LAST USED BLOCK -1 = HWM 所在的数据文件的BLOCK编号代入得出:
158856+1024-1=159879,这个就是HWM所有的BLOCK编号HWM所在的块:TOTAL BLOCKS- UNUSED
BLOCKS=164352-7168=157184,也就是说,HWM在第157184个块,其BLOCKID是159879
(E)接下来,再做几个试验:
第一步:执行ALTER TABLE sec.TEST_TAB DEALLOCATE UNUSED; 看看段空间的使用状况:
TOTAL_BLOCKS ------------ 156016 157184
TOTAL_BYTES ------------ 1278083072 1287651328
UNUSED_BLOCKS ------------ 4 0
UNUSED_BYTES ------------ 32768 0
LAST_USED_EXTENT_FILE_ID ------------ 6 9
LAST_USED_EXTENT_BLOCK_ID ------------ 148489 158856
LAST_USED_BLOCK ------------ 7660 1024
此
时再代入上面的公式,算出HWM的位置: 157184-0=157184
HWM所在的BLOCKID是158856+1024-1=159879,跟刚刚的没有变化,也就是说执行ALTER TABLETEST_TAB
DEALLOCATE UNUSED后,段的高水位标记的位置没有改变,但是看UNUSED
BLOCKS变为0了,总的块数减少到157184,这证明,DEALLOCATE
UNUSED为释放HWM上面的未使用空间,但是并不会释放HWM下面的*空间,也不会移动HWM的位置.
第二步:再来看看执行ALTER TABLE sec.TEST_TAB MOVE;后段空间的使用状况:
TOTAL_BLOCKS ------------ 8 8
TOTAL_BYTES ------------ 65536 65536
UNUSED_BLOCKS ------------ 7 5
UNUSED_BYTES ------------ 57344 40960
LAST_USED_EXTENT_FILE_ID ------------ 6 9
LAST_USED_EXTENT_BLOCK_ID ------------ 9 2632
LAST_USED_BLOCK ------------ 1 3
此
时,总共用到的块数已变为8, 再代入上面的公式,算出HWM的位置: 8-5=3HWM所在的BLOCK
ID是2632+3-1=2634,OK,发现,此时HWM的位置已经发生变化,现在HWM的位置是在第3个BLOCK,其BLOCK
ID是2634,所有数据文件的ID是9(这个没有发生变化,数据文件还是原来的那个数据文件,只是释放了原来的*空间),最后使用的块数也变为3,也
就是说已经使用了3块,HWM就是在最后一个使用的块上,即第3个块上.大家可能会觉得奇怪,为什么释放空间后,未使用的块还有5个啊?也就是说HWM之
上还是有5个已分配但从未使用的块.答案就跟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> SET AUTOTRACE TRACEONLY
SQL>SELECT COUNT(*) FROM sec.TEST_TAB;
Elapsed: 00:00:00.06
Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 34500 (2)| 00:06:54 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_TAB | 10M| 34500 (2)| 00:06:54 |
-----------------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 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 sec.test_tab;
TOTAL_BLOCKS ------------ 8 8
TOTAL_BYTES ------------ 65536 65536
UNUSED_BLOCKS ------------ 7 5
UNUSED_BYTES ------------ 57344 40960
LAST_USED_EXTENT_FILE_ID ------------ 6 9
LAST_USED_EXTENT_BLOCK_ID ------------ 9 2632
LAST_USED_BLOCK ------------ 1 3
发现TRUNCATE后和MOVE没有什么变化.为了最终验证一下我上面的观点,我再DROP一下表,然后新建这个表,看看这时在没有插入任何数据之前,是否ORACLE确实有给这个对象分配必要的空间:
DROP TABLE sec.TEST_TAB;
CREATE TABLE sec.TEST_TAB(C1 NUMBER(10),C2 CHAR(100)) TABLESPACE SEC;
TOTAL_BLOCKS ------------ 8 8
TOTAL_BYTES ------------ 65536 65536
UNUSED_BLOCKS ------------ 7 5
UNUSED_BYTES ------------ 57344 40960
LAST_USED_EXTENT_FILE_ID ------------ 6 9
LAST_USED_EXTENT_BLOCK_ID ------------ 17 2112
LAST_USED_BLOCK ------------ 1 3
,即使我没有插入任何一行记录,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 REUSESTORAGE,仅将HWM重置。
(5)ALTER TABLE MOVE会将HWM移动,但在MOVE时需要双倍的表空间,而且如果表上有索引的话,需要重构索引
(6)DELETE表不会重置HWM,也不会释放*的空间(也就是说DELETE空出来的空间只能给对象本身将来的INSERT/UPDATE使用,不能给其它的对象使用)
在ORACLE 10G:
(1)可以使用ALTER TABLE TEST_TAB SHRINK SPACE命令来联机移动HWM
(2)如果要同时压缩表的索引,可以发布:ALTER TABLE TEST_TAB SHRINK SPACE CASCADE