Oracle核心进程详解并kill验证

Oracle核心进程详解并kill验证

一、说明

在很多情况下我们需要杀死后台进程。比如系统出现了大量HANG住的现象，而通过HANGANALYZE我们发现元凶是一个后台进程，那么我们是否通过杀掉这个进程来解决问题，就要十分谨慎了。因为有些后台进程是不能随便杀的，一旦杀掉就可能导致数据库实例崩溃。

二、核心进程详解

2.1.PMON-进程监控进程

pmon（Process Monitor process）用于监控其他后台进程。负责在连接出现异常中止后进行清理工作。例如，一个专用服务器进程崩溃或者出于某种原因被结束掉，就要由PMON进程负责善后（恢复或者撤销工作），并释放资源。PMON会回滚未提交的工作，释放锁，并释放之前为失败进程分配的SGA资源。
PMON还负责监视其他Oracle后台进程，并在必要时重启这些后台进程。

主要作用：

• pmon进程会被定期唤醒，来清理dead process，并释放dead process持有的资源(latch and lock)。pmon通过轮询方式去检测dead
  process，轮询间隔为_dead_process_scan_interval（默认是60秒），并清理dead process
• 回滚dead transaction，前_cleanup_rollback_entries个undo entries，超过则post通知smon，剩下由smon来完成剩余的回滚工作。这个_cleanup_rollback_entries默认参数默认是100，生产可以考虑设置大一些
• 将数据库服务注册到监听，轮询每60秒（12c后这项工作由LRRG进程负责）
• 监控后台进程，如果核心进程crash，pmon负责终止实例
• rac服务端负载均衡，PMON进程每3秒会将各自节点的负载及连接数更新到service_register里面

2.2.SMON-系统监控进程

Smon（System Monitor Process）负责各种系统级清理职责。上面说的PMON进程所对应的是各个进程，而SMON则是从系统级的视角出发，成为了数据库上的垃圾回收器。

主要作用：

• 如有必要， 在实例启动时执行实例恢复。 在 Oracle RAC 数据库中，一个数据库实例的 SMON 进程可以为另一个失败的实例执行实例恢复。
• 在实例恢复期间， 由于读文件或表空间脱机错误而跳过的已终止事务，由 SMON 进行恢复。当表空间或文件重新联机时， SMON 将恢复该事务。
• 清理未使用的临时段。 例如， Oracle 数据库在创建索引时会分配扩展区。如果操作失败，则 SMON 会清理临时空间。
• 合并在字典管理的表空间中的多个连续空闲扩展区。

所做的工作：

• 清理临时表空间：举例来说，建立一个索引时，创建过程中为索引分配的区段被标记为temporary。如果出于某种原因create index会话异常中止了，smon就要负责清理这些区段。其他操作创建的临时区段也是由smon负责清理。
• 合并空闲表空间：如果你在使用字典管理的表空间，SMON会负责取得表空间中相互连续的空闲区段，合并成更大的空闲区段。
• 针对原来不可用的文件恢复活动的事务：这类似与数据库启动时smon的作用。在实例崩溃恢复时由于某个文件（或某些文件）不可用，可能会跳过一些失败的事务（即无法恢复），这些失败事务将由smon来恢复。举例来说，磁盘上的文件可能不可用或者未装载，导致部分事务失败，当文件变成可用时，smon将会恢复这些事务。
• 执行rac中失败节点的实例恢复：在一个rac配置中，集群中的一个数据库实例失败时，集群中的另外某个节点会打开该失败实例的重做日志文件，并恢复失败节点上的所有数据。
• 清理OBJ$：OBJ$是一个底层的数据字典表，数据库中几乎每个对象（表、索引、触发器、视图等）都在其中对应的一个条目。很多情况下，有些条目表示的可能是已经删除的对象，或者表示“not
  there”的对象（not there对象是Oracle依赖关系机制中使用的一种对象）。要由smon进程来删除这些不再需要的行。
• 管理撤销段：smon会负责实施撤销（undo）段的自动上下线（onlining和oflining），以及收缩撤销段。

Smon进程功能远不止以上几项，用到再补充。

2.3.DBWn-数据库块写入进程

DBWn（Database Writer Process）是数据库块写入进程。负责将buffer cache中的脏块写入磁盘，为buffer cache腾出更多空间（释放缓冲区来读入其他数据），再就是为了推进检查点（将在线重做日志文件中的位置前移，如果出现数据库崩溃，Oracle会从这个位置开始读取来恢复实例）。
DBWn进程可以配置多个，11g最多36个，12c最多100个。使用下面语句可查看：

