oracle后台进程杀掉会怎么样

在很多情况下我们需要杀死后台进程。比如，系统出现了大量挂起的现象，而通过HANGANALYZE工具分析，我们发现元凶是一个后台进程，那么是否要通过杀掉这个进程来解决问题，就要十分谨慎了。因为有些后台进程是不能随便杀的，一旦杀掉就可能导致数据库实例崩溃。因此，有些DBA给自己定了一条金科玉律，就是后台进程绝对是不能杀的。

其实这种做法过于保守了，只要你足够了解后台进程的主要功能，就可以十分安全地管理后台进程了。本节老白将以Oracle 10g和11g为例，和大家讨论究竟哪些后台进程是可以杀的。

首先我们来看六大核心进程。其实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 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进程会在实例启动后自动关闭。