循序渐进AWR.doc

0、问题起源：正式库中sysaux表空间膨胀
1）.正式库中sysaux情况介绍:
正式库中的sysaux表空间初始设置为800m，上个月占用率达到97%，警告日志中出现SYSAUX表空间不足的信息。将其扩充到1300m。
前几天又出现sysaux表空间不足的信息，使用率达到93%，警告日志中出现SYSAUX表空间不足的信息。该表空间又被扩充100m，达到1400m。
目前使用率是90%，剩余空间约120m。
2）.表空间膨胀原因
通过查询表dba_segments，可看到该表空间中占用空间最多的表为：wrh$_active_session_history（约380m）及该表索引（约65m）。共计约450m。
SELECTOWNER,SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024FROMDBA_SEGMENTSWHERETABLESPACE_NAME='SYSAUX';

查询表wrh$_active_session_history中的数据，约1680，000条记录。
selectcount(*)fromwrh$_active_session_history;

将该表中的数据按照event_id分组，查询产生数据量最多的事件的event_id和event_name。
可见主要事件为cursor:pinSwaitonX（约1670，000条）
SELECTA.EVENT_ID,B.NAME,COUNT(*)FROMWRH$_ACTIVE_SESSION_HISTORYA,V$EVENT_NAMEBWHEREA.EVENT_ID=B.EVENT_IDGROUPBYA.EVENT_ID,B.NAME;

由此，基本找到了sysaux表空间膨胀的原因：数据库中产生大量的“cursor:pinSwaitonX”事件。

3）.如何解决“cursor:pinSwaitonX”事件
用google搜索一下，目前还没发现解决办法。有的帖子说这是oracle这个版本的bug（HYPERLINK"http://www.itpub.net/720856.html"http://www.itpub.net/720856.html）。
但是wrh$_active_session_history表中的数据可以减小。它的产生是由于开启了awr（autoworkloadrepository）。定期从活动的session中产生快照，并保存在磁盘上（表wrh$_active_session_history），有一定的保留期。
默认情况下，oracle每个1小时产生一次快照，并将其保留7天。查询表dba_hist_wr_control可以看到：
SQL>select*fromdba_hist_wr_control;

DBIDSNAP_INTERVALRETENTIONTOPNSQL--------------------------------------1148+0000000:1+0000700:0DEFAULT

那么，就可以通过四种途径解决：
（1）关闭快照（影响：不会产生性能分析数据）
（2）减小产生快照的频率（影响：产生粗糙的性能分析数据）
（3）减小快照在磁盘中的保留期限（影响：只能保存短期的性能分析数据）。
（4）同时使用方法2和方法3（影响：同方法2和方法3）。

4）.参考资料
oracle10g新特性中文笔记(第五章)：HYPERLINK"http://mugen.itpub.net/post/76/21994"http://mugen.itpub.net/post/76/21994
oracle10gAWR[zt]HYPERLINK"http://xsb.itpub.net/post/419/308733"http://xsb.itpub.net/post/419/308733
10gR2的wrh$_分区表快速膨胀怎么办？HYPERLINK"http://xzh2000.itpub.net/post/96/210366"http://xzh2000.itpub.net/post/96/210366

一、WHY——为什么会出现ASH和AWR？
1.10g之前
用户的连接将产生会话，当前会话记录保存在v$session中；处于等待状态的会话会被复制一份放在v$session_wait中。当该连接断开后，其原来的连接信息在v$session和v$session_wait中就会被删除。这是10g之前的状况。
2.v$session_wait_history与ASH
若是一个普通的会话（我是指没有大量地耗费资源），则对于性能调整来说无足轻重。但若该会话在活动时大量占用了资源（比如：CP