循序渐进AWR.docVIP

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。 SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, BYTES / 1024 / 1024? FROM DBA_SEGMENTS?WHERE TABLESPACE_NAME = SYSAUX; ? ?查询表wrh$_active_session_history中的数据，约1680，000条记录。 select count(*) from wrh$_active_session_history; ? 将该表中的数据按照event_id分组，查询产生数据量最多的事件的event_id和event_name。 可见主要事件为cursor: pin S wait on X（约1670，000条） SELECT A.EVENT_ID, B.NAME, COUNT(*)? FROM WRH$_ACTIVE_SESSION_HISTORY A, V$EVENT_NAME B?WHERE A.EVENT_ID = B.EVENT_ID?GROUP BY A.EVENT_ID, B.NAME; ? 由此，基本找到了sysaux表空间膨胀的原因：数据库中产生大量的“cursor: pin S wait on X”事件。 ? 3）.如何解决“cursor: pin S wait on X”事件 用google搜索一下，目前还没发现解决办法。有的帖子说这是oracle这个版本的bug（/720856.html）。 但是wrh$_active_session_history表中的数据可以减小。它的产生是由于开启了awr（auto workload repository）。定期从活动的session中产生快照，并保存在磁盘上（表wrh$_active_session_history），有一定的保留期。 默认情况下，oracle每个1小时产生一次快照，并将其保留7天。查询表dba_hist_wr_control可以看到： SQL select * from dba_hist_wr_control; ? DBID SNAP_INTERVAL RETENTION?? TOPNSQL---- ------------- ----------- ----------1148 +00000 00:1?? +00007 00:0 DEFAULT ? 那么，就可以通过四种途径解决： （1）关闭快照（影响：不会产生性能分析数据） （2）减小产生快照的频率（影响：产生粗糙的性能分析数据） （3）减小快照在磁盘中的保留期限（影响：只能保存短期的性能分析数据）。 （4）同时使用方法2和方法3（影响：同方法2和方法3）。 ? 4）.参考资料 oracle 10g 新特性中文笔记(第五章)：/post/76/21994 oracle10g AWR[zt] /post/419/308733 10gR2的wrh$_分区表快速膨胀怎么办？/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 若是一个普通的会话（我是指没有大量地耗费资源），则对于性能调整来说无足轻重。但若该会话在活动时大量占用了资源（比如：CPU，内存，I/O等），该会话信息的丢失，将无法评测当时的系统瓶颈究竟是什么。令DBA高兴的是，oracle10g中保留下了v$session_wait中的这些信息。 在10g中新出现了一个视图：v$session_wait_history。这个视图保存了每个活动session在v$session_wait中最近10次的等待事件。但这对于一段时期内的数据库性能状况的监测是