oracle rac的lmd进程怎么理解

56次阅读
没有评论

共计 6136 个字符,预计需要花费 16 分钟才能阅读完成。

这篇文章主要介绍“oracle rac 的 lmd 进程怎么理解”,在日常操作中,相信很多人在 oracle rac 的 lmd 进程怎么理解问题上存在疑惑,丸趣 TV 小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”oracle rac 的 lmd 进程怎么理解”的疑惑有所帮助!接下来,请跟着丸趣 TV 小编一起来学习吧!

结论

1, 测试环境为 oracle 10.2.0.1 rac
2,lmd 进程如果异常中断,会导致所属 RAC 实例重启,并且在关库前会生成一个 SYSTEMSTATE DUMP 文件
3,lmon 进程是监控 lmd 进程,即 lmd 进程如果死掉,会由 lmon 进程重启它
4,lmd 进程负责全局队列服务,即 GES, 说白了,就是管理跨 RAC 多实例的资源请求,由此可见 LMD 进程的重要性,如果 LMD 出现故障,数据库 DML 操作会 HANG 住
    进而会引发 RAC 节点间的 IPC 通讯延时
5,IPC 通讯延时会产生对应的 LMD 的 TRACE FILE  

测试

–lmd 含义
lmd 进程是负责全局队列服务的进程,即 GES;
它是负责每个 RAC 实例来自远端 RAC 节点的资源请求;并且它是一个 DAEMON 进程,也就是说会由一个监控进程保护它,如果它不存在,由监控进程重启它

– 可见 lmd 进程如果异常中断,会直接导致 RAC 节点强制关闭,并且在关闭实例前生成一个 systemstate dump,以供分析
[oracle@jingfa1 ~]$ ps -ef|grep lmd
oracle    4774     1  0 Nov09 ?        00:00:31 asm_lmd0_+ASM1
oracle   11220     1  0 02:13 ?        00:00:15 ora_lmd0_jingfa1
oracle   30706 30376  0 05:19 pts/3    00:00:00 grep lmd
[oracle@jingfa1 ~]$ kill -9 11220

Tue Nov 10 05:20:03 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_pmon_11212.trc:
ORA-00482: LMD* process terminated with error
Tue Nov 10 05:20:03 2015
PMON: terminating instance due to error 482
Tue Nov 10 05:20:03 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_lms0_11222.trc:
ORA-00482: LMD* process terminated with error
Tue Nov 10 05:20:03 2015
System state dump is made for local instance
System State dumped to trace file /u01/app/oracle/admin/jingfa/bdump/jingfa1_diag_11214.trc
Tue Nov 10 05:20:03 2015
Trace dumping is performing id=[cdmp_20151110052003]
Tue Nov 10 05:20:08 2015
Instance terminated by PMON, pid = 11212
– 紧接实例又会自动重启
Tue Nov 10 05:21:05 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0

可见 lmd 进程又会自动重启
[oracle@jingfa1 ~]$ ps -ef|grep lmd
oracle    3474 30376  0 05:23 pts/3    00:00:00 grep lmd
oracle    4774     1  0 Nov09 ?        00:00:31 asm_lmd0_+ASM1
oracle   32703     1  0 05:21 ?        00:00:00 ora_lmd0_jingfa1

上述说 lmd 进程的健康是由其监控进程负责的,经查官方手册是 lmon 进程,LMON 进程负责每个 RAC 实例跨实例或者叫全局队列及资源的管理,以及全局队列锁的恢复操作

[oracle@jingfa1 bdump]$ ps -ef|grep lmon
oracle    4772     1  0 Nov09 ?        00:00:29 asm_lmon_+ASM1
oracle   19857 30376  0 05:34 pts/3    00:00:00 grep lmon
oracle   32701     1  0 05:21 ?        00:00:02 ora_lmon_jingfa1
[oracle@jingfa1 bdump]$ kill -9 32701
可见如果异常中断 LMON,其所属的 LMD 进程也会强制关闭
[oracle@jingfa1 bdump]$ ps -ef|grep lmd
oracle    4774     1  0 Nov09 ?        00:00:32 asm_lmd0_+ASM1
oracle   21171 30376  0 05:34 pts/3    00:00:00 grep lmd

可见只要异常中断 lmon 进程,会强制重启数据库实例
Tue Nov 10 05:34:18 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_pmon_32695.trc:
ORA-00481: LMON process terminated with error
Tue Nov 10 05:34:18 2015
PMON: terminating instance due to error 481
Tue Nov 10 05:34:18 2015
System state dump is made for local instance
System State dumped to trace file /u01/app/oracle/admin/jingfa/bdump/jingfa1_diag_32697.trc
Tue Nov 10 05:34:18 2015
Trace dumping is performing id=[cdmp_20151110053418]
Tue Nov 10 05:34:23 2015
Instance terminated by PMON, pid = 32695
Tue Nov 10 05:35:19 2015
Starting ORACLE instance (normal)