Select name,description from v$bgprocess where description like ‘db writer process%’;

查看当前数据库DBWn进程数量，查询db_writer_processes参数
修改DBWn进程数量：

alter system set db_writer_processes=4 scope=spfile;

注意DBWn进程设置越多占用CPU资源就越多，所以不是越多越好，得根据情况来。
Oracle默认的DBWn进程数量是cpu_count参数的1/8，它的数量影响写入磁盘的速度，如果写入速度不够快，不能很快的释放buffer cache，就出出现Free Buffer Waits 和 Write Complete Waits这两个等待事件的数量和等待时间开始增加。
另外，DBWn使用异步（ASYNC）I/O将块写到磁盘。采用异步I/O，DBWn会收集一批要写的块，并把他们交给操作系统。DBWn并不等待操作系统真正将块写出；而是立即返回，并收集下一批要写的块。当操作系统完成写操作时，它会异步地通知DBWn写操作已经完成。这样，与把所有工作都串行起来执行相比，DBWn可以更快地工作。
另外注意DBWn进程写入磁盘是离散写（scattered write），会把块分散地写到磁盘的各个位置。
LGWR是顺序写（sequential write）。

DBWn 进程在下列条件下会将脏缓冲区写入到磁盘：

• 当服务器进程扫描了额定数目的缓冲区后， 仍未找到干净的可重复使用的缓冲区时，它会通知 DBWn 执行写入操作。 DBWn 尽可能以异步方式将脏缓冲区写入到磁盘，以便同时能执行其他处理。
• DBWn 周期性地写出缓冲区，以推进检查点，该点是重做线程中实例恢复开始的位置。 检查点的日志位置由在缓冲区高速缓存中最老的脏缓冲区确定。
• 检查点触发，包括完全检查点和增量检查点，以及object checkpoint

至于DBWn进程怎么判断哪些脏块应该写，是怎么写的，相关到检查点队列（checkpoint queue），LRU算法（Least Recently Used）等知识。

2.4. LGWR-日志写入器进程

Lgwr进程负责将SGA中重做日志缓冲区（redo log buffer）的内容刷新输出到磁盘。LGWR是顺序写（sequential write），比离散写效率高。

触发条件：

• 每过3秒；
• 一个提交或回滚发生；
• 发生online redo log切换
• 重做日志缓冲区已达到三分之一满，或包含 1 MB 以上被缓冲的数据
• DBWn 必须将修改的缓冲区写入到磁盘

在 DBWn 可以将脏缓冲区写到磁盘之前，与该缓冲区更改相关联的重做记录必须先被写入磁盘 （预写协议）。如果 DBWn
发现一些重做记录尚未写入， 则它通知 LGWR 将记录写入磁盘，并等待 LGWR 完成此工作，然后DBWn 才将数据缓冲区写入磁盘。

lgwr和commit:
Oracle使用快速提交机制来提高已提交事务的性能。当用户发出commit语句时，事务分配到一个scn。lgwr将一个提交记录记入redo log buffer，连同提交scn和事务的重做条目，并立即写入到磁盘。 重做日志缓冲区是循环的。当 LGWR将重做条目从重做日志缓冲区写入到联机重做日志文件时，服务器进程可以复制新条目并覆盖已写入到磁盘的重做日志缓冲区中的条目。 通常 LGWR 的写入速度足够快， 以确保在缓冲区中总会有可用空间供新条目使用， 即使对联机重做日志的访问很繁重时也是如此。
包含事务提交记录的重做条目的原子写入， 是确定该事务已提交的唯一事件。 Oracle
数据库向已提交事务返回一个成功代码，虽然数据缓冲区尚未写入到磁盘。 对数据块的相应更改被延迟，直到 DBWn
在某个有利的时机将它们写到数据文件。

注意：
LGWR 可能会在提交事务之前， 将重做日志条目写入到磁盘。 只有之后提交了事务，这些重做条目才会成为永久性的。当事务活动很高时，LGWR 可能会使用组提交。 例如， 某个用户提交其事务， 导致 LGWR 将事务的重做条目写入到磁盘。在此写操作的过程中，其他用户也试图提交。 但 LGWR无法写入磁盘以提交这些事务，直到前面的写入完成为止。完成后, LGWR 可以将（尚未提交的)等待事务中的重做条目列表在一个操作中全部写入。
通过这种方式， 数据库最小化了磁盘 I/O， 而最大化了性能。如果提交请求继续维持在一个高的水平，则每个 LGWR写入操作都可能包含多个提交记录。

2.5. CKPT-检查点进程

