結論

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節點關閉及重啟，此程式的作用非常重要

基於oracle 10.2.0.1 rac學習lmon程式系列六

結論

引申問題

測試

相關文章