- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章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 。
。
(二)分析 。
查看报警期间的历史会话信息:
1
2
3
4
5
6
7
|
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.
查询1331会话信息,发现是日志写进程LGWR,1311会话不再被其它会话阻塞,可以判定该会话为阻塞源头,1331会话的等待事件是LGWR-LNS wait on channel.
1
2
3
4
5
6
7
|
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;
|
在本案例中,一共出现了2种类型的非空闲等待事件:
什么是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的等待步骤如下:
步骤①和②时所经历的时间就是log file sync所经历的时间。a1~a4是LGWR传送重做日志到备库的过程,b1~b4是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问题的主要解决方案如下:
。
(2)由SCN传播引起的log file sync 。
由SCN传播引起的log file sync等待事件几乎没有见过,个人觉得SCN传播引起log file sync的概率较小,可以忽略 。
1
2
3
4
5
6
|
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环境中主库用来传送日志到备库的进程,查看所有与之相关的等待事件.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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)方式传送数据.
1
2
3
4
5
6
7
8
9
10
11
12
|
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)传送 。
1
2
3
4
5
|
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;
|
到此这篇关于Oracle数据库由dataguard备库引起的log file sync等待的文章就介绍到这了,更多相关Oracle dataguard备库引起的log file sync等待内容请搜索我以前的文章或继续浏览下面的相关文章希望大家以后多多支持我! 。
原文链接:https://www.cnblogs.com/lijiaman/p/14044031.html 。
最后此篇关于Oracle数据库由dataguard备库引起的log file sync等待问题的文章就讲到这里了,如果你想了解更多关于Oracle数据库由dataguard备库引起的log file sync等待问题的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我想知道是否可以访问放在 tomcat 的 conf 文件夹中的文件。通常我会在这个文件中放置多个 webapp 的配置,在 war 之外。 我想使用类路径独立于文件系统。 我过去使用过 lib 文件
我有一个 PowerShell 脚本,它获取文件列表并移动满足特定条件的文件。为什么即使对象为空,foreach 循环也会运行? 我假设如果 $i 不存在,它就不会运行。但是如果 $filePath
我已将 BasicAccountRule.drl 放置在我的 Web 应用程序中,位置为:C:/workspace/exim_design/src/main/resources/rules/drl/i
我使用 File.open('file.txt').class 和 File.open('file.txt').readlines.class 以及前者进行了检查一个返回 File,后者返回 Arra
我正在尝试使用 FileOutputStream 删除文件,在其中写入内容后。这是我用来编写的代码: private void writeContent(File file, String fileC
我正在尝试使用 flink 和 python 批处理 api 测试 Wordcount 经典示例。我的问题是,将数据源从 env.from_elements() 修改为 env.read_text()
我正在尝试制作一个可以同时处理多个不同文件的程序。我的想法是制作一个包含 20 个 FILE* 的数组,以便在我达到此限制时能够关闭其中一个并打开请求的新文件。 为此,我想到了一个函数,它选择一个选项
我有两个文件A和B文件A: 976464 792992 文件B TimeStamp,Record1,976464,8383,ABCD 我想搜索文件 A 和文件 B 中的每条记录并打印匹配的记录。打印的
我有一些保存在 map 中的属性文件。示例: Map map = new HashMap<>(); map.put("1", "One"); map.put("2", "Two"); map.put(
我正在尝试找出一个脚本文件,该文件接受一个包含文件列表的文件(每一行都是一个文件路径,即 path/to/file)并将它们合并到一个文件中。 例如: list.text -- path/to/fil
为了使用 File.CreateText() 和 File.AppendText() 你必须: 通过调用这些方法之一打开流 写消息 关闭流 处理流 为了使用 File.AppendAllText()
使用rsync时,如何在使用--files-from参数复制时重命名文件?我有大约190,000个文件,在从源复制到目标时,每个文件都需要重命名。我计划将文件列表放在一个文本文件中传递给--files
我在非服务器应用程序中使用 Spring(只需从 Eclipse 中某个类的 main() 编译并运行它)。 我的问题是作为 new FileSystemXmlApplicationContext 的
QNX (Neutrino 6.5.0) 使用 ksh 的开源实现作为其 shell 。许多提供的脚本,包括系统启动脚本,都使用诸如 if ! test /dev/slog -ef /dev/slog
当我尝试打开从我的应用程序下载的 xls 文件时,出现此错误: excel cannot open the file because the file format or file extension
有一些相关的概念,即文件指针、流和文件描述符。 我知道文件指针是指向数据类型 FILE 的指针(在例如 FILE.h 和 struct_FILE.h 中声明)。 我知道文件描述符是 int ,例如成员
好吧,这应该很容易... 我是groovy的新手,我希望实现以下逻辑: def testFiles = findAllTestFiles(); 到目前为止,我想出了下面的代码,该代码可以成功打印所有文
我理解为什么以下内容会截断文件的内容: Get-Content | Out-File 这是因为 Out-File 首先运行,它会在 Get-Content 有机会读取文件之前清空文件。 但是当我尝
您好,我正在尝试将文件位置表示为变量,因为最终脚本将在另一台机器上运行。这是我尝试过的代码,然后是我得到的错误。在我看来,python 是如何添加“\”的,这就是导致问题的原因。如果是这种情况,我如何
我有一个只包含一行的输入文件: $ cat input foo bar 我想在我的脚本中使用这一行,据我所知有 3 种方法: line=$(cat input) line=$( input"...,
我是一名优秀的程序员,十分优秀!