通过分析oracle sysaux表空间下的各模块信息：SELECT t.OCCUPANT_NAME,SUM(t.SPACE_USAGE_KBYTES)/1024/1024 FROM gV$SYSAUX_OCCUPANTS t GROUP BY t.OCCUPANT_NAME ORDER BY 2 DESC;OCCUPANT_NAMESUM(t.SPACE_U
下午分析SYSAUX表空间时，还发现有一个配有流复制的数据库上有一张表STREAMS$_APPLY_SPILL_MESSAGES占据了此表空间很大的一部分空间约15g。此表是用来存储流复制应用时，对于大小超过TXN_LCR_SPILL_THRESHOLD限制的大事务，从流池中溢出来的信息.参看SYSAUX tablespace grows quite fast due to Apply spill
近一段时间监控生产数据库的表空间使用情况，发现SYSAUX表空间非常大（17g之多），而且每天都有几十M的增长，看到此现象后，认为这很不正常，分析SYSAUX表空间那些segments占用空间比较大：SELECT SUM(T.BYTES)/1024/1024 segments_SIZE,T.segment_name FROM Dba_Segments t WHERE t.table
在下午的检查中，还发现另外几个对象在sysaux表空间中占据很大的空间：I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST，大小为4124M，WRI$_OPTSTAT_HISTGRM_HISTORY，大小为2893M，前者是后者的索引，此表是用来保存历史的的收集统计信息的。查看metalink相关文章：Statistics space used by SM/OPTSTAT in the
在使用RMAN从AUTOBACKUP中恢复SPFILE，可能会碰到这个错误，这里简单总结一下。在RMAN恢复SPFILE过程中，可能遇到下面的错误： RMAN> restore spfile from autobackup; Starting restore at 27-6月 -07 using
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
