altertablemove与shrinkspace的区别是什么

这篇文章将为大家详细讲解有关alter table move 与shrink space的区别是什么,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

目前创新互联已为上1000家的企业提供了网站建设、域名、网站空间、网站改版维护、企业网站设计、翼城网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

一、move
案例:

同事将一关键表中删了多余的300w条数据后,程序就变的异常缓慢。分析得出,应该是表空间碎片过多,旧的索引效率过低。

执行下面两句话:

alter table ycsbt_qyygxx_jb move;

alter index R_SBXX_YCSBD_FK rebuild online;

效果非常明显。

deltete不会释放表空间,但是可以重用,也就是插入可以填补空洞,当然现实应用中确实是存在经常删除很少插入的情况,这样就存在了释放表空间优化数据库的可行性了,truncate有不能带条件的缺陷,自然就想到用alter table move重移表空间的方法。这里要注意三个要素

1、  alter table move 省略了tablespace XXX, 表示用户移到自己默认的表空间,因此当前表空间至少要是该表两倍大,这很好理解,由于易错所以提出,就不再细说了。

2、  alter table move过程中会导致索引失效,必须要考虑重新索引

3、  alter table move过程中会产生锁,应该避免在业务高峰期操作!


就第二点和第三点做实验说明如下

Connected toOracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as ljb


--先获取该SESSION的SID,方便实验观察

SQL> select sid from v$mystat where rownum=1;

     SID

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

     160

SQL> create table ljb_test as select * from dba_objects;

Table created

SQL> select count(*) from ljb_test;

  COUNT(*)

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

   62659

SQL> create index idx_test on ljb_test(object_id);

Index created


--查询当前该SESSION并无锁

SQL> select * from v$lock where sid=160;

ADDR     KADDR     SID TYPE     ID1      ID2      LMODE    REQUEST      CTIME      BLOCK

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


--查看索引状态也正常!

SQL> select index_name,table_name,status from user_indexes where table_name='LJB_TEST';

INDEX_NAME                TABLE_NAME                     STATUS

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

IDX_TEST                       LJB_TEST                       VALID

--执行命令alter table ljb_test move;


---查询:

select * from v$lock where sid=160;

ADDR     KADDR       SID  TYPE     ID1        ID2  LMODE  REQUEST  CTIME  BLOCK

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

2043451C 20434530       160   CF         0          0       4        0        0         0

1FA072BC 1FA073D8     160   TX    917534         592      6        0        1         0

204344C0 204344D4       160  HW        76    323783147     6        0        0         0

1F9C4224 1F9C423C      160  TM     84825          0        6        0        0         0

204342F4 20434308       160   TT        76         16       4        0         0        0

1F9C377C 1F9C37C4     160   TS        76    323783147      6        0        0         0

--不过由于alter table move命令未结束,索引仍然有效!

SQL> select index_name,table_name,status from user_indexes where table_name='LJB_TEST';

INDEX_NAME                TABLE_NAME                     STATUS

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

IDX_TEST                       LJB_TEST                       VALID

--等alter table ljb_test move;命令结束后,再查看发现锁消失了

SQL>  select * from v$lock where sid=160;

ADDR     KADDR  SID TYPE        ID1       ID2      LMODE    REQUEST      CTIME      BLOCK

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


--但是索引却失效了!

SQL> select index_name,table_name,status from user_indexes where table_name='LJB_TEST';

INDEX_NAME                  TABLE_NAME                     STATUS

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

IDX_TEST                       LJB_TEST                       UNUSABLE

总结:这个实验说明:除了知道alter table move命令可以释放空间(当然这语句最根本的作用还是移动表到不同的表空间去,这里只是借用它可以释放空间的一个特性),还要了解该动作会锁表直到命令结束,而且会导致索引失效,属于危险命令,建议千万不要在业务高峰期操作。

 

二、shrink

都知道alter table move 或shrink space可以收缩段,用来消除部分行迁移,消除空间碎片,使数据更紧密,但move 跟shrink space还是有区别的。
Move会移动高水位,但不会释放申请的空间,是在高水位以下(below HWM)的操作。
而shrink space 同样会移动高水位,但也会释放申请的空间,是在高水位上下(below and above HWM)都有的操作。

使用Shrink有两个前提条件:
    表必须启用row movement
    表段所在表空间的段空间管理(segment space management)必须为auto

在线段收缩的语法如下:
alter table/index/materialized view object_name shrink space [cascade] [compact];

cascade:是指压缩所有依赖的对象,比如压缩表语句加上cascade,表上所有的索引都会被压缩
compact:把压缩过程分为两个阶段:第一个阶段的语句带compact,压缩段空间,在这个过程中需要在表上加RX锁,即只在需要移动的行上加锁。由于涉及到rowid的改变,需要enable row movement.同时要disable基于rowid的trigger.这一过程对业务影响比较小。;第二个阶段语句不带compact,调整高水位并释放收回的空间。此过程需要在表上加X锁,会造成表上的所有DML语句阻塞。在业务特别繁忙的系统上可能造成比较大的影响。对于大表,建议采用compact选项。


