enq: CF - contention 等待事件

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 背景说明:用户反馈数据库运行很慢,但是等查看的时候又恢复了正常,果断的查看了过去一段时间的AWR报告; AWR报告信息如下:  从db time/Elapsed显示数据库的压力并不是很大。

背景说明:用户反馈数据库运行很慢,但是等查看的时候又恢复了正常,果断的查看了过去一段时间的AWR报告;

AWR报告信息如下:

 

从db time/Elapsed显示数据库的压力并不是很大。

 

 

每秒钟产生的redo log 6M,每小时21G,数据库的IO写压力很大。

 

 

top5等待事件:enq:CF-contention 该等待事件不是空闲等待事件;

 

二、Metalink对该等待事件的分析

这问题一直没有遇到过,只能求助于metalink,详细的说明如下:

1、出现问题的版本

ORACLE DATABASE - ENTERPRISE EDITION - VERSION 9.2.0.1 TO 11.2.0.3 [RELEASE 9.2 TO 11.2](当前数据库的版本为11.2.0.3)

 

2、症状

在awr等待报告中的top5等待事件或出现v$session_wait的等待事件;

 

3、原因

任何需要读取控制文件的动作期间都会产生CF队列,CF锁用于controlfile序列操作和共享部分controlfile读和写。通常CF锁是分配给一个非常简短的时间和时使用:

  • 发生检查点
  • 日志文件的切换
  • 归档online redolog
  • 运行崩溃后的恢复
  • 热备的开始和结束
  • DML通过nologging选项执行对象时

 

4、解决问题

找出当前持有CF锁的对象

select l.sid, p.program, p.pid, p.spid, s.username, s.terminal, s.module, s.action, s.event, s.wait_time, s.seconds_in_wait, s.statefrom v$lock l, v$session s, v$process pwhere l.sid = s.sidand s.paddr = p.addrand l.type='CF'and l.lmode >= 5;

 

查找等待CF锁的对象

select l.sid, p.program, p.pid, p.spid, s.username, s.terminal, s.module, s.action, s.event, s.wait_time, s.seconds_in_wait, s.statefrom v$lock l, v$session s, v$process pwhere l.sid = s.sidand s.paddr = p.addrand l.type='CF'and l.request >= 5

 

METALINK如下:

It is advisable to run the above queries a few times in a row...

   

1. If you see the holder is:

   

background process, typically LGWR, CKPT or ARCn

the holder is holding the enqueue for a longer period of time

   

Check if the redologs are sized adequately. Typically you want to drive at a log switch every 30 minutes. Also verify checkpointing parameters such as fast_start_mttr_target

   

   

2. If you see the holder is:

   

a user session (so no background process)

the holder is constantly changing

the wait event of the holder is 'control file parallel write'

Then it is most likely that the contention for the CF enqueue is caused by DML on a NOLOGGING object.

   

When performing DML operations using either NOLOGGING or UNRECOVERABLE option, then oracle records the unrecoverable SCN in the controlfiles. Typically you will see an increase in waits appearing for 'control file parallel write' as well however the session is not blocked for this wait event but rather the session performing the controlfile write will be holding the CF enqueue and the other sessions performing the unrecoverable (nologging) operation will be waiting to get a CF enqueue to update the controlfile with the unrecoverable SCN.

   

So if you have an object with the NOLOGGING option, it is normal to see CF enqueue contention...

   

The following operations can make use of no-logging mode:

   

direct load (SQL*Loader)

direct-load INSERT

CREATE TABLE ... AS SELECT

CREATE INDEX

ALTER TABLE ... MOVE PARTITION

ALTER TABLE ... SPLIT PARTITION

ALTER INDEX ... SPLIT PARTITION

ALTER INDEX ... REBUILD

ALTER INDEX ... REBUILD PARTITION

INSERT, UPDATE, and DELETE on LOBs in NOCACHE NOLOGGING mode stored out of line

 

3. Check if the archive destination (log_archive_dest_n) are accessible, you may need to involve System/Storage admins.

   

