【循序渐进Oracle】全面认识SYSAUX表空间

编辑手记： 为了简化管理支持oracle特性的对象，Oracle 10g版本中增加了SYSAUX表空间，它包含一些以前位于system表空间中的对象，并且集中存储支持Oracle特性的对象，因为SYSAUX的特殊性，在运维中可能会遇到各种问题，今天我们来全面认识SYSAUX表空间。本文摘自【循序渐进Oracle】一书。

在创建数据库的过程中，有这样一条语句：

SYSAUX DATAFILE SIZE 120M AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

这个语句用来创建一个新的表空间SYSAUX表空间，这个表空间在Oracle10g之前并不存在，而是在Oracle 10g中被引入，用来作为SYSTEM表空间的辅助表空间。

• 作为辅助表空间，以前一些使用系统表空间或独立表空间的数据库组件现在在SYSAUX表空间中创建，通过分离这些组件，SYSTEM表空间的负荷得以减轻。

• 而且通过使用SYSAUX表空间，反复创建一些相关对象及组件引起的空间问题得以避免，通过剥离，SYSTEM表空间的作用更加单纯，更易于管理和维护。

• 另外，如果SYSAUX表空间出现问题，如空间耗尽等，数据库的核心功能将保持有效。

下表列出了Oracle 10g中这些组件和以前版本的对照，可以注意到很多组件现在从SYSTEM表空间中转移出来，以前因为这些组件引发的系统表空间故障非常常见。

新增的V$SYSAUX_OCCUPANTS视图可以用来查看这些信息：

SYSAUX表空间作为SYSTEM的辅助表空间，具有如下一些限制。

• 不能删除。

SQL> drop tablespace SYSAUX including contents and datafiles;

drop tablespace SYSAUX including contents and datafiles

*

ERROR at line 1:

ORA-13501: Cannot drop SYSAUX tablespace

• 不能重命名。

SQL> alter tablespace SYSAUX rename toOPT_TBS;

alter tablespace SYSAUX rename to OPT_TBS

*

ERROR at line 1:

ORA-13502:Cannot rename SYSAUX tablespace

• 不能置为read only。

SQL> alter tablesapce SYSAUX read only;

alter tablesapce SYSAUX read only

      *

ERROR at line 1:

ORA-00940:invalid ALTER command

如果希望转移这些系统对象的表空间，可以使用相应的系统包实现：

如转换LOGMNER空间：

SQL> exec SYS.DBMS_LOGMNR_D.SET_TABLESPACE('USERS');

PL/SQL procedure successfully completed.

接下来再检查LOGMNR在SYSAUX中的空间占用：

看到LOGMNR的空间占用已经变为0。而相关对象已经转移到了USERS表空间：

SYSAUX表空间的使用情况可以通过DB Control清晰地看到，从EM首页中的数据库实例→管理→表空间→SYSAUX来查看，如图5-26所示，通过分析图表，空间的使用情况一目了然。

在以前的版本中，系统表空间被过度使用的最常见原因是由于高级复制引起的，缺省地，高级复制的系统对象被创建在SYSTEM表空间中，由于高级复制的队列表等可能会扩展到极其夸张的大小，所以可能会造成严重的系统故障。

以我处理过的一个案例为例（Oracle10gR1 RAC环境，架构于Solaris之上），来看一下该数据库系统的Top 8空间使用对象：

注意到，DEF$_LOB、DEF$_AQCALL都是和高级复制有关的原数据表，这两个表就占用了8092MB的空间，而另外一个63637MB大小的LOBSEGMENT也与高级复制有关，这3个表加起来已经占用了70多个GB的空间，而且都在SYSTEM表空间之中，这实在是个灾难。

实际上在创建之初，就应该将这些对象分离到SYSAUX表空间或其他独立的表空间，减少对于系统表空间的冲击。

这些问题加上用户的一些不当操作，最终导致了数据库故障。而且这个环境相当复杂，“Oracle10gR1 + CRS + ASM”的两套RAC环境间的高级复制，处理过程着实花了一番功夫。

然而需要注意的是，即使在Oracle10gR2/Oracle 11gR2中，Oracle仍然没有改变，Oracle仍然会缺省地将所有复制的系统队列表（queue table）置于系统表空间之中。

复制字典对象的存储地都是SYSTEM表空间：

一般建议在初始创建数据库时，可以通过修改队列创建脚本$ORACLE_HOME/rdbms/admin/catdefrt.sql定义存储参数来更改创建地点。

如果已经完成了创建，可以通过EXP/IMP等一系列手段迁移队列表，不过通常迁移操作都会影响高级复制的使用，这对于一个上线的24×7业务系统来说，通常都极为困难，所以最好的方法仍然是提前规划。

最后体会深刻的是，不管哪一项技术，前期的规划都极其重要，如果规划不当，后期的问题将会曾出不穷。在设计规划数据库的结构和应用上，Oracle的很多优化方案是值得我们借鉴的，将重要数据和次要数据分开，既可以避免次要数据在存储、IO上的竞争，又可以将重要数据的存储纯净化，从而方便备份恢复以及相关维护。