alter table move 與shrink space的區別

dawn009發表於2015-01-04

案例：

同事將一關鍵表中刪了多餘的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 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

查詢當前該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命令可以釋放空間（當然這語句最根本的作用還是移動表到不同的表空間去，這裡只是借用它可以釋放空間的一個特性），還要了解該動作會鎖表直到命令 結束，而且會導致索引失效，屬於危險命令，建議千萬不要在業務高峰期操作。

 


都知道alter table move 或shrink space可以收縮段，用來消除部分行遷移，消除空間碎片，使資料更緊密，但move 跟shrink space還是有區別的。
Move會移動高水位，但不會釋放申請的空間，是在高水位以下(below HWM)的操作。
而shrink space 同樣會移動高水位，但也會釋放申請的空間，是在高水位上下(below and above HWM)都有的操作。
也許很難理解吧，看測試就知道了。

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
2   for i in 1..100000 loop
3   insert into test values(i);
4   end loop;
5   end;
6   /

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 SEGME
NT_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 SEGME
NT_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。
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。

-------&gt>轉載於:http://blog.csdn.net/zhjxixi/article/details/7661378

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29119536/viewspace-1389210/，如需轉載，請註明出處，否則將追究法律責任。

相關文章