If you are using NFS filesystem for the archive destinations then make sure there is no issue with nfs as this can lead to log switch hanging and that leads to CF enqueue as the lock holder will be either LGWR or ARCn processes

 

理解如下:

  • 当holder的对象是后台进程:LGWR、CKPT、ARCn

解决方法:redolog的大小和切换频率,建议每次日志切换的时间间隔着30分钟左右。

  • 当holder的对象是用户session、并经常变化、等待事件"control file parallel write"

解决方法:该等待是正常的数据库等待;

  • 其他:检查归档的路径,由于系统或存储的问题导致的该等待事件;

 

五、问题的总结

本案例的aw报告中显示数据库每小时产生的归档日志达22G,数据库的online redolog的大小为1G/个,计算下来每个小时需要进行20次的日志切换,平均3分钟执行次。与建议的30分钟一次相差很多。

经过与业务沟通发现当前数据库正在进行数据的抽取工作,导致该等待事件的发生。

 

最后的解决方法:建议在工作时间避免进行数据的抽取保证在工作期间系统能够正常运行;

                            可以适当增加online redolog的大小到5G,减低日志的切换频率;

DBA有时候就是有这个好处,当所有人都不知道问题的时候,问题的大小你都可以随便描述(前提是建立在事实的依据下),如果平时树立足够的威信的话,那么很容易让其他的人员配合你的工作,这个时候成就感是很强的。

 

附:日志信息和产生情况

 

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++本文作者:JOHN

ORACLE技术博客:ORACLE 猎人笔记               数据库技术群:367875324 (请备注ORACLE管理 )  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
监控 Oracle 安全
Oracle数据库用户频繁被锁问题原因排查及解决
由于应用环境下Oracle用户总是频繁被锁,经常不能执行数据库事务操作,严重影响了系统运行效率。通过问题原因分析及排查,发现了原因,在此记录一下。
5040 0
Oracle数据库用户频繁被锁问题原因排查及解决
|
9月前
|
Oracle 关系型数据库 Linux
linux8安装oracle 11g遇到的问题记录
Oracle 11g在Linux 8上安装时会遇到link编译环节的问题。官方建议忽略安装中的链接错误,安装完成后应用DBPSU 11.2.0.4.240716补丁及一次性补丁33991024,再重新编译二进制文件,并配置监听器和数据库。但因11g已退出服务期,这些补丁需付费获取。网上信息显示22年1月的PSU补丁也可解决问题,找到该补丁后按常规方式打补丁即可。如有需求或疑问可咨询我。
357 20
|
关系型数据库 数据库 PostgreSQL
postgresql|【基于pg_basebackup命令的归档备份和恢复---热备冷恢复方式】
postgresql|【基于pg_basebackup命令的归档备份和恢复---热备冷恢复方式】
690 0
|
数据采集 数据可视化 数据挖掘
【优秀python案例】基于python爬虫的深圳房价数据分析与可视化实现
本文通过Python爬虫技术从链家网站爬取深圳二手房房价数据,并进行数据清洗、分析和可视化,提供了房价走势、区域房价比较及房屋特征等信息,旨在帮助购房者更清晰地了解市场并做出明智决策。
597 2
分布式系列教程(25) -解决Zookeeper启动失败的问题
分布式系列教程(25) -解决Zookeeper启动失败的问题
656 0
|
SQL Java Linux
Linux系统cpu飙升到100%排查方案
Linux系统cpu飙升到100%排查方案
791 0
【已解决】nested exception is java.sql.SQLSyntaxErrorException: ORA-01722: invalid number
【已解决】nested exception is java.sql.SQLSyntaxErrorException: ORA-01722: invalid number
172 0
|
SQL Oracle 关系型数据库
【已解决】ORA-01722: invalid number
【已解决】ORA-01722: invalid number
657 0
ora-04098 触发器无效且未通过重新验证
ora-04098 触发器无效且未通过重新验证
488 0
|
SQL 关系型数据库 数据库