一、故障描述

1. 客户生产库出现卡顿现象， cpu 跑满，排查。

2. 一线工程师事后查看 dba 历史视图发现与卡顿时间看到的 event 不同。

二、问题详细诊断过程

1 、问题一（卡顿）

根据 cpu 消耗排序查看语句与等待事件（方法很多、非唯一）

set line 222 pages 999
col username for a10
col event for a35
col program for a20 truncate
col cpu_p for 99.99
select ta.*,round(ta.cpu_time/tb.total_cpu * 100,1) cpu_usage from
(select s.username,s.program,s.event,s.sql_id,sum(trunc(m.CPU)) CPU_TIME,count(*) sum
        --,sum(m.PHYSICAL_READS) P_READ,sum(LOGICAL_READS) L_READ,
  from v$sessmetric m ,v$session s
 where ( m.PHYSICAL_READS >100
       or m.CPU>100
       or m.LOGICAL_READS >100)
       and m.SESSION_ID = s.SID
       and m.SESSION_SERIAL_NUM = s.SERIAL#
       and s.status = 'ACTIVE'
       and username is not null
 group by s.username,s.program,s.event,s.sql_id
 order by 5 desc) ta,(select sum(cpu) total_cpu from v$sessmetric) tb
where rownum < 11;

查看语句

select sql_text from gv$sql where sql_id='829dqppqgyqts';

查看 latch free 的 P2

select sid,SEQ#,P1,p2 from v$session_wait where event  like 'latch free';

P2 带入视图查看 name

select * from v$latchname where latch#=186;

V$latchname 查出来是 simulator hash latch （方法不唯一）

匹配 mos

2 、问题二（时候查看dba历史视图（dba_hist_active_sess_history）发现与卡顿时间（gv$active_session_history）的event不同）

概念介绍

1.      mmnl 进程从 gv$session 视图（从 X$KSUSE 基表获取）采集信息到 ash buffers 中，并且被获取到 X$ASH 基表中，默认 1 秒一次（ _ash_sampling_interval ，单位毫秒）。

2.      gv$active_session_history 视图从 X$ASH 基表读取数据，由 mmon 进程将 gv$active_session_history 视图信息持久化到 wrh$_active_session_history 基表中。

3.      dba_hist_active_sess_history 视图从 wrh$_active_session_history 基表读取数据，默认 10 秒一次（ _ash_disk_filter_ratio ，秒）。

4.      awr 报告数据从 dba_hist_active_sess_history 视图获取。

数据库mmon 进程trace 文件频繁报错：

报错一：

*** 2023-11-18 02:28:40.689

minact-scn master-status: grec-scn:0x0557.c26dea79 gmin-scn:0x0557.c1490c56 gcalc-scn:0x0557.c26a0542

*** 2023-11-18 02:33:43.871

minact-scn master-status: grec-scn:0x0557.c2acb330 gmin-scn:0x0557.c1490c56 gcalc-scn:0x0557.c2a8668b

minact-scn master-status: grec-scn:0x0557.c2b51c68 gmin-scn:0x0557.c1490c56 gcalc-scn:0x0557.c2b3a791

*** 2023-11-18 02:43:47.369

minact-scn master-status: grec-scn:0x0557.c2baf755 gmin-scn:0x0557.c1490c56 gcalc-scn:0x0557.c2bafeb4

解决办法：

根据在MOS上面匹配到的内容来看是因为MINACT-SCN MASTER-STATUS信息写到MMON的TRACE文件的BUG引起的，BUG号11891463，解决办法如下：

1.      将隐含参数 "_enable_minscn_cr" 设置为 false ：

alter system set "_enable_minscn_cr"=false scope=spfile;

2.      重启数据库生效

shutdown immediate 

startup

3.      有时设置了 "_enable_minscn_cr" 参数就可以解决这个问题，有时却不能，如果没能解决，那就再设置 "_smu_debug_mode" 参数：

alter system set "_smu_debug_mode"=134217728;

影响：

设置了上述参数后该信息不会再生成，但是这会禁用 min active SCN optimization 功能， " min active scn " 功能在 11g 中被引入用来支持强化延迟块清除操作，禁用该功能不会对数据库有任何影响。

参考文档：

Minact-Scn Master-Status: Grec-Scn Messages In Trace File (Doc ID 1361567.1)

报错二：

*** 2023-11-18 04:07:45.434

Unable to schedule a MMON slave at: Auto DBFUS Main

  Slave action has been temporarily suspended

    - Slave action had prior policy violations.

  Unknown return code: 101

解决办法：

根据在MOS上面匹配到的内容来看是因为Oralce使用DBFUS的自动功能失败了，禁用这个功能就能避免MMON进程trace一直报错，解决办法如下：

1. 将隐含参数 "_swrf_mmon_dbfus" 设置为 false ：

alter system set "_swrf_mmon_dbfus"=false; scope=spfile;

影响：

SWRF 功能是用于将 awr 数据导出，导入到其他数据库中 , 这个功能基本不使用，可以关闭，无太大影响，无需重启生效；。

参考文档 ：

Enq: FU - Contention Wait MMON trace file shows repeated entries "auto-DBFUS slave" (Doc ID 2671019.1)

dba历史视图 图片摘自-取名浪费我半小时