新特性的副產品--從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