在很多情况下我们需要杀死后台进程。比如系统出现了大量HANG住的现象，而通过HANGANALYZE我们发现元凶是一个后台进程，那么我们是否通过杀掉这个进程来解决问题，就要十分谨慎了。因为有些后台进程是不能随便杀的，一旦杀掉就可能导致数据库实例崩溃。因此，有些DBA给自己定了一个金科玉律，就是后台进程绝对是不能杀的。
其实这种做法过于保守了，只要你能够了解后台进程的主要功能，就可以十分安全的管理后台进程了。本节老白将要和大家讨论的问题就是究竟哪些后台进程是可以杀的。本节我们以Oracle 10g 和11g为讨论对象，探讨一下Oracle的后台进程哪些是可以杀的哪些是不可以杀的。
首先我们来看六大核心进程，其实Oracle 并没有这个概念，这是老白自己的归纳总结。那么哪几个后台进程可以称为六大核心进程呢？Pmon、smon、dbwr、lgwr、reco、ckpt这几个进程是所有Oracle 数据库必不可少的进程，其中ckpt进程的出现较晚，其他四个进程是老白使用Oracle 数据库以来，就存在的系统进程。这些进程无论哪个出现故障，都会导致数据库实例崩溃。因此来说，这些进程是无论如何都不能杀的。如果我们杀掉其中某个进程，在ALERT LOG中就会发现如下的错误：
在某个shell中，杀掉ckpt进程：
[oracle@localhost ~]$ 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
[oracle@localhost ~]$ kill -9 5377
执行了上述命令后，我们发现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 Instancedue to error 469
Mon Sep 26 08:48:32 2011
ORA-1092 : opitsk aborting process
Dumping diagnostic data indirectory=[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被杀掉后，是一个前台进程（Instance terminated byUser）执行了shutdownabort操作，终结了实例。从这一点上我们也可以看出，虽然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进程，cjq0是一个任务队列的调度进程，负责从job$表中找到需要执行的Job,并分配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数据从内存中刷到表中。这个进程也如果被杀掉也是可以自动重启的。在这里我们就不一一列出实验数据了：
n DISPATCHER进程DXXX：如果被杀掉，ALERT会有报错，不会导致实例宕机，根据需要进行重启
n 共享服务进程SXXX：如果被杀掉，不会导致实例宕机，根据需要进行重启
n 并行进程PXXX/PZXX：并行进程，如果被杀掉，不会导致实例宕机，进程根据需要进行重启
n 高级队列从属进程QXXX：如果被杀掉，不会导致实例宕机，进程根据需要重启。如果存在高级队列操作，杀掉此类进程要十分慎重
Oracle 10g引入了ASM后，也新增了一些和ASM有关的进程。首先ASM实例具有一系列的后台进程，其次，RDBMS为了访问ASM也新增了一系列的后台进程，首先我们来看看ASM实例的后台进程。
ASM实例也拥有类似RDBMS实例的核心进程，另外ASM实例新增了一些其他的后台进程，下面我们做一个简单的了解。
l ASMB - 当数据库实例使用SPFILE的时候启动的ASM后台进程。这个进程是十分关键的，一旦故障将导致ASM实例宕机。
l RBAL - DISKGROUP做rebalance的后台进程，该进程一旦故障将导致ASM实例宕掉。
l DBW0 - DB writes,和RDBMS的DB WRITER类似，不过是将ASM CACHE中的数据写入磁盘，该进程一旦故障将导致ASM实例故障。
l SMON - 恢复进程，类似RDBMS的SMON进程，处理DISKGROUP的恢复操作，一旦故障将导致ASM实例故障。
l CKPT - Checkpoint进程，类似RDBMS的CKPT进程，一旦故障将导致ASM实例故障。
l PSP0 - 启动其他ASM实例进程的进程，一旦故障将导致ASM实例故障。
l GMON -群组监控进程，用于节点监控和状态表的维护，一旦故障将导致ASM实例故障。
l ora_ASMB_<dbsid>: 特殊的ASM前台进程。
l KATE - Konductor or ASM Temporary Errands,，用来ONLINE磁盘的临时任务进程。
l VKTM - 管理快速计时器的进程。
l PING - 计量网络延时的进程。
l DIA? - 类似数据库的diag进程。
l DIAG - 类似数据库的diag进程。
l LGWR - Log writer, 和数据库类似，处理磁盘组的REDO信息。
l LMON - 锁监控进程，类似数据库的LMON。
l LMS? - 锁监控SLAVE进程，类似数据库的LMS进程。
l MMAN - SGA自动调整进程，类似数据库的MMAN。
l b??? - 用于离线磁盘的SLAVE进程。
l x??? - 磁盘组重配置后删除磁盘的SALVE进程。
l pz?? - 用于GLOBAL VIEW查询的并行SLAVE进程。
Oracle 11g在后台进程方面有了较多的改变，这种改变有时候让我们甚至感觉不太认识Oracle 数据库了，我们需要重新认识Oracle 11g的后台进程结构。下面是新增的后台进程：
n ACMS (atomic controlfile to memory service) ，这是每个实例都有的代理进程，在RAC环境下，对控制进程事务的提交和回退起到辅助作用。
n DBRM (database resource manager)，用于资源管理和资源计划相关的任务。
n DIA0 (diagnosability process 0) (目前只有0，没有其他进程)，用于数据库的hang检测和死锁处理。
n DIAG (diagnosability) ，进行诊断DUMP，执行全局oradebug命令。
n EMNC (event monitor coordinator) ，用于数据库事件管理和发布的进程。
n FBDA (flashback data archiver process)，闪回区归档进程，用于将跟踪表的历时记录记录写入归档日志，管理闪回数据区的空间。
n GTX0-j (global transaction)，在RAC环境中为XA全局事务提供透明的服务，只在RAC环境中能见到这个进程。系统会更具XA事务的负载情况确定启动几个这种进程。
n KATE，当磁盘离线时代理ASMmeatadata的I/O。
n MARK，当写入一个离线磁盘出错时记录这个ALLOCATION UNIT为过期状态。
n SMCO (space management coordinator)，执行空间管理有关的作业，比如空间预分配和空间回收。可以动态生成Wnnn SLAVE进程。
n VKTM (virtual keeper of time) ，每秒钟更新一次时间，在高优先级情况下可以提供20毫秒的基准时间计数。
n DSKM (slave diskmon) ，用于RDBMS和ASM实例之间的联系通道。Master Diskmon守护进程处理I/O隔离信息、I/O资源关联计划将Transaction Commit Cache 信息传输到SAGE存储。也用来在节点和SAGE存储服务器之间实现skgxp ANT协议。如果没有配置SAGE存储，diskmon slave进程会在实例启动后自动关闭。
