症状 12.1版本中因为监控⾏为,导致 MMON 进程占⽤⼤量的CPU。⼤量的 CPU 时间花费在 MMON_SLAVE 的执⾏监控的 SQL 语句: WITH MONITOR_DATA AS (SELECT INST_ID, KEY, NVL2(PX_QCSID, NULL, STATUS)STATUS, FIRST_REFRESH_TIME, LAST_REFRESH_TIME, REFRESH_COUNT, PROCESS_NAME, SID, SQL_ID, SQL_EXEC_START, SQL_EXEC_ID, DBOP_NAME, DBOP_EXEC_ID, SQL_PLAN_HASH_VALUE, SESSION_SERIAL#, SQL_TEXT, IS_FULL_SQLTEXT, PX_SERVER#, PX_SERVER_GROUP, PX_SERVER_SET, PX_QCINST_ID, PX_QCSID, CASE WHEN ELAPSED_TIME < (CPU_TIME+ APPLICATION_WAIT_TIME+ CONCURRENCY_WAIT_TIME+ CL ...;
⽆论是 RAC 或⾮ RAC,在告警⽇志中会不断出现ORA-12850的报错,失败的 SQL 语句都是基于 GV$SQL_MONITOR 的查询。错误 信息:
Thu Sep 08 04:00:41 2016 Errors in file /app/oracle/diag/rdbms/dbname/dbinstance/trace/dbinstance_m002_14490.trc: ORA-12850: Could not allocate slaves on all specified instances: 3 needed, 2 allocated
在没有使⽤并⾏时,也会有 ORA-12751的错误出现。
原因 12C 中引⼊ “⾃动捕获报告” 的特性,该特性的其中⼀部分功能,MMON_SLAVE 进程会监控占⽤资源较多的 SQL,并且⾃动对这些 SQL 产⽣ SQL 监控报告。 作为新特性,这些SQL占⽤⼀定的CPU资源也是预期的。这些SQL可以在(G)V$SQLSTATS中查询到。 如果相关的 SQL 占⽤太多的 CPU 资源,那么是不正常的,很可能是由于优化器使⽤了不好的执⾏计划引起。 可能是和12C的新特性“⾃适应查询” 有关:
解决⽅案 1,关闭“⾃动捕获报告”的特性。注意:_report_capture_cycle_time=0 /* 该参数可以在数据库⽴即修改 */ SQL> alter system set "_report_capture_cycle_time"=0; /* Default is 60 seconds */ 上⾯的设置没有任何负⾯影响,该设置只会关闭“⾃动捕获报告”的特性,不会关闭原来的 SQ Monitor 的功能,SQL Monitor 的功能可以被 正常使⽤。
或者
2,在 OS 层⾯杀掉 MMON_SLAVE 进程,sid和serial可以在 ASH 数据中获得。 |