检查点（checkpoint）是一种机制。它的作用是通知dbwn进程将数据库缓冲区缓存（buffer cache）中的已修改的数据脏块写入到disk中，ckpt进程负责通知 dbwn进程。
要修改数据库中的数据，首先需要将数据从数据文件中取出到SGA的buffer cache中，这里是要修改数据的一个副本，在这里进行修改的同时，会将变更向量写入到SGA中的redo log buffer内存区域，然后通过lgwr进程实际写入到磁盘上的redo log中。到这一步，修改的数据还没有实际写入磁盘，但是redo log中已经有记录。
假设这时候数据库崩溃了，那么内存中修改过的、尚未写入数据文件的数据会丢失。在下一次数据库启动之后，Oracle会通过redo log进行事务重演，也就是进行前滚操作，将数据库恢复到崩溃前的状态（这里我的理解是将redo log中的记录应用到数据文件，这样就保持了一致性），然后数据库可以打开使用，在之后Oracle会将没有提交的数据进行回滚。
崩溃后打开数据库，需要先读取redo log完成前滚，需要前滚的数据越多，那么打开时间越长。检查点的存在就是为了缩短这个恢复时间。
检查点位置是由buffer cache中最旧的脏缓冲区来确定的。
检查点位置作为一个指向重做流的指针，并存储在控制文件中，和在每个数据文件头中。

目标：
使用检查点，能实现以下目标：

• 缩短实例崩溃或介质故障情况下恢复所需的时间
• 确保在buffer cache中的脏缓冲区（dirty buffer）被定期写入磁盘
• 确保在一致性关闭过程中所有已提交的数据都被写入磁盘

检查点结构：

• Checkpoint SCN
• Checkpoint RBA （RBA（redo byte address）重做字节地址：当前检查点位置，是发生实例故障时重做流中必须由此开始的恢复位置）
• Thread that allocated the checkpoint
• Enabled thread bitmap
• Timestamp

检查点类型：
1、线程检查点（Thread checkpoints） 数据库将某个确定目标之前、
被某个特定的重做线程所修改的所有缓冲区写入磁盘。 数据库中所有实例的线程检查点的集合即为数据库检查点。线程检查点在下列情况下发生：

• 一致的数据库关闭
• ALTER SYSTEM CHECKPOINT 语句
• 联机重做日志切换
• ALTER DATABASE BEGIN BACKUP 语句

2、表空间和数据文件的检查点（Tablespace and data file checkpoints） 数据库将某个确定目标之前、
被重做线程所修改的所有缓冲区写入磁盘。表空间检查点是一组数据文件检查点，每个数据文件检查点对表空间中的某个数据文件做检查点操作。这些检查点发生在很多情况下，
包括将一个表空间变为只读、将表空间脱机、 收缩数据文件、 或执行 ALTER TABLESPACE BEGIN BACKUP 等。

3、增量检查点（Incremental checkpoints） 增量检查点是一种线程检查点， 部分原因是为了避免在redo
log切换时写入大量的块。 DBWn 至少每隔三秒会进行检查以确定是否有工作要做。 当 DBWn 将脏缓冲区写入磁盘时,
它会向前推进检查点位置，导致 CKPT 将检查点位置写入控制文件，而不是数据文件头。

4、其他类型的检查点包括实例和介质恢复检查点， 和删除或截断模式对象时的检查点。

5、完全检查点只会在执行 alter system checkpoint 语句或 consistent shutdown 关闭数据库时出现。

三、Kill验证

3.1.kill ckpt进程

[oracle@p19c ~]$ ps -ef|grep ckpt
oracle    15962      1  0 12:09 ?        00:00:00 ora_ckpt_p19c
oracle    28160  26720  0 12:38 pts/3    00:00:00 grep --color=auto ckpt
[oracle@p19c ~]$ kill -9 15962

–执行了上述命令后，ALERT LOG中出现了：

–可以看到，由于ckpt出现故障，PMON进程将实例关闭了：

3.2.kill pmon进程

当pmon被杀掉后，是一个前台进程(Instance terminated by User)执行了shutdown abort操作，终结了实例。从这一点上我们也可以看出，虽然pmon是监控进程的后台进程，一旦重要的后台进程出现故障，pmon会自动关闭实例。反过来所有的Oracle 进程，包括前台进程和后台进程都在反过来监视PMON，一旦发现pmon异常，立即会关闭实例。这种相互监控也是大型系统中最为常用的方法。

