这篇文章主要介绍“oracle rac的lmd进程怎么理解”,在日常操作中,相信很多人在oracle rac的lmd进程怎么理解问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”oracle 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
–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进程怎么理解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注百云网站,小编会继续努力为大家带来更多实用的文章!
本篇内容介绍了“Redis内存对像模型分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!Redis内存统计语句:info memory输出说明:used_mem…
免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。