其他分享
首页 > 其他分享> > 62

62

作者：互联网

博客园Logo
首页
新闻
博问
专区
闪存
班级

代码改变世界
搜索
注册
登录
满格
博客园 首页 新随笔 联系 管理 随笔 - 182 文章 - 0 评论 - 32
Oracle数据库由dataguard备库引起的log file sync等待

导读：

最近数据库经常出现会话阻塞的报警，过一会又会自动消失，昨天晚上恰好发生了一次，于是赶紧进行了查看，不看不知道，一看吓一跳，发现是由dataguard引起的log file sync等待。我们知道，通常log file sync等待都是由频繁写日志造成的，这次居然是由DG环境引起的。

（一）问题描述

数据库：Oracle 11.2.0.4，单机版，有Dataguard环境

操作系统：centos 7.4

通过zabbix监控到的会话阻塞信息如下图，这里是自定义的监控，解释如下：

用户usera,其session id为2663，session serial为27727，该会话未在执行SQL语句，但是却一直处于非空闲等待，等待的事件为log file sync，一共等待了548s

clipboard

（二）分析

查看报警期间的历史会话信息：

复制代码
select sample_time, session_id,session_serial#,session_type,user_id,sql_id,sql_plan_operation,event,
blocking_session,blocking_session_serial#,PROGRAM,MACHINE
from v$active_session_history a
where a.sample_time > to_date(‘2020-11-25 20:40:00’,‘yyyy-mm-dd hh24:mi:ss’)
and a.sample_time < to_date(‘2020-11-25 20:59:00’,‘yyyy-mm-dd hh24:mi:ss’)
and blocking_session is not null
order by a.sample_time;
复制代码
可以看到，会话1333，2191，2663均被会话1331阻塞了，等待事件是log file sync，它们在等待的会话为1311。

snipaste_2020-11-26_11-38-30

查询1331会话信息，发现是日志写进程LGWR，1311会话不再被其它会话阻塞，可以判定该会话为阻塞源头，1331会话的等待事件是LGWR-LNS wait on channel。

复制代码
select sample_time, session_id,session_serial#,session_type,user_id,sql_id,event,
blocking_session_status,blocking_session,PROGRAM,MACHINE
from v$active_session_history a
where a.sample_time > to_date(‘2020-11-25 20:40:00’,‘yyyy-mm-dd hh24:mi:ss’)
and a.sample_time < to_date(‘2020-11-25 20:59:00’,‘yyyy-mm-dd hh24:mi:ss’)
and a.session_id = 1331
order by a.sample_time;
复制代码
snipaste_2020-11-26_11-42-47

在本案例中，一共出现了2种类型的非空闲等待事件：

log file sync
LGWR-LNS wait on channel（阻塞源头）
什么是log file sync：当用户提交一个事务之后就开始等待log file sync，直到LGWR进程完成了对SCN的传播和对应重做日志的写入操作。所以log file sync的等待时间是由重做日志I/O时间和SCN传播时间两部分构成的，如果还使用了DataGuard，且日志传送时使用了同步+确认(SYNC+AFFRIM)选项时，那么LGWR还需在用户提交事务之后将重做日志信息传递到远程备库节点。总结一下，log file sync的计算公式如下：

用户进程log file sync等待时间 = LGWR执行重做日志I/O时间 + SCN传播时间 + LGWR传送重做日志到备库的时间。

在数据库实例中，log file sync的等待步骤如下：

clipboard

步骤①和②时所经历的时间就是log file sync所经历的时间。a1a4是LGWR传送重做日志到备库的过程，b1b4是LGWR传播SCN的过程，c1~c2是LGWR将重做日志写入到重做日志文件的过程。

a1~a4代表LGWR传送重做日志到DataGuard备库，过程如下：

a1：LGWR将事务对应的重做信息发送给本地节点的LNS(network server)进程

a2：LNS进程通过网络将重做信息发送给备库的RFS(remote file server)进程

a3：RFS进程将重做日志信息写入到备库的备用重做日志文件(Standby redo log)，返回消息给主库的LNS进程

a4：主库的LNS进程通知LGWR进程重做信息已经写入到备库的备用重做日志文件

b1~b4代表LGWR传播SCN，SCN是数据库内部的时钟，不重复，单项增长，SCN是针对数据库的，不是针对实例的，也就是说，对于RAC数据库，虽然有多个实例，这些实例会使用相同的SCN，但是每个实例都可以进行各自的任务，这就意味着实例之间需要传播SCN。对于分布式数据库（例如，使用了DB Link），也同样存在着同步SCN的概念。同步SCN的过程如下：

b1：LGWR进程将事务提交的SCN发送给本地的一个LMS进程

