ORA-03232故障解決一例

    環境：windows2000 server+oracle817
    應用程式執行過程中報錯，資訊如下：
    ORA-03232:無法分配81塊（源於表空間3）的區

[@more@]

首先根據錯誤號查Metalink(125271.1:How to Choose Extent Size for Temporary Tablespace to Prevent ORA-3232):
ORA-03232 unable to allocate an extent of string blocks from tablespace string
Cause: An attempt was made to specify a HASH_MULTIBLOCK_IO_COUNT value that is greater than the  tablespace's NEXT value.
Action: Increase the value of NEXT for the tablespace using ALTER TABLESPACE DEFAULT STORAGE or decrease  the value of

           HASH_ MULTIBLOCK_IO_COUNT.
This parameter determines how many sequential blocks a hash join reads and writes  in one IO operation. The maximum value is operating system dependent.   It is always less than the maximum I/O size of the operating system expressed as  Oracle blocks (MAX_IO_SIZE / DB_BLOCK_SIZE).
由此我們得知出現這個錯誤是由於雜湊連線時順序讀取或寫入的連續資料塊大小大於相應表空間的next_extent值而引發的。
我們首先根據錯誤資訊查出錯的表空間的資訊：
SQL> select * from v$tablespace where ts#=3;

       TS# NAME
---------- ------------------------------
         3 TEMP

SQL> select initial_extent,next_extent,extent_management from dba_tablespaces where tablespace_name='TEMP';

INITIAL_EXTENT NEXT_EXTENT EXTENT_MANAGEMENT
-------------- ----------- -----------------
        262144       65536 DICTIONARY
我們看到出錯的表空間為TEMP表空間，其next_extent大小為64K,採用字典管理方式。
再進一步看一下hash連線的情況：
SQL> show parameter hash_multiblock_io_count

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------------
hash_multiblock_io_count             integer     0

SQL> show parameter db_block_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
db_block_size                        integer     8192

SQL> select 81*8192 from dual;

   81*8192
----------
    663552
我們看到HASH_MULTIBLOCK_IO_COUNT採用的還是預設值0（MTS下則為1）。應用程式雜湊連線要求連續寫入81個資料塊，大小為663552bytes，而表空間的next_extent值只為64KB，遠小於此值，因此引發該錯誤。

根據metalink給出的建議，我們可以有兩種方法解決此錯誤：
1、增大表空間的next值，使之等於或大於作業系統的IO大小（不同OS有不同的值）。語法參考：alter tablespace temp default storage(next 1M);
2、設定HASH_MULTIBLOCK_IO_COUNT為非0的值。

但是我們根據剛才的查詢看到，TEMP表空間採用DMT方式。我們知道表空間在DMT方式下對效能有諸多影響，遠不如LMT來的靈活。因此在處理該問題的時候我並沒有按照metalink給出的兩種建議去做，而是把temp表空間刪除掉重建，採用本地管理的表空間，並設定uniform size（臨時表空間設定uniform size的時候要注意與初始化引數中sort_area_size相結合，一般為sort_area_size的整數倍。我一般喜歡將sort_area_size設為1M，uniform size設為2M）。最終解決辦法如下：
SQL> drop tablespace temp including contents;
SQL> create tablespace temp tempfile 'd:oradatatemp01.dbf' size 300M
     extent management local uniform size 2M;