alter table move 與shrink space的區(qū)別是什么

這篇文章將為大家詳細(xì)講解有關(guān)alter table move 與shrink space的區(qū)別是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

一、move
案例：

同事將一關(guān)鍵表中刪了多余的300w條數(shù)據(jù)后，程序就變的異常緩慢。分析得出，應(yīng)該是表空間碎片過多，舊的索引效率過低。

執(zhí)行下面兩句話：

alter table ycsbt_qyygxx_jb move;

alter index R_SBXX_YCSBD_FK rebuild online;

效果非常明顯。

deltete不會釋放表空間，但是可以重用，也就是插入可以填補空洞，當(dāng)然現(xiàn)實應(yīng)用中確實是存在經(jīng)常刪除很少插入的情況，這樣就存在了釋放表空間優(yōu)化數(shù)據(jù)庫的可行性了，truncate有不能帶條件的缺陷，自然就想到用alter table move重移表空間的方法。這里要注意三個要素

1、  alter table move 省略了tablespace XXX, 表示用戶移到自己默認(rèn)的表空間，因此當(dāng)前表空間至少要是該表兩倍大，這很好理解，由于易錯所以提出，就不再細(xì)說了。

2、  alter table move過程中會導(dǎo)致索引失效，必須要考慮重新索引

3、  alter table move過程中會產(chǎn)生鎖，應(yīng)該避免在業(yè)務(wù)高峰期操作！

就第二點和第三點做實驗說明如下

Connected to Oracle 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

--查詢當(dāng)前該SESSION并無鎖

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

ADDR     KADDR     SID TYPE     ID1      ID2      LMODE    REQUEST      CTIME      BLOCK

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

--查看索引狀態(tài)也正常！

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

--執(zhí)行命令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命令未結(jié)束，索引仍然有效！

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;命令結(jié)束后，再查看發(fā)現(xiàn)鎖消失了

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

總結(jié)：這個實驗說明：除了知道alter table move命令可以釋放空間（當(dāng)然這語句最根本的作用還是移動表到不同的表空間去，這里只是借用它可以釋放空間的一個特性），還要了解該動作會鎖表直到命令結(jié)束，而且會導(dǎo)致索引失效，屬于危險命令，建議千萬不要在業(yè)務(wù)高峰期操作。

二、shrink

都知道alter table move 或shrink space可以收縮段，用來消除部分行遷移，消除空間碎片，使數(shù)據(jù)更緊密，但move 跟shrink space還是有區(qū)別的。
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.這一過程對業(yè)務(wù)影響比較小。；第二個階段語句不帶compact，調(diào)整高水位并釋放收回的空間。此過程需要在表上加X鎖，會造成表上的所有DML語句阻塞。在業(yè)務(wù)特別繁忙的系統(tǒng)上可能造成比較大的影響。對于大表，建議采用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空間內(nèi)的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條數(shù)據(jù)后，分配的空間仍不變，因為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

--這邊可以看到，刪掉一半數(shù)據(jù)后，仍然顯示使用了186個BLOCKS，高水位沒變。但查詢真正使用的BLOCK數(shù)只有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
--分配的空間已經(jīng)降到最小，1個EXTENTS ，88個BLOCKS

所以MOVE并不算真正意義上的壓縮空間，只會壓縮HWM以下的空間，消除碎片。我們一般建表時沒有指定initial參數(shù)(默認(rèn)是8個BLOCK)，也就感覺不到這個差異。而SHRINK SPACE真正做到了對段的壓縮，包括初始分配的也壓了，所以它是blow and above HWM操作。
至于需要哪種方法，得看你的需求來了，需要分析表的增長情況，要是以后還會達(dá)到以前的HWM高度，那顯然MOVE是更合適的，因為SHRINK SPACE還需要重新申請之前放掉的空間，無疑增加了操作。

注意：

1.不過用MOVE的方式也可以做到真正的壓縮分配空間，只要指定STORAGE參數(shù)即可。

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之后索引會變?yōu)闊o效，需要REBUILD。同時move表需要2倍的表空間，而shrink不需要

3.使用shrink space時，索引會自動維護(hù)。如果在業(yè)務(wù)繁忙時做壓縮，可以先shrink space compact，來壓縮數(shù)據(jù)而不移動HWM，等到不繁忙的時候再shrink space來移動HWM。

4.索引也是可以壓縮的，壓縮表時指定Shrink space cascade會同時壓縮索引，也可以alter index xxx shrink space來壓縮索引。

5.shrink space需要在表空間是自動段空間管理的，所以system表空間上的表無法shrink space。

6.shrink的限制

關(guān)于alter table move 與shrink space的區(qū)別是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。