b2：本地节点的LMS进程将包含了SCN的消息发送给所有远程节点的LMS进程

b3：所有远程节点的LMS进程接受到了SCN消息并反馈给本地节点的LMS进程

b4：本地节点的LMS进程通知LGWR，所有远程节点都受到了事务的SCN

c1~c2代表LGWR执行重做日志写I/O。过程如下：

c1：LGWR进程将redo buffer cache中的日志写入到online redo log

c2：写完之后LGWR会收到通知已完成

在分析完log file sync等待事件的过程之后，基本上可以知道其形成原因了。然而，新的问题又来了，log file sync等待由3部分原因构成，在我的环境中，到底是LGWR执行重做日志比较慢，还是SCN传播时间存在异常等待，还是LGWR传送重做日志到备库存在性能瓶颈，这个时候我们就需要确认log file sync的并发现象了，我们继续分析。

（1）由LGWR执行重做日志I/O引起的log file sync

如果是由于LGWR将日志写入到online redo log引起的I/O问题，往往会伴随着log file parallel write等待事件出现，也就是说，如果log file sync和log file parallel write一起出现，那么往往是存放在线日志文件的磁盘I/O出问题了，有可能是磁盘吞吐量较差，也有可能是频繁的小I/O操作，磁盘I/O问题的主要解决方案如下：

优化了redo日志的I/O性能，尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上；
加大日志缓冲区(log buffer)；
使用批量提交，减少提交的次数；
clipboard

（2）由SCN传播引起的log file sync

由SCN传播引起的log file sync等待事件几乎没有见过，个人觉得SCN传播引起log file sync的概率较小，可以忽略

复制代码
SQL> SELECT NAME FROM v$event_name a WHERE a.name LIKE ‘%SCN%’ OR a.name LIKE ‘%LMS%’;

NAME

retry contact SCN lock master
ges master to get established for SCN op
复制代码

（3）由LGWR传送重做日志到备库引起的log file sync

需要特别注意的是，只有在LOG_ARCHIVE_DEST_n参数中使用了"SYNC，AFFIRM"属性时，log file sync等待事件才会与LGWR传送日志有关，如果使用了其它属性，不用考虑。

LNS进程DataGuard环境中主库用来传送日志到备库的进程，查看所有与之相关的等待事件。

复制代码
SQL> SELECT NAME FROM v$event_name a WHERE a.name LIKE ‘%LNS%’;

NAME

LNS wait on ATTACH
LNS wait on SENDREQ
LNS wait on DETACH
LNS wait on LGWR
LGWR wait on LNS
LNS ASYNC archive log
LNS ASYNC dest activation
LNS ASYNC end of log
LNS simulation latency wait
LGWR-LNS wait on channel
复制代码
回过头，再次查看我们的生产环境的问题，是log file sync伴随着LGWR-LNS wait on channel出现，再次确认数据库的参数信息，发现数据库运行在最大可用模式，备库采用了同步(sync)方式传送数据。

复制代码
SQL> select name,open_mode,database_role,protection_mode,protection_level from v$database;

NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL

ORCL2 READ WRITE PRIMARY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

SQL> show parameter log
NAME TYPE VALUE

log_archive_dest_2 string SERVICE=adg_orcl LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=adg_orcl
复制代码
再进一步分析"LGWR-LNS wait on channel"等待事件：

什么是LGWR-LNS wait on channel：这个等待事件监视LGWR或LNS进程等待在KSR通道上接收消息所花费的时间（This wait event monitors the amount of time spent by the log writer (LGWR) process or the network server processes waiting to receive messages on KSR channels. Data Guard Wait Events (Doc ID 233491.1) ）。

KSR通道的解释:https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/DBA_HIST_CHANNEL_WAITS.html#GUID-682C58F4-5787-4C8E-844C-9DFE04612BDD。

可以断定，数据库的异常等待是由于主库的LNS进程同步传送在线日志信息给DG环境引起的，且引起的瓶颈在备库端。想到我们的主库是高配的物理服务器，备库是低配的云主机(虚拟机)，出现这种问题也就不足为奇了。

（三）解决方案
使用异步方式传送日志信息，修改日志传送方式为异步(async)传送

复制代码
SQL> alter system set log_archive_dest_2= SERVICE=“adg_orcl” LGWR ASYNC VALID_FOR=(all_logfiles, primary_role) DB_UNIQUE_NAME=“adg_orcl” scope=both;

– 重新启用通道
SQL> alter system set log_archive_dest_state_2= defer;
SQL> alter system set log_archive_dest_state_2= enable;
复制代码

【完】

