今天在QQ群的技术讨论中有人提及AWR实际保留的天数并非10g的 7天 或 11g 的 8天 ,而是视乎SYSAUX表空间的使用率而定,当SYSAUX表空间空闲空间较多时会将AWR数据保留地更久。
虽然不知道以上这番理论出自那部书籍,但是至少是说的有模有样的,而且网友还告诉我这是他测试过的结果。
实际是这样吗?
我相信这位网友并没有吹牛,他很可能查询dba_hist_snapshot等AWR视图且看到了的确有7天之前的快照仍被保留着,而没有被清理掉。我们来重演他所看到的现场:
测试使用版本11.2.0.2 , 11g中默认AWR保留8天:
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production PL/SQL Release 11.2.0.2.0 - Production CORE 11.2.0.2.0 Production TNS for Linux: Version 11.2.0.2.0 - Production NLSRTL Version 11.2.0.2.0 - Production SQL> select * from global_name; GLOBAL_NAME ---------------------------------------------------------- www.askmac.cn & www.askmac.cn SQL> col SNAP_INTERVAL for a20 SQL> col RETENTION for a20 SQL> select snap_interval,retention from dba_hist_wr_control; SNAP_INTERVAL RETENTION -------------------- -------------------- +00000 01:00:00.0 +00008 00:00:00.0 以上确认了默认的快照间隔为1小时 ,且保留时间为8天 检查当前SYSAUX表空间的使用率 REM tablespace report set linesize 200 select a.tablespace_name, round(a.bytes_alloc / 1024 / 1024) megs_alloc, round(nvl(b.bytes_free, 0) / 1024 / 1024) megs_free, round((a.bytes_alloc - nvl(b.bytes_free, 0)) / 1024 / 1024) megs_used, round((nvl(b.bytes_free, 0) / a.bytes_alloc) * 100) Pct_Free, 100 - round((nvl(b.bytes_free, 0) / a.bytes_alloc) * 100) Pct_used, round(maxbytes / 1048576) Max from (select f.tablespace_name, sum(f.bytes) bytes_alloc, sum(decode(f.autoextensible, 'YES', f.maxbytes, 'NO', f.bytes)) maxbytes from dba_data_files f group by tablespace_name) a, (select f.tablespace_name, sum(f.bytes) bytes_free from dba_free_space f group by tablespace_name) b where a.tablespace_name = b.tablespace_name(+) union all select h.tablespace_name, round(sum(h.bytes_free + h.bytes_used) / 1048576) megs_alloc, round(sum((h.bytes_free + h.bytes_used) - nvl(p.bytes_used, 0)) / 1048576) megs_free, round(sum(nvl(p.bytes_used, 0)) / 1048576) megs_used, round((sum((h.bytes_free + h.bytes_used) - nvl(p.bytes_used, 0)) / sum(h.bytes_used + h.bytes_free)) * 100) Pct_Free, 100 - round((sum((h.bytes_free + h.bytes_used) - nvl(p.bytes_used, 0)) / sum(h.bytes_used + h.bytes_free)) * 100) pct_used, round(sum(f.maxbytes) / 1048576) max from sys.v_$TEMP_SPACE_HEADER h, sys.v_$Temp_extent_pool p, dba_temp_files f where p.file_id(+) = h.file_id and p.tablespace_name(+) = h.tablespace_name and f.file_id = h.file_id and f.tablespace_name = h.tablespace_name group by h.tablespace_name ORDER BY 1 / TABLESPACE_NAME MEGS_ALLOC MEGS_FREE MEGS_USED PCT_FREE PCT_USED MAX ------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- MGMT_AD4J_TS 200 199 1 99 1 32768 MGMT_ECM_DEPOT_TS 40 13 27 32 68 32768 MGMT_TABLESPACE 1350 86 1265 6 94 32768 SYSAUX 600 295 305 49 51 32768 SYSTEM 700 231 469 33 67 32768 TEMP 21 21 0 100 0 32768 UNDOTBS1 495 358 137 72 28 32768 USERS 1950 1243 707 64 36 32768 SYSAUX表空间剩余295MB空间,空闲率较高
因为这套数据库在2011-10-17之后就一直没有打开过,所以Automatic Workload Repository中最早保留的快照信息是在2011-10-10,通过查询dba_hist_snapshot视图可以反映这一点:
select snap_id, to_char(begin_interval_time, 'YYYY-MM-DD'), to_char(end_interval_time, 'YYYY-MM-DD') from dba_hist_snapshot order by snap_id; SNAP_ID TO_CHAR(BE TO_CHAR(EN ---------- ---------- ---------- 96 2011-10-10 2011-10-10 97 2011-10-10 2011-10-10 98 2011-10-10 2011-10-10 99 2011-10-10 2011-10-10 100 2011-10-10 2011-10-10 101 2011-10-10 2011-10-11 102 2011-10-11 2011-10-11 103 2011-10-11 2011-10-11 ................... 221 2011-10-17 2011-10-17 222 2011-10-24 2011-10-24 SQL> select sysdate from dual; SYSDATE --------- 24-OCT-11
当前的日期是24-OCT-11,而最早的快照信息是在2011-10-10,这样就达成了网友所说的AWR的保留时间并非7或8天,”awr保留天数根据sysaux大小决定。” 或 “默认7天,sysaux足够大这个7天没有意义” 的说法。
事实是这样吗?
不是的!
那么为什么能看到早于7天的快照呢?
回答: 不要被所看到的信息所蒙蔽,虽然我们常说事实胜于雄辩或实践是检验真知的唯一 , 但事情的表象往往会欺骗我们。
以上这个问题的关键点并非在于是否能看到早于7天的snapshot快照信息,而在于当MMON后台进程(该进程负责收集和清理AWR数据)在执行对过期快照清理工作时是否会清除7 或 8 天之前的snapshot,以及MMON后台进程多久才Purge一次AWR Snapshot。
以上这些问题 , 我们可以通过_swrf_test_action参数和10046 trace搞清楚:
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ 2 FROM SYS.x$ksppi x, SYS.x$ksppcv y 3 WHERE x.inst_id = USERENV ('Instance') 4 AND y.inst_id = USERENV ('Instance') 5 AND x.indx = y.indx 6 AND x.ksppinm LIKE '%_swrf%'; NAME VALUE DESCRIB -------------------- ---------- -------------------------------------------------- _swrf_test_action 0 test action parameter for SWRF _swrf_mmon_flush TRUE Enable/disable SWRF MMON FLushing _swrf_mmon_metrics TRUE Enable/disable SWRF MMON Metrics Collection _swrf_metric_frequen FALSE Enable/disable SWRF Metric Frequent Mode Collectio t_mode n _swrf_on_disk_enable TRUE Parameter to enable/disable SWRF d _swrf_mmon_dbfus TRUE Enable/disable SWRF MMON DB Feature Usage _swrf_test_dbfus FALSE Enable/disable DB Feature Usage Testing
_swrf_test_action 隐藏参数用以调试MMON的行为,设置该参数并10046事件:
SQL> alter session set "_swrf_test_action" = 28; Session altered. SQL> alter session set "_swrf_test_action" = 10; Session altered. [oracle@vrh4 ContentsXML]$ ps -ef|grep mmon oracle 2872 1 0 18:28 ? 00:00:00 ora_mmon_SBDB oracle 3446 3289 0 18:44 pts/1 00:00:00 tail -f SBDB_mmon_2872.trc oracle 3997 3407 0 19:17 pts/2 00:00:00 grep mmon SQL> oradebug setospid 2872; Oracle pid: 15, Unix process pid: 2872, image: [email protected] (MMON) SQL> oradebug event 10046 trace name context forever,level 12; Statement processed.
完成以上操作后等待一段时间,MMON进程的trace文件会陆续写出一些信息,如:
*** 2011-10-24 18:45:24.795 KEWRAFM: Beginning one MMON Auto-Flush cycle ... Finished one MMON Auto-Flush cycle. *** 2011-10-24 18:46:24.874 KEWRAFM: Beginning one MMON Auto-Flush cycle ... Finished one MMON Auto-Flush cycle. *** 2011-10-24 18:47:24.952 KEWRAFM: Beginning one MMON Auto-Flush cycle ... Finished one MMON Auto-Flush cycle. *** 2011-10-24 18:48:25.053 KEWRAFM: Beginning one MMON Auto-Flush cycle ... Finished one MMON Auto-Flush cycle.
说明MMON每分钟都会自动刷新一定的数据到磁盘上。
此外还可以看到MMON清理过期快照的信息:
*** 2011-10-24 18:58:25.290
KEWRAFM: Beginning one MMON Auto-Flush cycle ...
Finished one MMON Auto-Flush cycle.
KEWRAPM: Beginning one MMON Auto-Purge cycle ...
KEWRAPM: Finished one MMON Auto-Purge cycle.
KEWRAPC: Auto Purge Action Completed.
*** 2011-10-24 19:28:26.091
KEWRAFM: Beginning one MMON Auto-Flush cycle ...
Finished one MMON Auto-Flush cycle.
KEWRAPM: Beginning one MMON Auto-Purge cycle ..
KEWRAPM: Finished one MMON Auto-Purge cycle
*** 2011-10-24 19:58:27.041
KEWRAFM: Beginning one MMON Auto-Flush cycle ...
Finished one MMON Auto-Flush cycle.
KEWRAPM: Beginning one MMON Auto-Purge cycle ...
KEWRAPM: Finished one MMON Auto-Purge cycle.
可以看到在默认情况下MMON每30分钟会自动去清理一次Automatic Workload Repository自动负载仓库中的过期快照信息,当18:58:25.290的第一次清理工作完成后查询dba_hist_snapshot可以发现过期快照消失了:
SQL> select snap_id, 2 to_char(begin_interval_time, 'YYYY-MM-DD'), 3 to_char(end_interval_time, 'YYYY-MM-DD') 4 from dba_hist_snapshot 5 order by snap_id; SNAP_ID TO_CHAR(BE TO_CHAR(EN ---------- ---------- ---------- 194 2011-10-16 2011-10-16 195 2011-10-16 2011-10-16 196 2011-10-16 2011-10-16 197 2011-10-16 2011-10-16 ................. 222 2011-10-24 2011-10-24
通过以上演示我们可知AWR快照的保留天数与SYSAUX的使用率并无关系,实际控制AWR保留天数的最主要因素是MMON何时、如何地清理过期快照? MMON的清理操作直接受到dba_hist_wr_control.retention设置值的影响,默认情况10g 为保留7天,而11g为保留8天,MMON只已清理过期的快照。
同时KEWRAPM的trace信息也说明了,默认情况下MMON每30分钟做一次”MMON Auto-Purge cycle”清理工作。
Leave a Reply