结论

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
SQL> update t_lock set a=111 where a=1;
hang住


不过在最后节点报错如下
Tue Nov 17 00:47:00 2015
PMON failed to delete process, see PMON trace file


好像发现21进程死了
[oracle@jingfa2 bdump]$ more jingfa2_pmon_27036.trc
/u01/app/oracle/admin/jingfa/bdump/jingfa2_pmon_27036.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production


found process 0x83a5fd38 pid=21 serial=28 ospid = 3187 dead
*** 2015-11-17 00:45:10.693
found process 0x83a5fd38 pid=21 serial=28 ospid = 3187 dead
*** 2015-11-17 00:45:10.695


*** 2015-11-17 00:47:50.688
found process 0x83a5fd38 pid=21 serial=28 ospid = 3187 dead
*** 2015-11-17 00:48:00.687
found process 0x83a5fd38 pid=21 serial=28 ospid = 3187 dead


SQL> select pid,spid,addr,background,program from v$process order by 4;


       PID SPID         ADDR             B PROGRAM
---------- ------------ ---------------- - ------------------------------------------------
         2 27036        0000000083A56700 1 oracle@jingfa2 (PMON)
        31 27947        0000000083A64C48 1 oracle@jingfa2 (q001)
        30 27945        0000000083A64460 1 oracle@jingfa2 (q000)
    相似内容略
        13 27060        0000000083A5BDF8 1 oracle@jingfa2 (RECO)
        14 27062        0000000083A5C5E0 1 oracle@jingfa2 (CJQ0)
        15 27064        0000000083A5CDC8 1 oracle@jingfa2 (MMON)


       PID SPID         ADDR             B PROGRAM
---------- ------------ ---------------- - ------------------------------------------------
        23 27349        0000000083A60D08   oracle@jingfa2 (TNS V1-V3)
        22 7042         0000000083A60520   oracle@jingfa2 (PZ99)
        21 3187         0000000083A5FD38   oracle@jingfa2 (PZ99) --21号进程
        27 27540        0000000083A62CA8   oracle@jingfa2 (TNS V1-V3)
         1              0000000083A55F18   PSEUDO
        18 13422        0000000083A5E580   oracle@jingfa2 (TNS V1-V3)
        24 27355        0000000083A614F0   oracle@jingfa2 (TNS V1-V3)
        32 19004        0000000083A65430   oracle@jingfa2 (TNS V1-V3)
        25 27376        0000000083A61CD8   oracle@jingfa2 (TNS V1-V3)


31 rows selected.


由上可知21号进程不是后台进程，正常会在V$SESSION会在对应会话记录才对，但没有，说明这个进程不正常了，所以在上述报错了
SQL> select sid,serial#,program,event from v$session where paddr='0000000083A5FD38';


no rows selected


SQL> 


但是过了一会，21号进程通过PMON已经清理成功了
Tue Nov 17 00:52:30 2015
PMON deletion of process succeeded


这下进程没有了吧，可见PMON清理时，是先清理会话资源，最后才清理进程资源
SQL>  select pid,spid,addr from v$process where pid=21;


no rows selected


---上面只是hang 单节点的lmon,现在2个节点的lmon全hang住




类似测试略，若2个节点全HANG LMON且同时更新同一个记录DML，仍不会影响数据库的进展，没有任何报错


可以用v$session_wait来分析等待某个等待事件已经消耗多久时间了，关注seconds_in_wait及state
SQL> select sid,event,p1,p2,p3,wait_time,seconds_in_wait,state from v$session_wait where sid=167;


       SID EVENT                                                                    P1         P2         P3  WAIT_TIME SECONDS_IN_WAIT STATE
---------- ---------------------------------------------------------------- ---------- ---------- ---------- ---------- --------------- -------------------
       167 rdbms ipc message                                                        10          0          0          0             192 WAITING


SQL> select sid,event,p1,p2,p3,wait_time,seconds_in_wait,state from v$session_wait where sid=167;


       SID EVENT                                                                    P1         P2         P3  WAIT_TIME SECONDS_IN_WAIT STATE
---------- ---------------------------------------------------------------- ---------- ---------- ---------- ---------- --------------- -------------------
       167 rdbms ipc message                                                        10          0          0          0             198 WAITING


SQL> 






---我们继续分析，如果在执行DML时，中断会话，看会如何




看到PMON在作事哟
[oracle@jingfa1 bdump]$ more jingfa1_pmon_4849.trc
/u01/app/oracle/admin/jingfa/bdump/jingfa1_pmon_4849.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      jingfa1
Release:        2.6.18-164.el5
Version:        #1 SMP Tue Aug 18 15:51:48 EDT 2009
Machine:        x86_64
Instance name: jingfa1
Redo thread mounted by this instance: 0 <none>
Oracle process number: 2
Unix process pid: 4849, image: oracle@jingfa1 (PMON)


