ORA-03232故障

查询oracle数据库的时候碰到ORA-03232故障,到网上找到文章,很详细说明,特转载如下


http://www.itpub.net/thread-271012-1-1.htmlORA-03232故障解决一例


ORA-03232故障解决一例：
    环境：windows2000 server+oracle817
        应用程序运行过程中报错，信息如下：
    ORA-03232:无法分配81块（源于表空间3）的区

首先根据错误号查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 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 temporary  tablespace temp tempfile 'd:\oradata\temp01.dbf' size 300M
     extent management local uniform size 2M;






注意:修改了temp表空间的next段大小也可以解决

转载于:https://www.cnblogs.com/yifan268/archive/2010/04/20/1716218.html