背景
客户环境使用EMCC13.5 监控EXADATA数据库 并结合钉钉将数据库告警实时打印到钉钉DB群
前段时间突然收到一个很离谱的告警
Alert
HostName= xxxxx
TargetType= Cluster Database
TargetName= xxxxx
Message= 6,470,713 seconds in DB Time is spent waiting for TX lock.
EventTime= Mar 16, 2024 9:00:03 AM CST @所有人6,470,713 seconds的TX锁?什么情况？两个月的TX锁？客户TB级别的数据库，出现这么久的TX锁难道没有一点影响？ 怀着疑惑连上了数据库去查此时后台的等待事件并没有发现任何锁，捞取了相关时间段的awr，ash等都没有看到TX类型的锁等待。此时判断是误报，
Alert
HostName= xxxx
TargetType= Cluster Database
TargetName= xxxx
Message= 736,546 seconds in DB Time is spent waiting for TM lock.
EventTime= Mar 17, 2024 12:41:20 PM CST @所有人一天后另一个DB又收到了一条类似的问题，但这次是TM 锁，持续时间一周左右。 登上DB查询后发现和之前的情况一样。此时已经可以确认两次都是误报，那这个误报是怎么产生的？
问题调查
年初客户的EXADATA环境进行了image的升级，升级后当前image版本为22.1.18.0.0，需要将之前使用的EMCC13.4升级到13.5才能完美监控EXADATA，这个动作也是近期完成的。难道是因为升级了EMCC导致的误报？
带着这个疑惑向oracle提了一个case去咨询这个问题，oracle要求提供告警信息截图
但是问题来了，按照这个指示我们一层层登入EMCC发现意外事件管理器并没有任何关于TX/TM锁的记录。于是将这个调查结果又回复给了case，并且这时候很巧又报了一次TX，lock，我顺便将这次告警的信息也一起上传给oracle
这次case提供了一条metric 去查询TX/TM锁
WITH Lock_types as
(select 'TX' as lock_type from dual
UNION
select 'TM' from dual
UNION
select 'UL' from dual)
,blocked_locks as
(select p2 id1,
p3 id2,
case when event like 'enq: TX%' then 'TX'
when event = 'enq: UL - contention' then 'UL'
when event = 'enq: TM - contention' then 'TM'
end lock_type,
count(*) num_blocked,
sum(last_call_et) dbtime_blocked
from gv$session
where (event like 'enq: TX%'
or event in ('enq: UL - contention','enq: TM - contention'))
and wait_time=0
group by p2,p3,
case when event like 'enq: TX%' then 'TX'
when event = 'enq: UL - contention' then 'UL'
when event = 'enq: TM - contention' then 'TM'
end)
SELECT
LT.lock_type
,NVL(MAX(BL.num_blocked),0) as max_blocked
,NVL(MAX(BL.dbtime_blocked),0) as max_dbtime_blocked
FROM
blocked_locks BL
,lock_types LT
WHERE
LT.lock_type = BL.lock_type(+)
GROUP BY
LT.lock_type;查询结果如下
调查结果
此时再将所有的信息提供给case，两小时左右，终于迎来了oracle的回复
根据回复来看EMCC13.5的收集确实存在着问题，我们根据oracle的意见先去agent查看这个文件
[oracle@xxxx ~]$
[oracle@xxxx ~]$
[oracle@xxxx ~]$ cd /EMCC/agent_13.5.0.0.0/plugins/oracle.sysman.db.agent.plugin_13.5.1.0.0/metadata
[oracle@xxxx metadata]$ ls
adr_info.xmlp gds_creds.xmlp inst_farsync_common.xmlp oracle_dbservice.xml
asmcreds.xmlp gds_gsm_common.xmlp inst_logfiles.xmlp oracle_dbsvc.xml
cloud_db_common_metrics.xmlp gds_gsm.xml inst_misc.xmlp oracle_dbsys.xml
cloud_db_creds.xmlp gds_pool_common.xmlp inst_ondemand.xmlp oracle_farsync.xml
cloud_db_inst_props.xmlp gds_pool.xml inst_perf.xmlp oracle_listener.xml
cloud_schema_storage_metrics.xmlp gds_shard_director.xml inst_properties.xmlp oracle_pdbexpress.xml
cluster.xml gds_sharded_database.xml oci_creds.xmlp oracle_pdb.xml
creds.xmlp gds_shardgroup.xml oldVersions order.xml
database.xmlp gds_shardspace.xml oracle_cloud_adw.xml osb_server.xml
db_farsync_common_dyn_props.xmlp hascluster.xmlp oracle_cloud_atp.xml osm_cluster.xml
db_farsync_common.xmlp has.xml oracle_cloud_dbcs.xml osm_common.xmlp
dyn_props.xmlp inst_adaptive.xmlp oracle_cloud_db_ha_backup_metrics.xmlp osm_instance.xml
emdb_ccc_oracle_metrics.xmlp instance.xmlp oracle_cloud_db_service.xml osm_ioserver.xml
esa_database_dyn_props.xmlp inst_checkers.xmlp oracle_cloud_infrastructure.xml osm_proxy.xml
esa_instance_dyn_props.xmlp inst_config.xmlp oracle_cloud_tenant.xml rac_database.xml
gds_cloud.xml inst_dynamic_props.xmlp oracle_cman.xml scn_info.xmlp
gds_common.xmlp inst_farsync_common_dyn_props.xmlp oracle_database.xml target_version.xmlp
[oracle@hzsmtx6dbadm01 metadata]$ vi database.xmlp编辑database.xmlp 找到last_call_et
解决方法
已经明确了问题接下来我们按照oracle的建议进行更改
[oracle@xxxx ~]$ cd /EMCC/agent_13.5.0.0.0/plugins/oracle.sysman.db.agent.plugin_13.5.1.0.0/metadata
[oracle@xxxx metadata]$ cp database.xmlp database_bak.xmlp
[oracle@xxxx metadata]$ vi database.xmlp
替换last_call_et 为seconds_in_wait
重启agent
[oracle@xxxx ~]$ cd /EMCC/agent_13.5.0.0.0/bin
[oracle@xxxx bin]$ ./emctl stop agent
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
Stopping agent ... stopped.
[oracle@xxxx bin]$ ./emctl start agent
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
Starting agent ....................................... started.
RAC每个节点 都需要替换和重启修改完成后观察2个月已不在产生误报
