oracle p000进程,基于oracle 10.2.0.1 rac学习lmon进程系列六

结论

1,经目前的测试，lmon仅在RAC节点关闭及重启，才会发挥其巨大作用

2,lmon进程如何工作，需要分析lmon的trc文件

3,lmon trc文件里面的内容非常多，也很复杂，要在另一文章中进行分析与测试

4,可以基于bdump进行基于时间排序，也就是说基于最新时间进行比对，就知道你一个测试操作，到底与哪些后台进程有关系了

进而可以把台后进程的含义及作用理解，也可以进一步整合这些后台进程

5，在测试时会产生很多意外的惊喜，一定要全面记录，进行分析

6, RAC节点启动时，LMON会把节点信息注册到NM,关于NM将在下文进行测试与学习

7,lmon的TRC文件也可以看到DRM及队列相关的操作，当然还有其它的内容，同上请在另一文进行测试与分析

8，引申一点，可以从LMON的TRC中发现，LMON是一个中转进程的角色，通过它把LMS及相关的其它进程联系起来，协作工作

当然这个还要进一步测试方可

9，目前暂未在正常RAC数据库运行期间发现LMON的作用

10，LMON只要异常中断，会导致当前节点重启，并记录TRC文件

引申问题

测试

---oracle version

SQL> select * from v$version where rownum=1;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi

---lmon含义

1，进程也叫全局队列服务监控进程即global enqueue service monitor

2,lmon监控RAC全局范围内的全局队列以及全局资源

2，并且负责全局队列的恢复操作

--基于上述不同含义进行测试

先分析

2,lmon监控RAC全局范围内的全局队列以及全局资料

从字面看与锁以及资料有关，哪么如果只是单节点的锁出现故障，lmon会如何处理呢？或者lmon出现故障会如何呢？

为了回答上述问题，先看看lmon进程正常产生的等待事件为rdbms ipc message

SQL> select sid,event,p1text,p2text,p3text from v$session where paddr='0000000083A57EB8';

SID EVENT                                                            P1TEXT               P2TEXT               P3TEXT

---------- ---------------------------------------------------------------- -------------------- -------------------- --------------------

167 rdbms ipc message                                                timeout

SQL> select sid,event,p1,p2,p3 from v$session where paddr='0000000083A57EB8';

SID EVENT                                                                    P1         P2         P3

---------- ---------------------------------------------------------------- ---------- ---------- ----------

167 rdbms ipc message                                                        10          0          0

---先oradebug lmon，会看如何,可见已经过了20分，仍然没有任何报错，表明如果数据库没有活动，我指的是DML或查询，不会对数据库造成什么影响

SQL> select pid,spid,program from v$process where lower(program) like '%lmon%';

PID SPID         PROGRAM

---------- ------------ ------------------------------------------------

5 4880         oracle@jingfa1 (LMON)

SQL> oradebug setospid  4880

Oracle pid: 5, Unix process pid: 4880, image: oracle@jingfa1 (LMON)

SQL> oradebug suspend

Statement processed.

告警日志

Mon Nov 16 23:50:16 2015

Unix process pid: 4880, image: oracle@jingfa1 (LMON) flash frozen

SQL> host date

Tue Nov 17 00:05:09 CST 2015

--再看下oradebug lmon,仅运行单节点查询，会如何,经测和上述结果相，可见仅运行查询，LMON故障，不会对数据库造成什么影响

Tue Nov 17 00:08:10 2015

Unix process pid: 4880, image: oracle@jingfa1 (LMON) flash frozen

--再看下oradebug lmon,仅运行单节点dml，会如何,可见不会对数据库造成什么影响(再往下测试，会略去无关的内容，仅列举结论)

Tue Nov 17 00:11:43 2015

Unix process pid: 4880, image: oracle@jingfa1 (LMON) flash frozen

SQL> update t_lock set a=22 where a=1;

1 row updated.

SQL> host date

Tue Nov 17 00:18:33 CST 2015

--再看下oradebug lmon,节点1运行DML，节点2运行查询，会如何，可见不会对数据库造成什么影响

---node 1

SQL> update t_lock set a=22 where a=1;

1 row updated.

---node2

A          B

---------- ----------

2          2

中间略

9          9

10         10

14 rows selected.

---继续看下oradebug lmon,节点1及节点2皆运行dml,但不是基于相同的记录，会如何,可见不会对数据库造成什么影响

--node1

SQL> update t_lock set a=22 where a=1;

1 row updated.

--node2

SQL> update t_lock set a=33 where a=3;

3 rows updated.

---继续看，2个节点基于相同的记录进行DML，会如何，可见不会对数据库造成什么影响

---node1

SQL> update t_lock set a=22 where a=1;

1 row updated.

---node2