4、Truncate drop all storage行為

在11gR2中，Oracle有一個新特性就是deferred_segment_creation引數的引用。在之前的版本中，一旦建立資料表create語句執行，如果初始資料表中沒有資料，Oracle是不會建立segment結構，直到第一行資料被插入到資料表中。

這個新特性其實就開啟了段結構虛擬化的開端，drop all storage就是將原來保留的一個extent刪除掉。

首先將資料插入：

SQL> insert into t select * from dba_objects;

99693 rows inserted

SQL> commit;

Commit complete

段結構如下：

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='T' and owner='TEST';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28808 65536 8

1 4 28816 65536 8

2 4 28824 65536 8

（篇幅原因，有省略……）

26 4 30720 1048576 128

27 rows selected

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='IDX_T_ID' and owner='TEST';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28936 65536 8

1 4 28840 65536 8

2 4 28904 65536 8

（篇幅原因，有省略……）

17 4 30208 1048576 128

18 rows selected

刪除段結構。

SQL> truncate table t drop all storage;

Table truncated

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='T' and owner='TEST';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='IDX_T_ID' and owner='TEST';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

雖然沒有段結構，但是新的data_object_id編號已經分配了。

SQL> select object_name, object_id, data_object_id from dba_objects where owner='TEST' and object_name in ('T','IDX_T_ID');

OBJECT_NAME OBJECT_ID DATA_OBJECT_ID

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

IDX_T_ID 123667 123672

T 123666 123673

新段結構雖然沒有分配，但是新的編號已經分配。

5、sys使用者下的drop all storage

有一點一定注意：drop all storage特性只有在非sys使用者下才能使用。如果在sys中使用，drop all storage就和drop storage行為相同。

SQL> show user

User is "SYS"

SQL> create table t tablespace users as select * from dba_objects;

Table created

SQL> create index idx_t_id on t(object_id) tablespace users;

Index created

段結構如下：

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='IDX_T_ID' and owner='SYS';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28936 65536 8

1 4 28944 65536 8

（篇幅原因，有省略……）

15 4 30464 65536 8

16 4 30592 1048576 128

17 rows selected

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='T' and owner='SYS';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28808 65536 8

1 4 28816 65536 8

2 4 28824 65536 8

（篇幅原因，有省略……）

26 4 30336 1048576 128

27 rows selected

執行truncate table操作。

SQL> truncate table t drop all storage;

Table truncated

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='T' and owner='SYS';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28808 65536 8

SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where segment_name='IDX_T_ID' and owner='SYS';

EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

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

0 4 28936 65536 8

雖然使用了drop all storage，但是頭分割槽extent結構依然存在。

6、結論

Truncate系列引數給我們提供了控制行為的各種開關。那麼我們如何選擇呢？筆者認為：不同的業務操作場景，可以使用不同的truncate開關。一般的業務場景下，使用truncate table就是可以的。對於一些經常使用灌入資料的資料表，我們可以預見到過一段時間會有大規模資料insert進入（非append），我們就可以選擇reuse storage，這樣可以避免下次的頻繁空間分配。畢竟空間分配也要消耗資源和時間。對於新特性drop all storage，筆者個人覺得比較雞肋，在儲存日趨便宜的情況下，意義不是很大。

Truncate資料表背後的幾個引數（下）

相關文章