新特性的副產品--從11g的DEFERRED SEGMENT CREATION說起

       某日協助同事完成兩個測試數據庫的結構同步。將早就爛熟於心的exp和imp命令編寫成shell自動運行，交活了事。沒有想到，同事說同步的表相差巨大。不會吧，檢查了生成的日誌信息：

 

. exporting dimensions
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully without warnings.

        正常的一談糊塗。但是檢查導出表的數據確實差了不少。應該是49張表，但是導出的只有34張。

        反覆檢查USER_TABLES的信息，首先發現的就是確實沒有導出的表在某些屬性字段上比較怪異。

        

SQL> select INITIAL_EXTENT,NEXT_EXTENT from user_tables where table_name='TBL_NC_AREA_I';

INITIAL_EXTENT NEXT_EXTENT
-------------- -----------

         奇怪。爲空。

         沒有辦法，估計需要修改表的一些狀態纔可能改變。

SQL> alter table TBL_NC_AREA_I move;

Table altered.

SQL> select INITIAL_EXTENT,NEXT_EXTENT from user_tables where table_name='TBL_NC_AREA_I';

INITIAL_EXTENT NEXT_EXTENT
-------------- -----------
     65536     1048576

SQL>

         不錯，現在看起來比較正常了，exp也正常導出。

          真是爲什麼呢？存儲參數的信息沒有出現，而後在user_tables中發現了字段SEGMENT_CREATED。估計就是這個“問題”。找找看，發現凡是不能正常導出的表這個屬性字段都是顯示：       

select INITIAL_EXTENT,NEXT_EXTENT,SEGMENT_CREATED
from user_tables where table_name='TBL_NC_BALANCEBANK_I';

-------------- ----------- ---
               NO

         查。發現原來這個11gR2的一個特性：DEFERRED SEGMENT CREATION，即建立表的時候，一開始並沒有直接分配存儲空間。直接在字典中記錄了數據結構。而只有當真正有數據的時候才分配空間。這種方法對於象SAP這樣大的系統需要部署成千上萬張表是非常有效的。

         檢查測試數據庫：

SQL> show parameters deferred_segment_creation

NAME                     TYPE    VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation        boolean     TRUE

          這個功能是開啓的。當然可以通過修改參數來進行修改：

alter system set deferred_segment_creation=true;
session級別的方法相似。
如果在表一級：
CREATE TABLE .... SEGMENT CREATION IMMEDIATE;
需要延後分配：
CREATE TABLE ... SEGMENT CREATION DEFERRED

        當然還有我的“土製”辦法，move一下表。

         現在EXP是沒有問題。但是奇怪，爲什麼EXP只能檢索出已經分配存儲空間的表，難道讀的字典不是相同的基表？不能不說，這個特性對於EXP而言，起碼是有瑕疵的，並且在一些UPGRDE等操作也是有風險的。

        同時注意，這樣的表在SYS, SYSTEM, PUBLIC, OUTLN, or XDB 模式（schema）下，是無法建立的。

        時時都是有收穫的，只要留心些。 -:)

         --EOF