kclmap: mapping region: 0x60400000 length: 595591168
*** 2015-11-17 01:32:39.176
*** SERVICE NAME:(SYS$BACKGROUND) 2015-11-17 01:32:39.176
*** SESSION ID:(170.1) 2015-11-17 01:32:39.176
kcllkopb: req=0 block=5/14000a6
kcllkopb: req=0 typ=cur wtyp=2hop tm=1950
[oracle@jingfa1 bdump]$ date
Tue Nov 17 01:33:58 CST 2015


从时间点来推算，可见后台进程pmon,lms,mmon,lck,smon,ckpt全作事了，引申下，可以基于时间点对比分析你的测试与哪些进程有关系，这也是一个分析思路
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:29 jingfa1_pz96_21216.trc
-rw-rw---- 1 oracle oinstall  795 Nov 17 01:32 jingfa1_pmon_4849.trc
-rw-rw---- 1 oracle oinstall 993K Nov 17 01:32 jingfa1_lms0_4884.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:33 jingfa1_pz98_27362.trc
-rw-rw---- 1 oracle oinstall 160K Nov 17 01:33 jingfa1_mmon_4902.trc
-rw-rw---- 1 oracle oinstall  56K Nov 17 01:33 jingfa1_lck0_4906.trc
-rw-rw---- 1 oracle oinstall 172K Nov 17 01:35 jingfa1_smon_4896.trc
-rw-rw---- 1 oracle oinstall 145K Nov 17 01:35 jingfa1_ckpt_4894.tr




---即然我们进行了各种测试，LMON全没有看到相应的期望结果，恢复LMON，执行事务，然后异常中断，分析LMON TRC及告警日志看会如何


--补充下，如果用ORADEBUG RESUME恢复LMON,在其TRC文件会显如下内容
Received ORADEBUG command 'resume' from process Unix process pid: 10124, image: 
SKGXPIWAIT: keepalive_reset elapsed 1793091 ts 24392338 last ping 22599247 check 600000
PING HISTORY for CONTEXT Time Stampe 0x1743292
MSGs     Time Stamp
---      ----------
3                0x158d64f
2                0xef49d9
2                0xf3ddbf
2                0xf87199
2                0xfd057f
2                0x101995b
2                0x1062d3f
2                0x10ac119
2                0x10f54fc
3                0x11e7294
0                0x12acf55
2                0x12f6335
3                0x135b6e9
0                0x1400592
2                0x1449973
2                0x1492d50
SKGXP_KEEPALIVE_RESET: alarm unblocked already
SKGXP_KEEPALIVE_RESET: restting shared signal for keep alive messages
SKGXP_KEEPALIVE_RESET: re-initing shared signal for keep alive messages
SKGXP_KEEPALIVE_RESET: setting alarm for keep alive messages


--好我们继糿分析,恢复LMON，在单节点执行DML，异常中断，会如何，发现报了SMON并行事务的错误，但在LMON 的TRC未发现任何信息，可见LMON不会参与异常事务的恢复


Tue Nov 17 01:43:48 2015
SMON: Parallel transaction recovery tried




[oracle@jingfa1 bdump]$ more jingfa1_smon_4896.trc
Dead transaction 0x0009.024.000000c8 recovered by 1 server(s)
*** 2015-11-17 01:43:48.380
SMON: Parallel transaction recovery tried
*** 2015-11-17 01:48:28.082
kclscrs: req=0 block=1/4075a7
kclwcrs: req=0 typ=cr wtyp=2hop tm=910
kclscrs: req=0 block=1/4073da
kclwcrs: req=0 typ=cr wtyp=2hop tm=916
kclscrs: req=0 block=1/4011dd
kclwcrs: req=0 typ=cr wtyp=2hop tm=510
kcllkopb: req=0 block=1/4075a7
kcllkopb: req=0 typ=cur wtyp=2hop tm=752
kcllkopb: req=0 block=1/4011d5
kcllkopb: req=0 typ=cur wtyp=2hop tm=567
kcllkopb: req=0 block=1/4011dd
kcllkopb: req=0 typ=cur wtyp=2hop tm=575