也许很难理解吧,看测试就知道了。

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SQL> create table test (id number) storage (initial 10m next 1m) tablespace users;

Table created.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> col SEGMENT_NAME for a10
SQL> select SEGMENT_NAME,EXTENTS,BLOCKS,INITIAL_EXTENT/1024/1024 init from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS       INIT
---------- ---------- ---------- ----------
TEST               10       1280         10

SQL> col TABLE_NAME for a10
SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST                0         1280

--TEST表初始分配了10M的空间,可以看到有10个EXTENTS,1280个BLOCKS。USER_TABLES视图显示有0个使用的BLOCKS,1280个空闲BLOCKS,即该10M空间内的BLOCK都还没被ORACLE”格式化”。

SQL> begin
   for i in 1..100000 loop
   insert into test values(i);
   end loop;
   end;
   /

PL/SQL procedure successfully completed.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS
---------- ---------- ----------
TEST               10       1280

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST              186         1094

--插入10W条数据后,分配的空间仍不变,因为10个EXTENTS还没使用完。显示使用了186个BLOCKS,空闲1094个BLOCKS。这时候的186BLOCKS即是高水位线

SQL> delete from test where rownum<=50000;

50000 rows deleted.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS
---------- ---------- ----------
TEST               10       1280

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST              186         1094

SQL> select count(distinct dbms_rowid.rowid_block_number(rowid)) used_blocks from test;

USED_BLOCKS
-----------
         77

--这边可以看到,删掉一半数据后,仍然显示使用了186个BLOCKS,高水位没变。但查询真正使用的BLOCK数只有77个。所以DELETE操作是不会改变HWM的

SQL> alter table test move;

Table altered.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST               81         1199

--MOVE之后,HWM降低了,空闲块也上去了

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS
---------- ---------- ----------
TEST               10       1280

--但是分配的空间并没有改变,仍然是1280个BLOCKS。下面看用SHRINK SPACE的方式

SQL> alter table test enable row movement;

Table altered.

SQL> alter table test shrink space;

Table altered.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS
---------- ---------- ----------
TEST                1         88

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST               81            7
--分配的空间已经降到最小,1个EXTENTS ,88个BLOCKS


所以MOVE并不算真正意义上的压缩空间,只会压缩HWM以下的空间,消除碎片。我们一般建表时没有指定initial参数(默认是8个BLOCK),也就感觉不到这个差异。而SHRINK SPACE真正做到了对段的压缩,包括初始分配的也压了,所以它是blow and above HWM操作。
至于需要哪种方法,得看你的需求来了,需要分析表的增长情况,要是以后还会达到以前的HWM高度,那显然MOVE是更合适的,因为SHRINK SPACE还需要重新申请之前放掉的空间,无疑增加了操作。

注意:

1.不过用MOVE的方式也可以做到真正的压缩分配空间,只要指定STORAGE参数即可。

SQL> drop table test;

Table dropped.

SQL> create table test (id number) storage (initial 10m next 1m) tablespace users;

Table created.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS,INITIAL_EXTENT/1024/1024 init from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS       INIT
---------- ---------- ---------- ----------
TEST               10       1280         10

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST                0         1280

SQL> alter table test move storage (initial 1m);

Table altered.

SQL> analyze table test compute statistics;

Table analyzed.

SQL> select SEGMENT_NAME,EXTENTS,BLOCKS,INITIAL_EXTENT/1024/1024 init from user_segments where SEGMENT_NAME='TEST';

SEGMENT_NA    EXTENTS     BLOCKS       INIT
---------- ---------- ---------- ----------
TEST              16        128          1

SQL> select TABLE_NAME,BLOCKS,EMPTY_BLOCKS from user_tables where table_name='TEST';

TABLE_NAME     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
TEST               0          128

2.使用move时,会改变一些记录的ROWID,所以MOVE之后索引会变为无效,需要REBUILD。同时move表需要2倍的表空间,而shrink不需要

3.使用shrink space时,索引会自动维护。如果在业务繁忙时做压缩,可以先shrink space compact,来压缩数据而不移动HWM,等到不繁忙的时候再shrink space来移动HWM。

4.索引也是可以压缩的,压缩表时指定Shrink space cascade会同时压缩索引,也可以alter index xxx shrink space来压缩索引。

5.shrink space需要在表空间是自动段空间管理的,所以system表空间上的表无法shrink space。

6.shrink的限制

关于alter table move 与shrink space的区别是什么就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。


新闻名称:altertablemove与shrinkspace的区别是什么
文章分享:http://scyanting.com/article/ggjejs.html