分类: ----170 trouble shooting, ----150 DataGuard
好文要顶 关注我 收藏该文
gegeman
关注 - 17
粉丝 - 41
+加关注
0 0
« 上一篇： 使用udev高效、动态的管理Linux设备文件
posted @ 2020-11-26 19:12 gegeman 阅读(49) 评论(0) 编辑 收藏
刷新评论刷新页面返回顶部
登录后才能发表评论，立即 登录 或 注册， 访问 网站首页
博客园派送云上免费午餐，AWS注册立享12个月免费套餐
【推荐】News: 大型组态、工控、仿真、CADGIS 50万行VC++源码免费下载
【推荐】阿里云钜惠返场，奖励继续赢5万现金，错过再等一年
【推荐】了不起的开发者，挡不住的华为，园子里的品牌专区
【推荐】未知数的距离，毫秒间的传递，声网与你实时互动
【福利】AWS携手博客园为开发者送免费套餐与抵扣券

相关博文：
· logfileswitch(checkpointincomplete)-容易被误诊的event
· Plugin从Sync改为Async后报Couldnotloadfileorassembly错误
· redolog
· Handlersyncbarrier
· AndroidStudiofastutil.jar一直在sync
» 更多推荐…
AWS免费套餐
最新 IT 新闻:
· 一文速览SpaceX首次载人商业发射 四名宇航员在太空生活半年
· 任正非：华为和荣耀不要藕断丝连 荣耀要做华为最强的竞争对手
· 复活有望！力帆重整计划草案获通过
· 中国降价海外疯涨！特斯拉全系欧洲多国大涨价 最高涨3.9万
· 悬崖边的傅盛，看猎豹坠落
» 更多新闻…
公告
昵称： gegeman
园龄： 5年1个月
粉丝： 41
关注： 17
+加关注
< 2020年11月 >
日 一 二 三 四 五 六
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 1 2 3 4 5
6 7 8 9 10 11 12
随笔分类 (219)
–100 Oracle(52)
----111 Oracle Lock(5)
----112 PL/SQL(2)
----113 SQL(3)
----120 Oracle RAC(8)
----130 Oracle安装与升级(5)
----140 Oracle数据库调优(14)
----150 DataGuard(10)
----160 Oracle备份与恢复(12)
----170 trouble shooting(4)
–200 MySQL(19)
----210 MySQL高可用(11)
----220 MySQL安装(3)
----240 MySQL性能优化(1)
----260 MySQL备份与恢复(5)
–300 SQL Server(4)
–400 MongoDB(18)
–500 ELK Stack(1)
–600 GoldenGate(2)
–700 主机、操作系统(2)
----710 Linux/UNIX(24)
----720 windows(1)
----730 虚拟机(3)
----740 zabbix(2)
----820 hadoop(1)
----830 java(2)
----840 php(5)
相册 (1)
picture(1)
最新评论

  1. Re:[Oracle]LogMiner工具小结
    啊沙发里看见啊， Oracle logminer的源代码实现，下载，日志格式详细解释，代码验证，都在tomcoding的com…
    –汤姆的代码
  2. Re:Oracle 11gR2 RAC + ASM + Grid安装
    ASM图文安装指南，ASM格式数据结构解密，条带化的秘密，ASM工具源代码，访问tomcoding。com
    –汤姆的代码
  3. Re:Oracle ASM
    ASM条带化的最明确讲解，ASM工具源代码下载，磁盘格式文档，百度tomcoding获取
    –汤姆的代码
    阅读排行榜
  4. oracle client安装与配置(34417)
  5. [Oracle]理解undo表空间(23319)
  6. Oracle 11gR2 RAC + ASM + Grid安装(22038)
  7. oracle执行计划（二）----如何查看执行计划(19132)
  8. [Oracle]Oracle数据库任何用户密码都能以sysdba角色登入(15537)
  9. 【oracle】Enterprise Manager 无法连接到数据库实例。下面列出了组件的状态—个人解决方案(10094)
  10. Oracle分区表删除分区引发错误ORA-01502: 索引或这类索引的分区处于不可用状态(8697)
  11. [Oracle]Audit（一）–认识Audit(6854)
  12. 【Linux资源管理】一款优秀的linux监控工具——nmon(6648)
  13. [Oracle]约束（constraint）(5626)
    评论排行榜
  14. keepalived+MySQL实现高可用(6)
  15. 【Linux资源管理】一款优秀的linux监控工具——nmon(5)
  16. Oracle 12cR1 RAC集群安装（一）–环境准备(2)
    Copyright © 2020 gegeman
    Powered by .NET 5.0.0 on Kubernetes

标签：log,LGWR,sync,----,62,file,日志
来源： https://blog.csdn.net/wubaoyu123/article/details/110220295