从如下可见,SMON进程确实有活动，不过本文我们不分析SMON进程
[oracle@jingfa1 bdump]$ ll -lrht|tail -20f
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:07 jingfa1_pz98_20358.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:09 jingfa1_pz97_23464.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:10 jingfa1_pz99_25467.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:27 jingfa1_pz98_18048.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:29 jingfa1_pz96_21216.trc
-rw-rw---- 1 oracle oinstall  795 Nov 17 01:32 jingfa1_pmon_4849.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:33 jingfa1_pz98_27362.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:39 jingfa1_pz98_4391.trc
-rw-rw---- 1 oracle oinstall 160K Nov 17 01:39 jingfa1_mmon_4902.trc
-rw-rw---- 1 oracle oinstall 567K Nov 17 01:40 jingfa1_lmon_4880.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:41 jingfa1_pz96_7540.trc
-rw-rw---- 1 oracle oinstall 172K Nov 17 01:41 jingfa1_ckpt_4894.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:41 jingfa1_pz98_8031.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:43 jingfa1_p000_11095.trc
-rw-r----- 1 oracle oinstall 305K Nov 17 01:43 alert_jingfa1.log
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:45 jingfa1_pz99_12891.trc
-rw-rw---- 1 oracle oinstall 995K Nov 17 01:47 jingfa1_lms0_4884.trc
-rw-rw---- 1 oracle oinstall 173K Nov 17 01:48 jingfa1_smon_4896.trc
-rw-rw---- 1 oracle oinstall  27K Nov 17 01:48 jingfa1_dbw0_4890.trc
-rw-rw---- 1 oracle oinstall  56K Nov 17 01:49 jingfa1_lck0_4906.trc




[oracle@jingfa1 bdump]$ tail -f jingfa1_lck0_4906.trc
KCL: A32: check for affinity dissolve
*** 2015-11-17 01:49:09.978
KCL: A37: no affinity initiate
object 573 [ 2 1 ] minimum 6000 limit 50
*** 2015-11-17 01:49:09.978
KCL: A37: no affinity initiate
object 576 [ 1 0 ] minimum 6000 limit 50
*** 2015-11-17 01:49:09.978
KCL: A37: no affinity initiate
object 577 [ 1 0 ] minimum 6000 limit 50








SQL> alter system kill session '131,398';


System altered.






可见异常中断会话，与LCK进程有关，不过本文不研究LCK
[oracle@jingfa1 bdump]$ tail -f jingfa1_lck0_4906.trc


*** 2015-11-17 01:54:10.047
KCL: A32: check for affinity dissolve


与上述对比下，可见只有SMON，LCK，PZ99有动作，可见SMON进程非常重要
[oracle@jingfa1 bdump]$ ll -lrht|tail -20f
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:27 jingfa1_pz98_18048.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:29 jingfa1_pz96_21216.trc
-rw-rw---- 1 oracle oinstall  795 Nov 17 01:32 jingfa1_pmon_4849.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:33 jingfa1_pz98_27362.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:39 jingfa1_pz98_4391.trc
-rw-rw---- 1 oracle oinstall 160K Nov 17 01:39 jingfa1_mmon_4902.trc
-rw-rw---- 1 oracle oinstall 567K Nov 17 01:40 jingfa1_lmon_4880.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:41 jingfa1_pz96_7540.trc
-rw-rw---- 1 oracle oinstall 172K Nov 17 01:41 jingfa1_ckpt_4894.trc
-rw-rw---- 1 oracle oinstall  575 Nov 17 01:41 jingfa1_pz98_8031.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:43 jingfa1_p000_11095.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:45 jingfa1_pz99_12891.trc
-rw-rw---- 1 oracle oinstall 995K Nov 17 01:47 jingfa1_lms0_4884.trc
-rw-rw---- 1 oracle oinstall  27K Nov 17 01:52 jingfa1_dbw0_4890.trc
-rw-rw---- 1 oracle oinstall  963 Nov 17 01:53 jingfa1_lgwr_4892.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:53 jingfa1_p000_26225.trc
-rw-rw---- 1 oracle oinstall 173K Nov 17 01:53 jingfa1_smon_4896.trc
-rw-r----- 1 oracle oinstall 305K Nov 17 01:53 alert_jingfa1.log
-rw-rw---- 1 oracle oinstall  57K Nov 17 01:54 jingfa1_lck0_4906.trc
-rw-rw---- 1 oracle oinstall  577 Nov 17 01:55 jingfa1_pz99_27871.trc


哪到底如何才能让LMON进程工作呢


由下可见,LMON进程非常重要
---node1 lmon,杀死lmon进程
SQL> host ps -ef|grep lmon
oracle    1252 10123  0 01:58 pts/3    00:00:00 /bin/bash -c ps -ef|grep lmon
oracle    1254  1252  0 01:58 pts/3    00:00:00 grep lmon
oracle    4180     1  0 Nov16 ?        00:00:31 asm_lmon_+ASM1
oracle    4880     1  0 Nov16 ?        00:00:31 ora_lmon_jingfa1