[oracle@p19c ~]$ ps -ef | grep pmon
oracle    15917      1  0 12:32 ?        00:00:00 ora_pmon_p19c
oracle    30325  26983  0 13:10 pts/3    00:00:00 grep --color=auto pmon
[oracle@p19c ~]$ kill -9 15917
[oracle@p19c ~]$ ps -ef | grep pmon
oracle    33582  26983  0 13:17 pts/3    00:00:00 grep --color=auto pmon

可以看到，kill pmon进程后数据库实例崩溃：

3.3.kill mman进程

MMAN(Memory Manager )进程是10g新引入的进程，主要目的是执行共享内存自动管理的功能，自动调整共享内存各个组件的大小。

[oracle@p19c ~]$ ps -ef | grep mmon
oracle    30119      1  0 13:55 ?        00:00:00 ora_mmon_p19c
oracle    30731  26663  0 13:56 pts/3    00:00:00 grep --color=auto mmon
[oracle@p19c ~]$ kill -9 30119
[oracle@p19c ~]$ ps -ef | grep mmon
oracle    31083      1  0 13:57 ?        00:00:00 ora_mmon_p19c
oracle    31284  26663  0 13:57 pts/3    00:00:00 grep --color=auto mmon

可以看到mmon进程被强制杀掉，mmon进程会被重启，而数据库实例没有发生故障。因此在某些情况下mmon进程如果故障，在必要情况下，我们是可以杀掉该进程的。

3.4.kill psp0进程

PSP0进程在10g中开始引入，主要功能是启动其他的Oracle 进程。这个进程也是一个十分关键的核心进程，一旦故障，将导致数据库实例故障。

[oracle@p19c ~]$ ps -ef | grep psp0
oracle    15921      1  0 13:22 ?        00:00:00 ora_psp0_p19c
oracle    37220  26663  0 14:11 pts/3    00:00:00 grep --color=auto psp0
[oracle@p19c ~]$ kill -9 15921
[oracle@p19c ~]$ ps -ef | grep psp0
oracle    37696  26663  0 14:12 pts/3    00:00:00 grep --color=auto psp0

–可以看到kill掉psp0进程后，实例崩溃：

3.5.kill cjq0进程

cjq0是一个任务队列的调度进程，负责从job$表中找到需要执行的Job,并分配job进程执行Job，如果job进程不足，会自动产生新的job进程(job_queue_processes参数限制范围内)。

[oracle@p19c ~]$ ps -ef | grep cjq0
oracle    17105      1  0 13:59 ?        00:00:02 ora_cjq0_p19c
oracle    27244  26787  0 14:24 pts/3    00:00:00 grep --color=auto cjq0
[oracle@p19c ~]$ kill -9 17105
[oracle@p19c ~]$ ps -ef | grep cjq0
oracle    28430      1  0 14:27 ?        00:00:00 ora_cjq0_p19c
oracle    28665  26787  0 14:28 pts/3    00:00:00 grep --color=auto cjq0

可以看出CJQ进程如果被杀掉，CJQ0进程会被重启，而数据库实例没有发生故障。因此在某些情况下CJQ0进程如果故障，在必要情况下，我们是可以杀掉该进程的。

3.6.kill jxxx进程

既然CJQ0都可以杀，那么CJQ0产生的JXXX进程我们就不用做实验了，肯定是能杀的了。在某些系统中，经常会有一些JOB进程占用了大量的系统资源，从而导致数据库性能问题，这种情况下，为了恢复OLTP应用的性能，杀掉JOB进程是最简单的方法。不过在杀掉JOB进程之前一定要做仔细的分析，如果JOB进程中正在做一个数据量很大的大型修改事务，那么杀掉这个JOB，可能会导致产生大量的回滚操作，从而对系统性能产生更为不利的影响。

3.7.kill arch进程

ARCH进程的主要职责是在重做日志文件切换后，将已经写满的重做日志文件复制到归档日志文件中，以防止循环写入重做日志文件时将其覆盖。因此，如果ARCH进程被kill，新的归档日志文件的生成将会受阻。
arch进程一般是arc0,arc1，…
ARC0进程被杀掉后，会自动重启，而数据库实例没有发生故障。因此在某些情况下ARCH进程如果故障，在必要情况下，我们是可以杀掉该进程的。

3.8.kill qmon进程

QMON进程主要负责队列的监控和同步，以及队列服务的管理。它可能涉及与Oracle的队列功能相关的任务，如消息队列的处理等。
经过测试，QMON进程是可以杀的，杀掉QMON进程的后果是相关进程重启。
虽然QMON进程可以被终止，但这样做可能会对数据库的性能和稳定性产生影响。因此，在实际操作中应谨慎处理，确保了解可能的风险和后果。

