Ora_pmon:是进程监视器(Process Monitor)的缩写。当取消当前的事务,或者释放进程占用的锁以及其它资源的时候,这个进程清空那些失败的进程。
Ora_vktm: 这个进程用于提供一个数据库的时钟,每秒更新;或者作为参考时间计数器,这种方式每20毫秒更新一次,仅在高优先级时可用。
Ora_gen0: 执行所需的任务,包括SQL和DML
Ora_diag: 主要用来捕获实例中失败进程的诊断信息,并生成相应的 TRACE 文件。该进程自动启动不需要进行调整,如果该进程失效则自动重新启动。
Ora_dbrm: Oracle资源管理器(Oracle Database Resource Manager,以下简称DBRM)管理数据库资源,为不同的会话分配不同的数据库资源。DBRM管理的资源主要包括CPU时间。
Ora_psp0: 进程生成器进程:它主要负责生成各个后台进程.
Ora_dia0: 另一个数据库诊断进程,负责检测Oracle数据库中的挂起(hang)和死锁的处理。
Ora_mman: 内存管理进程,负责内存的动态管理,分配和收回。
Ora_dbw0: 数据库写入进程,把缓冲区中的内容写入到数据文件中。
Ora_lgwr: 日志写入进程,把重做日志缓冲区中的内容写入到重做日志文。
Ora_ckpt: 检查点进程,检查点(checkpoint)是一个事件,当此事件发生时,DBWn进程将把SGA中所有改变的数据库缓冲区写入到数据文件中。CKPT进程的功能是当发生检查点事件时唤醒DBWn进程,更新数据库所有的数据文件和控制文件,并标记最新的检查点,以便下一次更新从最新的检查点开始。
Ora_smon: 系统监控进程,当失败的数据库实例重新启动时,SMON进程完成实例的恢复工作
Ora_reco: 恢复进程,用于解决分布式数据库中由于网络或系统故障导致挂起的分布式事务。在规定的时间间隔内,本地的RECO进程会试图连接到远程数据库,并自动完成挂起的分布式事务在本地的提交或回滚
Ora_mmon: 用于AWR ,MMON监控数据库性能,进行自动调优;
Ora_mmnl: MMNL负责将SGA中的统计信息写入到表中;
Ora:d000: 调度进程,允许用户进程共享一定数量的服务器进程,从而支持共享服务器配置。
Ora_s000: 共享服务器进程,在共享服务器配置中,每个共享服务器进程为多个客户请求提供服务
Ora_qmnc: 用于AQ功能;QMNC做为Qnnn的coordinator;
Ora_cjq0: 用于对job的协调,管理。
Ora_q000:建立的进程队列中的第一个。
Ora_q001: 建立的进程队列中的第二个。
q000
高级队列进程:使消息入队和出队。 高级队列的 Qmnc的slave 进程,完成QMNC 分配的任务。
j000是任务调度进程CJQ0的slave进程,j000进程无法启动,也就是说CJQ0进程没有办法启动他的slave进程,从trace中的Oracle process
(J000)
job 具体执行进程,接受 CJQ0 分发的 job 任务。
number: 48
Unix process
pid: 8324292, image: oracle@cmspdb1 (CJQ0)
可以看出,问题进程应该在CJQ0,也可用通过SQL查询找到问题进程
SQL> select program from v$process wheres pid=12690;
PROGRAM
------------------------------------------------
oracle@cmspdb2 (CJQ0)
然后我们来分析原因,首先是session,process是否足够
SQL> select count(*) from v$process;
COUNT(*)
----------
593
SQL> show parameter session;
SQL> select
count(*) from v$session;
COUNT(*)
----------
588
Process和session都没有问题,下面我们来看看job_queue_processes参数
SQL> show parameter job_queue_processes;
NAME TYPE VALUE
job_queue_processes integer 10
查看j000进程到底占用了多少。$ ps -ef|grep ora_j |grep -v grep
oracle 27263908 1
0 17时10分05秒- 0:00 ora_j002_pmcpdp1
oracle 26215608 1 104 17时10分00秒- 0:29 ora_j000_pmcpdp1
oracle 26740142 1
0 17时10分00秒- 0:05 ora_j001_pmcpdp1
不幸的是,开发人员在告诉我他们的应用丢失数据库连接时,报错已经消失了,最晚的告警日志报错信息是在16点36分左右。
但是我们可以很容易推测,在空闲时期j000已经有3个了,10个是可能不够用的,所以我们要调整job_queue_processes的值预防下次出现此类错误
SQL> Alter system set job_queue_processes=50 scope=both sid='*';
MMON可管理性监视器进程,以前也叫Memory Monitor,内存监视器进程用于支持Oracle数据库的自我管理和自我调整的进程,简单地理解为“监视器的监视器”。
m000进程,不过根据metalink上的描述,这个进行应该是MMON进程启动的从属平行进程,属于轻量级的进程,对系统没有多大的影响
关于告警日志里面的错误信息,我们看出m000进程创建失败,PMON进程无法启动该进程。一般情况下,PMON无法启动进程原因有下面一些:
1、Oracle连接数超过进程数限制。(正是由于Oracle达到了进程数限制,进而PMON无法创建m000进程)
2、进程死锁。
MMAN
MMAN,Memory Manager,内存管理进程,支持内存分配的自动管理。有了这个进程,我们DBA只需要去设置总的内存大小,SGA以及PGA等,MMAN会在DBA设置的总体大小范围内进行自动分配。
新多的后台进程有:ora_dbrm_orcl,ora_dia0_orcl,ora_psp0_orcl,ora_smco_orcl,ora_vktm_orcl,ora_w000_orcl,
这些后台进程的功能分别如下:
DBRM:数据库资源管理进程, (The database resource manager process),负责设置资源计划和其他的资源管理的工作。
DIAG:数据库诊断进程, (The diagnosibility process) ,负责维护管理各种用于诊断的转储文件,并执行oradebug命令。
DIA0:另一个数据库诊断进程,负责检测Oracle数据库中的挂起(hang)和死锁的处理。
PSP0:process spawner,用于产生oracle进程
SMCO:space management coordinator,该进程负责空间管理协调管理工作,负责执行空间的分配和回收。
Wnnn;命名为W000,W001,W002.....,由smcO动态产生执行上述相关任务。
VKTM:virtual keeper of time,用于提供wall-clock time,(每秒钟更新一次)。提供每二十毫秒更新一次的reference-time counter,看起来有点类似计时器的功能。
Oracle11g 新引入的其他后台进程
再来认识一下Oracle11g中新引入的一些其他进程,因为一些特性在我的测试库中没有用到,比如asm,所以在ps -ef的结果中没有。
GMON:用于维护asm磁盘组的磁盘之间的关系。
KATE:当ASM的磁盘离线的时候,该进程负责asm的元文件的io读写。
MARK:如果有向asm离线磁盘的missed 写请求,该进程将ASM分配的单元的状态标记为stale
FBDA:涉及到flashback-data-archive新特性的一个进程,The flashback data archiver proces。用于将“轨表”(tracked tables)的历史数据进行归档。当“轨表”上的事务提交以后,fbda进程负责将数据的前镜像保存到flashback archive区域。该进程还负责flashback的数据归档的空间管理、分配、保留,跟踪tracked transactions。
什么是“轨表”(tracked tables): 是指启用了flashback archive特性的表。
RMSn:The Oracle RAC management processes,负责执行Oracle RAC的管理任务,比如RAC相关资源的创建和集群中新实例的添加。
DSKM:The slave diskmon process , 负责oracle 实例、asm实例和磁盘的管理进程之间的io fencing 信息的交换。如果使用SAGE的存储,该进程还负责SAGE存储的一些信息的管理。
事后我检查了一下v$resource_limit,发现会话连接数、进程数并没有超。那么完全可以排除这个因素,那么现在就有可能是进程死锁或bug造成的
同事在检查过程中发现Physic memory资源严重不足,引起了Swap频繁读写。继续检查SGA参数发现sga_max_size、sga_target设置过大(这台测试服务器是虚拟机做的克隆,生产环境的RAM为64G,SGA也设置较大,克隆过后ORACLE实例启动不了,调整了SGA_TARGET、SGA_MAX_SIZE等参数后才启动成功,但是不知为什么sga_max_size设置了成了11264M(11G),有可能是当时要设置为1G多,因为物理内存才3G多,但是不知是手抖了还是搞晕了,当然也不排除后面被人改掉,居然设置成了11264M大小,汗颜啊。居然运行了这么久直到最近才出现问题,测试数据库基本不会做巡检)
经查MOS(Oracle Linux: ORA-27301:OS Failure Message: No Buffer Space Available (文档 ID 2041723.1),发现可能是因为网卡的MUT参数设置过高导致网卡的缓存不足导致的。
Fri Nov 24 09:11:42 2017
skgxpvfynet: mtype: 61 process 11799 failed because of a resource problem in the OS. The OS has most likely run out of buffers (rval: 4)
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_11799.trc (incident=123381):
ORA-00603: ORACLE server session terminated by fatal error
ORA-27504: IPC error creating OSD context
ORA-27300: OS system dependent operation:sendmsg failed with status: 105
ORA-27301: OS failure message: No buffer space available
ORA-27302: failure occurred at: sskgxpsnd2
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_123381/orcl2_ora_11799_i123381.trc
Fri Nov 24 09:11:42 2017
skgxpvfynet: mtype: 61 process 11801 failed because of a resource problem in the OS. The OS has most likely run out of buffers (rval: 4)
opiodr aborting process unknown ospid (11743) as a result of ORA-603
This happens due to less space available for network buffer reservation.
SOLUTION
1. On servers with High Physical Memory, the parameter vm.min_free_kbytes should be set in the order of 0.4% of total
Physical Memory. This helps in keeping a larger range of defragmented memory pages available for network buffers
reducing the probability of a low-buffer-space conditions.
*** For example, on a server which is having 256GB RAM, the parameter vm.min_free_kbytes should be set to 1048576 ***
vm.min_free_kbytes=0.4%*total Physical Memory
On NUMA Enabled Systems, the value of vm.min_free_kbytes should be multiplied by the number of NUMA nodes since the value
is to be split across all the nodes.
On NUMA Enabled Systems, the value of vm.min_free_kbytes = n * 0.4% of total Physical Memory. Here 'n' is the
number of NUMA nodes.
2. Additionally, the MTU value should be modified as below
#ifconfig lo mtu 16436
To make the change persistent over reboot add the following line in the file /etc/sysconfig/network-scripts/ifcfg-lo :
MTU=16436
Save the file and restart the network service to load the changes
#service network restart
当前服务器网卡本地回环的MTU默认设置是65536,按照MOS文档的方法修改这个设置。
ifconfig lo mtu 16436
但是重启后将恢复默认值,如果保证重启也生效,就需要修改网卡的配置文件。
vi /etc/sysconfig/network-scripts/ifcfg-lo
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
MTU=16436
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。