编辑手记： 为了简化管理支持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表空间及其组件
作为辅助表空间，以前一些使用系统表空间或独立表空间的数据库组件现在在SYSAUX表空间中创建，通过分离这些组件，SYSTEM表空间的负荷得以减轻。
而且通过使用SYSAUX表空间，反复创建一些相关对象及组件引起的空间问题得以避免，通过剥离，SYSTEM表空间的作用更加单纯，更易于管理和维护。
另外，如果SYSAUX表空间出现问题，如空间耗尽等，数据库的核心功能将保持有效。
下表列出了Oracle 10g中这些组件和以前版本的对照，可以注意到很多组件现在从SYSTEM表空间中转移出来，以前因为这些组件引发的系统表空间故障非常常见。
使用SYSAUX表空间的组件
以前版本所在表空间
Analytical Workspace Object Table
SYSTEM
Enterprise Manager Repository
OEM_REPOSITORY
LogMiner
SYSTEM
Logical Standby
SYSTEM
OLAP API History Tables
CWMLITE
Oracle Data Mining
ODM
Oracle Spatial
SYSTEM
Oracle Streams
SYSTEM
Oracle Text
DRSYS
Oracle Ultra Search
DRSYS
Oracle interMedia ORDPLUGINS Components
SYSTEM
Oracle interMedia ORDSYS Components
SYSTEM
Oracle interMedia SI_INFORMTN_SCHEMA Components
SYSTEM
Server Manageability Components
New in Oracle10g
Statspack Repository
User-defined
Unified Job Scheduler
New in Oracle10g
Workspace Manager
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
SYSAUX空间组件的转移
如果希望转移这些系统对象的表空间，可以使用相应的系统包实现：
如转换LOGMNER空间：
SQL> execSYS.DBMS_LOGMNR_D.SET_TABLESPACE('USERS');
PL/SQL procedure successfully completed.
接下来再检查LOGMNR在SYSAUX中的空间占用：
看到LOGMNR的空间占用已经变为0。而相关对象已经转移到了USERS表空间：
SYSAUX表空间的使用情况可以通过DB Control清晰地看到，从EM首页中的数据库实例→管理→表空间→SYSAUX来查看，如图5-26所示，通过分析图表，空间的使用情况一目了然。
SYSAUX的作用与意义
在以前的版本中，系统表空间被过度使用的最常见原因是由于高级复制引起的，缺省地，高级复制的系统对象被创建在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上的竞争，又可以将重要数据的存储纯净化，从而方便备份恢复以及相关维护。
如何加入"云和恩墨大讲堂"微信群
