在很多情況下我們需要殺死後臺程序。比如，系統出現了大量掛起的現象，而通過HANGANALYZE工具分析，我們發現元凶是一個後臺程序，那麼是否要通過殺掉這個程序來解決問題，就要十分謹慎了。因為有些後臺程序是不能隨便殺的，一旦殺掉就可能導致資料庫例項崩潰。因此，有些DBA給自己定了一條金科玉律，就是後臺程序絕對是不能殺的。

其實這種做法過於保守了，只要你足夠了解後臺程序的主要功能，就可以十分安全地管理後臺程序了。本節老白將以Oracle 10g和11g為例，和大家討論究竟哪些後臺程序是可以殺的。

首先我們來看六大核心程序。其實Oracle並沒有核心程序這個概念，這是老白自己的歸納總結。那麼哪幾個後臺程序可以稱為六大核心程序呢？pmon、smon、dbwr、lgwr、reco和ckpt這六個程序是所有Oracle 

在某個shell中，殺掉ckpt程序：
[[email protected] ~]$ ps -ef|grep ckpt
grid      5245     1  0 Sep25 ?        00:00:00 asm_ckpt_+ASM
oracle    5377     1  0 Sep25 ?        00:00:22 ora_ckpt_orcl
oracle   10891 10763  0 08:48 pts/4    00:00:00 grep ckpt
[

執行了上述命令後，我們發現ALERT LOG中出現了：
Mon Sep 26 08:48:31 2011
System state dump requested by (Instance=1, osid=5342 (PMON)), summary=[abnormal Instance termination].
System State dumped to trace file /u01/app/oracle/diag/RDBMS/orcl/orcl/trace/orcl_diag_5365.trc
Mon Sep 26 08:48:32 2011
PMON (ospid: 5342): terminating the Instance due to error 469
Mon Sep 26 08:48:32 2011
ORA-1092 : opitsk aborting process
Dumping diagnostic data in directory=[cdmp_20110926084831], requested by (Instance=1, osid=5342 (PMON)), summary=[abnormal Instance termination].
Instance terminated by PMON, pid = 5342

可以看到，由於ckpt出現故障，pmon程序將例項關閉了。如果殺掉pmon又會出現什麼情況呢？
Mon Sep 26 08:52:58 2011
Shutting down Instance (abort)
License high water mark = 4
USER (ospid: 11224): terminating the Instance
Instance terminated by USER, pid = 11224
Mon Sep 26 08:52:59 2011
Instance shutdown complete

我們看到，當pmon被殺掉後，一個前臺程序執行了shutdown abort操作，終結了例項（Instance terminated by User）。可以看出，雖然pmon是監控程序的後臺程序，但是一旦重要的後臺程序出現故障，pmon會自動關閉例項。反過來所有的Oracle程序，包括前臺程序和後臺程序，也在監視pmon，一旦發現pmon異常，會立即關閉例項。這種相互監控的機制也是大型系統中最為常用的方法。

下面我們來看看10g新增加的MMAN程序，MMAN（Memory Manager ）程序是10g新引入的程序，主要目的是實現共享記憶體自動管理的功能，自動調整共享記憶體各個元件的大小。
Mon Sep 26 11:09:52 2011
Errors in file /opt/oracle/admin/orcl/bdump/orcl_pmon_6261.trc:
ORA-00822: MMAN process terminated with error
Mon Sep 26 11:09:52 2011
PMON: terminating Instance due to error 822
Instance terminated by PMON, pid = 6261

可以看到，一旦MMAN程序出現故障，資料庫例項就會崩潰。看樣子MMAN是繼六大核心程序之後的第七個不可殺的核心程序。

PSP0程序在10g中開始引入，主要功能是啟動其他的Oracle程序。這個程序也是一個十分關鍵的核心程序，一旦出現問題，將導致資料庫例項故障。
Errors in file /opt/oracle/admin/orcl/bdump/orcl_pmon_32149.trc:
ORA-00490: PSP process terminated with error
Mon Sep 26 14:14:55 2011
PMON: terminating Instance due to error 490
Instance terminated by PMON, pid = 32149

至此，我們已經看到了八個關鍵核心程序。

下面我們來看一下cjq0程序。它是一個任務佇列的排程程序，負責從job$表中找到需要執行的任務，並分配job程序執行，如果job程序不足，會自動產生新的job程序（在job_queue_processes引數限制範圍內）。下面來看看殺掉這個程序會有什麼結果。
Mon Sep 26 09:07:18 2011
Restarting dead background process CJQ0
Mon Sep 26 09:07:18 2011
CJQ0 started with pid=25, OS id=12226

可以看出cjq程序如果被殺掉，cjq0程序會被重啟。

既然cjq0都可以殺，那麼cjq0產生的JXXX程序我們就不用做實驗了，肯定是能殺的了。其實老白也是經常殺掉JOB程序的，在某些系統中，經常會有一些JOB程序佔用大量的系統資源，從而導致資料庫效能問題。這時，為了恢復OLTP應用的效能，殺掉JOB程序是最簡單的方法。不過在殺掉JOB程序之前一定要做仔細的分析，如果JOB程序中正在做一個數據量很大的大型修改事務，那麼殺掉這個JOB，可能會導致大量的回滾操作，從而對系統性能產生更為不利的影響。

下一個我們要來研究的是arch程序，在Oracle 10g中，arch程序一般是arc0, arc1，...。我們來殺掉一個arch程序，看看會有什麼結果。
Mon Sep 26 09:56:27 2011
ARCH: Detected ARCH process failure
ARCH: STARTING ARCH PROCESSES
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0 started with pid=16, OS id=6646
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH

可以看出，arc0程序被殺掉後，會自動重啟，而資料庫例項沒有發生故障。因此arch程序如果出現故障，在必要情況下，我們是可以殺掉該程序的。

下面我們來看一下QMON程序，QMON程序是佇列監控同步程序（QMNC）和佇列服務程序（QXXX）的統稱。
Mon Sep 26 09:10:46 2011
Restarting dead background process CJQ0
Mon Sep 26 09:10:46 2011
CJQ0 started with pid=25, OS id=12347

從上面的測試可以看出，QMON程序是可以殺的，殺掉QMON程序的後果是相關程序重啟。

MMON和M000是Oracle 10g引入的新後臺程序，MMON是管理監控程序，M000是MMON的SLAVE程序，協助MMON程序工作。如果這些程序出現故障會有什麼結果呢?
Mon Sep 26 10:11:39 2011
Restarting dead background process MMON
MMON started with pid=11, OS id=11860

MMON程序是可以自動重啟的，當然也在可殺範圍內了。

類似的MMNL程序也是AWR新增的程序，主要作用是將AWR資料從記憶體中重新整理到表中。這個程序如果被殺掉也是可以自動重啟的。在這裡我們就不一一列出實驗資料了：

 DISPATCHER程序DXXX：如果被殺掉，ALERT會報錯，不會導致例項宕機，根據需要進行重啟。

 共享服務程序SXXX：如果被殺掉，不會導致例項宕機，根據需要進行重啟。

 並行程序PXXX/PZXX：並行程序，如果被殺掉，不會導致例項宕機，程序根據需要進行重啟。

 高階佇列從屬程序QXXX：如果被殺掉，不會導致例項宕機，程序根據需要進行重啟。如果存在高階佇列操作，殺掉此類程序要十分慎重。

Oracle 10g引入了ASM後，也新增了一些和ASM有關的程序。首先ASM例項具有一系列的後臺程序，其次，RDBMS為了訪問ASM也新增了一系列的後臺程序。我們來看看ASM例項的後臺程序。

ASM例項也擁有類似RDBMS例項的核心程序，另外ASM例項新增了一些其他的後臺程序，下面我們做一個簡單的瞭解。

 ASMB：當資料庫例項使用SPFILE時啟動的ASM後臺程序。這個程序是十分關鍵的，一旦出現故障將導致ASM例項宕機。

 RBAL：DISKGROUP做rebalance的後臺程序，該程序一旦有故障將導致ASM例項宕掉。

 DBW0：DB writes，和RDBMS的DB WRITER類似，不過是將ASM CACHE中的資料寫入磁碟，該程序一旦有問題將導致ASM例項故障。

 SMON：恢復程序，類似於RDBMS的SMON程序，處理DISKGROUP的恢復操作，一旦有問題將導致ASM例項故障。

 CKPT：Checkpoint程序，類似於RDBMS的CKPT程序，一旦有問題將導致ASM例項故障。

 PSP0：啟動其他ASM例項程序的程序，一旦有問題將導致ASM例項故障。

 GMON：群組監控程序，用於節點監控和狀態表的維護，一旦有問題將導致ASM例項故障。

 ora_ASMB：特殊的ASM前臺程序。

 KATE：Konductor or ASM Temporary Errands，用來執行ONLINE磁碟的臨時任務程序。

 VKTM：管理快速計時器的程序。

 PING：計量網路延時的程序。

 DIA?：類似於資料庫的diag程序。

 DIAG：類似於資料庫的diag程序。

 LGWR：Log writer, 和資料庫類似，處理磁碟組的REDO資訊。

 LMON：鎖監控程序，類似於資料庫的LMON程序。

 LMS?：鎖監控SLAVE程序，類似於資料庫的LMS程序。

 MMAN：SGA自動調整程序，類似於資料庫的MMAN。

 b???：用於離線磁碟的SLAVE程序。

 x???：磁碟組重配置後刪除磁碟的SALVE程序。

 pz??：用於GLOBAL VIEW查詢的並行SLAVE程序。

Oracle 11g在後臺程序方面有了較多的改變，這種改變有時候甚至讓我們感覺Oracle資料庫變陌生了，需要重新認識Oracle 11g的後臺程序結構。下面是新增的後臺程序。

 ACMS（atomic controlfile to memory service），這是每個例項都有的代理程序，在RAC環境下，對控制程序事務的提交和回退起到輔助作用。

 DBRM（database resource manager），用於資源管理和資源計劃相關的任務。

 DIA0 （diagnosability process 0），目前只有“0”，沒有其他程序，用於資料庫的掛起檢測和死鎖處理。

 DIAG（diagnosability），進行診斷DUMP，執行全域性oradebug命令。

 EMNC（event monitor coordinator），用於資料庫事件管理和釋出的程序。

 FBDA（flashback data archiver process），閃回區歸檔程序，用於將跟蹤錶的歷史記錄寫入歸檔日誌，管理閃回資料區的空間。

 GTX0-j （global transaction），在RAC環境中為XA全域性事務提供透明的服務，只在RAC環境中出現。系統會根據XA事務的負載情況確定啟動幾個這種程序。

 KATE，當磁碟離線時代理ASM metadata的I/O。

 MARK，當寫入一個離線磁碟出錯時記錄這個ALLOCATION UNIT為過期狀態。

 SMCO（space management coordinator），執行空間管理有關的作業，比如空間預分配和空間回收。可以動態生成Wnnn SLAVE程序。

 VKTM（virtual keeper of time），每秒更新一次時間，在高優先順序情況下可以提供20毫秒的基準時間計數。

 DSKM（slave diskmon），用於RDBMS和ASM例項之間的聯絡通道。Master Diskmon守護程序處理I/O隔離資訊，I/O資源管理計劃將Transaction Commit Cache資訊傳輸到SAGE儲存，也用來在節點和SAGE儲存伺服器之間實現skgxp ANT協議。如果沒有配置SAGE儲存，diskmon slave程序會在例項啟動後自動關閉。