加入收藏 | 设为首页 | 会员中心 | 我要投稿 河北网 (https://www.hebeiwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

发布时间:2019-09-10 04:26:29 所属栏目:编程 来源:波波说运维
导读:本日首要从一个案例来先容一下log file sync这个守候变乱及常用的一些办理步伐,下面先看下妨碍时刻段的守候变乱。 1. 查察卡即刻间段的守候变乱及会话 查察妨碍时刻段守候变乱、题目sql id及会话会见次数 selecttrunc(sample_time,'mi')tm,sql_id,nvl(eve
副问题[/!--empirenews.page--]

本日首要从一个案例来先容一下log file sync这个守候变乱及常用的一些办理步伐,下面先看下妨碍时刻段的守候变乱。

1. 查察卡即刻间段的守候变乱及会话

查察妨碍时刻段守候变乱、题目sql id及会话会见次数

  1. select trunc(sample_time, 'mi') tm, sql_id, nvl(event,'CPU'),count(distinct session_id) cnt 
  2.  from dba_hist_active_sess_history 
  3.  where sample_time between to_date('2019-09-03 9:30:00') and 
  4.  to_date('2019-09-03 11:00:00') 
  5.  group by trunc(sample_time, 'mi'), sql_id,nvl(event,'CPU') 
  6.  order by cnt desc; 

查察该sql相干的守候变乱及对应的会话会见次数

  1. select sql_id, nvl(event, 'CPU'), count(distinct session_id) sz 
  2.  from dba_hist_active_sess_history a, dba_hist_snapshot b 
  3.  where sample_time between to_date('2019-09-03 09:30:00') and 
  4.  to_date('2019-09-03 11:00:00') 
  5.  and sql_id = '0spj1q9t1yh2d' 
  6.  and a.snap_id = b.snap_id 
  7.  and a.instance_number = b.instance_number 
  8.  group by sql_id, nvl(event, 'CPU') 
  9.  order by sz desc; 

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

很明明看到都是log file sync守候变乱很明明。那什么是log file sync呢?

2. log file sync -- 日记文件同步

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

在一个提交(commit)异常频仍的数据库中,一样平常会呈现log file sync守候变乱,当这个守候变乱呈此刻top5中,这个时侯我们必要针对log file sync守候变乱举办优化,必然要尽快说明并办理题目,不然当log file sync守候时刻从几毫秒直接到20几毫秒也许导致体系机能急剧降落,乃至会导致短暂的挂起。

当一个用户提交或回滚数据时, LGWR 将会话期的重做由 Log Buffer 写入到重做日记中,LGWR 完成使命往后会关照用户历程。 日记文件同步守候( Log File Sync) 就是指历程守候LGWR 写完成这个进程, 对付回滚操纵,该变乱记录从用户发出 rollback 呼吁到回滚完成的时刻。假如该守候过多,也许声名 LGWR 的写出服从低下,可能体系提交过于频仍。 针对该题目,可以存眷 log file parallel write 守候变乱,可能通过 user commits,user rollback 等统计信息调查提交或回滚次数。

总之,log file sync的来源一样平常是频仍commit/rollback或磁盘I/O有题目,大量物理读写争用。

可以通过如下公式计较均匀 Redo 写巨细:

  1. avg.redo write size = (Redo block written/redo writes)*512 bytes 

假如体系发生 Redo 许多,而每次写的较少,一样平常声名 LGWR 被过于频仍地激活了。 也许导致过多的 Redo 相干 Latch 的竞争, 并且 Oracle 也许无法有用地行使 piggyback 的成果。从一个AWR陈诉中提取一些数据来研究一下这个题目。

log file sync守候变乱的优化方案:

  • 优化了redo日记的I/O机能,只管行使快速磁盘,不要把redo log file存放在raid 5的磁盘上;
  • 加大日记缓冲区(log buffer);
  • 行使批量提交,镌汰提交的次数;
  • 部门常常提交的事宜配置为异步提交;
  • 恰当行使NOLOGGING/UNRECOVERABLE等选项;
  • 回收专用收集,正确配置收集UDP buffer参数;
  • 安装最新版本数据库停止bug

3. awr陈诉--rman备份

网络一下awr陈诉来说明,网络进程这里就不做先容了。

(1) 陈诉如下:

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

这里可以留意到有一个非常的守候变乱--RMAN backup & recovery I/O,应该是rman恰亏得做备份导致的磁盘IO忙碌

(2) 调查RMAN日记

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

很明明是从破晓5点开始备份,一向备份到靠近10点导致,这里也耗损了一部门的磁盘IO

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

(3) 调解备份时刻

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

下面回到log file sync的说明上。

4. awr陈诉--log file sync

记一次出产数据库log file sync 守候变乱非常及处理赏罚进程

(编辑:河北网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读