可见 lmon 及 lmd 会自动重启
[oracle@jingfa1 bdump]$ ps -ef|grep lmon
oracle    4772     1  0 Nov09 ?        00:00:30 asm_lmon_+ASM1
oracle   21820     1  0 05:35 ?        00:00:01 ora_lmon_jingfa1
oracle   27926 30376  0 05:39 pts/3    00:00:00 grep lmon
[oracle@jingfa1 bdump]$ ps -ef|grep lmd
oracle    4774     1  0 Nov09 ?        00:00:33 asm_lmd0_+ASM1
oracle   21822     1  0 05:35 ?        00:00:00 ora_lmd0_jingfa1
oracle   28028 30376  0 05:39 pts/3    00:00:00 grep lmd

引申下,也就是说肯定操作系统层面会有某种机制,确保 lmon 及 lmd 进程异常中断后,会重启它们,哪这种机制到底是什么呢?
经分析操作系统层面的各个进程,主要是 /etc/init.d 下,对比后发现 lmon 及其所属 lmd 是隶属于 ORACLE 层面,而非集群层面,没有对应的进程控制它们,

我们换个思路分析,与 lmd 进程相关的参数有哪些,其含义是什么?

NAME_1                                             VALUE_1                                            DESC1
————————————————– ————————————————– ————————————————–
_lm_lmd_waittime                                   8                                                  default wait time for lmd in centiseconds

—node1
SQL select addr,program,username,pid,spid from v$process where username= oracle and spid=21822;

ADDR             PROGRAM                                          USERNAME               PID SPID
—————- ———————————————— ————— ———- ————
0000000083A585C8 oracle@jingfa1 (LMD0)                            oracle                   6 21822

–node2
SQL select addr,program,username,pid,spid from v$process where username= oracle and spid=668;

ADDR             PROGRAM                                          USERNAME               PID SPID
—————- ———————————————— ————— ———- ————
0000000083A585C8 oracle@jingfa2 (LMD0)                            oracle                   6 668

–node2
SQL conn tbs_zxy/system
Connected.
SQL update t_lock set a=11 where a=1;

1 row updated.

–node1
SQL update t_lock set a=1111 where a=1;
–hang 住
可见上述参数并不直接与锁的检测有关哟,但是 lmd 是和全局锁有关的

换个思路,如果 oradebug 模拟暂停 lmd, 再产生全局锁会如何呢

—node1
暂停 lmd
SQL oradebug setospid 21822
Oracle pid: 6, Unix process pid: 21822, image: oracle@jingfa1 (LMD0)
SQL oradebug suspend
Statement processed.

Tue Nov 10 06:03:44 2015
Unix process pid: 21822, image: oracle@jingfa1 (LMD0) flash frozen

—node2
暂停 lmd
SQL oradebug setospid 668
Oracle pid: 6, Unix process pid: 668, image: oracle@jingfa2 (LMD0)
SQL oradebug suspend
Statement processed.

Tue Nov 10 06:06:08 2015
Unix process pid: 668, image: oracle@jingfa2 (LMD0) flash frozen

—node2
SQL update t_lock set a=11 where a=1;

1 row updated.

–node1
SQL update t_lock set a=1111 where a=1;
–hang 住

现在开始观察节点 1 及节点 2 的告警日志

–node2
Tue Nov 10 06:09:42 2015
IPC Send timeout detected.Sender: ospid 682  – 可见发送进程是 SMON 进程
Receiver: inst 1 binc 432326879 ospid 21822  – 可见接受者是 NODE1 的 LMD 进程
Tue Nov 10 06:09:45 2015
IPC Send timeout to 0.0 inc 20 for msg type 12 from opid 12 – 同上,接受者也是 SMON 进程
Tue Nov 10 06:09:45 2015
Communications reconfiguration: instance_number 1
Tue Nov 10 06:09:45 2015
IPC Send timeout detected.Sender: ospid 696  – 可见是 MMON 进程为发送进程
Receiver: inst 1 binc 432326879 ospid 21822   – 可见接受进程是节点的 lmd 进程
Tue Nov 10 06:09:48 2015
IPC Send timeout to 0.0 inc 20 for msg type 12 from opid 15  — 同上,接受者为 mmon 发送进程

–node1
Tue Nov 10 06:09:23 2015
IPC Send timeout detected. Receiver ospid 21822  – 可见接受为 LMD 进程
Tue Nov 10 06:09:23 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_lmd0_21822.trc: – 产生一个 LMD 的 TRACE 文件
IPC Send timeout detected. Receiver ospid 21822 – 同上
Tue Nov 10 06:09:27 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_lmd0_21822.trc:  

由上可见 lmd 确实与全局锁获取相关,如果 LMD 进程出现故障,会导致 RAC2 个节点通讯出现问题

[oracle@jingfa2 bdump]$ ps -ef|grep 682
oracle     682     1  0 02:14 ?        00:00:01 ora_smon_jingfa2
oracle    7157 13004  0 06:15 pts/1    00:00:00 grep 682

SQL select spid,pid,program from v$process where spid=696;

SPID                PID PROGRAM
———— ———- ————————————————
696                  15 oracle@jingfa2 (MMON)

到此,关于“oracle rac 的 lmd 进程怎么理解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注丸趣 TV 网站,丸趣 TV 小编会继续努力为大家带来更多实用的文章!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-15发表,共计6136字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)