3.9.kill mmnl进程

MMNL进程也是AWR新增的进程，主要作用是将AWR数据从内存中刷到表中。这个进程也如果被杀掉也是可以自动重启的。

[oracle@p19c ~]$ ps -ef | grep mmnl
oracle    15986      1  0 14:20 ?        00:00:00 ora_mmnl_p19c
oracle    34033  26771  0 15:04 pts/3    00:00:00 grep --color=auto mmnl
[oracle@p19c ~]$ kill -9 15986
[oracle@p19c ~]$ ps -ef | grep mmnl
oracle    34694      1  0 15:06 ?        00:00:00 ora_mmnl_p19c
oracle    36433  26771  0 15:10 pts/3    00:00:00 grep --color=auto mmnl

可以看到mmnl进程被强制杀掉，mmnl进程会被重启，而数据库实例没有发生故障。因此在某些情况下mmnl进程如果故障，在必要情况下，我们是可以杀掉该进程的。

3.10.kill reco进程

[oracle@p19c ~]$ ps -ef | grep reco
oracle    15972      1  0 14:20 ?        00:00:00 ora_reco_p19c
oracle    38691  26771  0 15:15 pts/3    00:00:00 grep --color=auto reco
[oracle@p19c ~]$ kill -9 15972
[oracle@p19c ~]$ ps -ef | grep reco
oracle    39087      1  0 15:16 ?        00:00:00 ora_reco_p19c
oracle    39895  26771  0 15:18 pts/3    00:00:00 grep --color=auto reco

–kill reco进程后alert日志报错：

–随后reco进程重启：

在某些情况下，如果RECO进程被阻塞或处于异常状态，它可能会阻止数据库的正常关闭。但有时需要杀掉RECO进程才能关闭数据库。然而，这只是一个权宜之计，并且应该谨慎使用，因为它可能导致数据丢失或不一致。如果必须杀掉RECO进程，那么应该谨慎操作，并确保有适当的备份和恢复策略来应对可能出现的问题。

3.11.kill smon进程

[oracle@p19c ~]$ ps -ef | grep smon
oracle    15966      1  0 14:59 ?        00:00:00 ora_smon_p19c
oracle    27225  26760  0 15:27 pts/3    00:00:00 grep --color=auto smon
[oracle@p19c ~]$ kill -9 15966
[oracle@p19c ~]$ ps -ef | grep smon
oracle    28273  26760  0 15:29 pts/3    00:00:00 grep --color=auto smon

–可以看到kill掉smon进程后，数据库实例会崩溃：

3.12.kill dbwn进程

直接kill掉dbwn进程通常不会导致数据库实例立即崩溃，但会严重影响数据库的稳定性和性能。然而，如果由于dbwn进程的缺失导致数据库长时间处于不稳定状态，并且其他关键进程（如pmon、smon等）也无法正常工作，那么最终可能会导致数据库实例崩溃。

3.13.kill lgwr进程

如果LGWR进程长时间无法恢复工作，并且重做日志缓冲区持续满溢，那么Oracle可能会决定终止数据库实例以防止进一步的数据损坏。这是Oracle的一种保护机制，旨在确保数据库的一致性和完整性。
如果LGWR进程被kill，并且在此之后数据库实例崩溃，那么恢复过程将变得更加复杂和困难。由于没有完整的重做日志记录，Oracle可能无法准确地确定在崩溃时哪些更改尚未被应用到数据文件中。这可能导致在恢复过程中需要更多的手动干预和更长的恢复时间。

[oracle@p19c ~]$ ps -ef |grep lgwr
oracle    15960      1  0 15:06 ?        00:00:00 ora_lgwr_p19c
oracle    30290  26714  0 15:41 pts/3    00:00:00 grep --color=auto lgwr
[oracle@p19c ~]$ kill -9 15960
[oracle@p19c ~]$ ps -ef |grep lgwr
oracle    30482  26714  0 15:42 pts/3    00:00:00 grep --color=auto lgwr

–可以看到kill掉lgwr进程后数据库实例崩溃：

3.14.补充

·DISPATCHER进程DXXX：如果被杀掉，ALERT会有报错，不会导致实例宕机，根据需要进行重启

·共享服务进程SXXX：如果被杀掉，不会导致实例宕机，根据需要进行重启

·并行进程PXXX/PZXX：并行进程，如果被杀掉，不会导致实例宕机，进程根据需要进行重启

·高级队列从属进程QXXX：如果被杀掉，不会导致实例宕机，进程根据需要重启。如果哦存在高级队列操作，杀掉此类进程要十分慎重