oracle lmd0,oracle 10.2.0.1 rac的lmd进程的含义之一

结论

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

6,关于与lmd相关的参数仍在研究中,暂无结论

测试

--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)

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9240380/viewspace-1827211/,如需转载,请注明出处,否则将追究法律责任。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值