SQL> host kill -9 4880


---node1 马上实例强制重启
Tue Nov 17 01:59:09 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_pmon_4849.trc:
ORA-00481: LMON process terminated with error
Tue Nov 17 01:59:09 2015
PMON: terminating instance due to error 481
Tue Nov 17 01:59:09 2015
System state dump is made for local instance
System State dumped to trace file /u01/app/oracle/admin/jingfa/bdump/jingfa1_diag_4851.trc
Tue Nov 17 01:59:09 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_lms0_4884.trc:
ORA-00481: LMON process terminated with error
Tue Nov 17 01:59:09 2015
Errors in file /u01/app/oracle/admin/jingfa/bdump/jingfa1_lmd0_4882.trc:
ORA-00481: LMON process terminated with error
Tue Nov 17 01:59:09 2015
Trace dumping is performing id=[cdmp_20151117015909]
Tue Nov 17 01:59:14 2015
Instance terminated by PMON, pid = 4849
Tue Nov 17 01:59:43 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0


---同时node2,产生DUMP，并且重配动作开始
Tue Nov 17 01:59:09 2015
Trace dumping is performing id=[cdmp_20151117015909]
Tue Nov 17 01:59:16 2015
Reconfiguration started (old inc 12, new inc 14)
List of nodes:
 1
 Global Resource Directory frozen
 * dead instance detected - domain 0 invalid = TRUE 
 Communication channels reestablished
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
Tue Nov 17 01:59:16 2015
 LMS 0: 0 GCS shadows cancelled, 0 closed
 Set master node info 
 Submitted all remote-enqueue requests
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
 Post SMON to start 1st pass IR
Tue Nov 17 01:59:16 2015
 LMS 0: 5813 GCS shadows traversed, 0 replayed
Tue Nov 17 01:59:16 2015
 Submitted all GCS remote-cache requests
 Post SMON to start 1st pass IR
 内容略
 LMS 0: 5971 GCS shadows traversed, 3267 replayed
Tue Nov 17 01:59:46 2015
 Submitted all GCS remote-cache requests
 Fix write in gcs resources
Reconfiguration complete




意外发现LMON进程在实例重启会发挥其作用，从LMON TRC文件中发现，一会再测试这个




到底如何才能验证LMON进程的作用呢，直接中断其测试会话对应的操作系统进程，会如何？
经过测试，发现什么也有没作


继续在上述基础上，中断当前测试节点的实例，看会如何,发现在启动RAC 节点1时，LMON会把当前节点注册到NM中，关于NM还要继续研究下，到底是什么？
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.


Total System Global Area  599785472 bytes
Fixed Size                  2022632 bytes
Variable Size             314573592 bytes
Database Buffers          281018368 bytes
Redo Buffers                2170880 bytes
Database mounted.
Database opened.
Tue Nov 17 01:59:44 2015
lmon registered with NM - instance id 1 (internal mem no 0)


查看重启后最新的LMON的TRC文件，好像全是与DRM及队列有关




[oracle@jingfa1 bdump]$ tail -f jingfa1_lmon_17921.trc
kclclose: latch 7
kclclose: lock queue
kclclose: null queue
kclclose: rm queue
kclclose: drop queue
 sent syncr inc 20 lvl 71 to 0 (20,0/36/0) 
 sent synca inc 20 lvl 71 (20,0/36/0) 
 sent syncr inc 20 lvl 72 to 0 (20,0/38/0) 
 sent synca inc 20 lvl 72 (20,0/38/0) 
End DRM(8) 


基于上述，我有个思路，会不会只要是某个RAC节点重启或关闭，LMON进程就会作事呢，果不其然，与我想的一致，我关闭节点时，发现节点1的LMON的TRC文件有变化，产生大量的新内容
也就是LMON在RAC关闭过程要作大量的工作，非常重要
[oracle@jingfa1 bdump]$ tail -100f jingfa1_lmon_17921.trc
kclobj: scanning buffer
kclobj: cr buffer on object queue
kclobj: scanning buffer
kclobj: cr buffer on object queue
中间略
*** 2015-11-17 02:16:01.170
 Submitted all GCS cache requests
 sent syncr inc 22 lvl 7 to 0 (22,22/0/0) 
 Post SMON to start 1st pass IR
 Fix write in gcs resources
 sent syncr inc 22 lvl 8 to 0 (22,24/0/0) 
*** 2015-11-17 02:16:01.181
Reconfiguration complete
*   domain 0 valid?: 0 


[oracle@jingfa1 bdump]$ 




---接上，我们继续启动节点2，看下节点1的LMON TRC文件
同上，也是产生大量的内容，可见LMON在RAC节点关闭及重启，此进程的作用非常重要