Process m000 died, see its trace file

数据库是11g的物理DG

standby database报错Process m000 died, see its trace file。

现在网上搜索的此错误,是资源耗尽不能连接,但是数据库仍然存活。

这种情况通过调整资源数解决,如processes达到上限

查看资源使用情况

select * from v$resource_limit;

RESOURCE_NAME                  CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION   LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
processes                                       50              54        150                  150
sessions                                        64              68        252                  252
enqueue_locks                                   35              39       3310                 3310
enqueue_resources                               17              17       1328            UNLIMITED
ges_procs                                        0               0          0                    0
ges_ress                                         0               0          0            UNLIMITED
ges_locks                                        0               0          0            UNLIMITED
ges_cache_ress                                   0               0          0            UNLIMITED
ges_reg_msgs                                     0               0          0            UNLIMITED
ges_big_msgs                                     0               0          0            UNLIMITED
ges_rsv_msgs                                     0               0          0                    0
gcs_resources                                    0               0          0                    0
gcs_shadows                                      0               0          0                    0
dml_locks                                        0               0       1108            UNLIMITED
temporary_table_locks                            0               0  UNLIMITED            UNLIMITED
transactions                                     5               5        277            UNLIMITED
branches                                         0               0        277            UNLIMITED
cmtcallbk                                        2               3        277            UNLIMITED
max_rollback_segments                           11              11        277                65535
sort_segment_locks                               0               1  UNLIMITED            UNLIMITED
k2q_locks                                        0               0        504            UNLIMITED
max_shared_servers                               1               1  UNLIMITED            UNLIMITED
parallel_max_servers                             0               0        135                 3600

增加processes

alter system set processes=200 scope=spfile;

然后重启数据库解决。

但是我的问题通过上述方法无法解决。

再次观察出问题实例,发现以下:

通过sqlplus登陆,进去是idle进程,只能杀死os进程来重启。

重启后又会自动关闭。

查看alert日志无信息

使用strace 命令跟踪smon进程显示

[[email protected] ~]$ strace -p 7351
Process 7351 attached
getrusage(RUSAGE_SELF, {ru_utime={0, 21996}, ru_stime={0, 14997}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 21996}, ru_stime={0, 14997}, ...}) = 0
semtimedop(15794179, {{18, -1, 0}}, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
semtimedop(15794179, {{18, -1, 0}}, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
semtimedop(15794179, {{18, -1, 0}}, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
semtimedop(15794179, {{18, -1, 0}}, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)

可以看出资源已经不可用,怀疑是内存的问题。

这里说明一下,该服务器是用作测试的,上面跑了若干个实例,单节点10g,11g,12c,11g standby,11g rac等5个实例。

使用ipcs -m查看

 ipcs -m
 ------ Shared Memory Segments --------
 key        shmid      owner      perms      bytes      nattch     status 
 0x1644d05c 28082176   oracle     600        945815552  28                
 0xb4a8f6f0 28147713   oracle     660        4096       0                 
 0xb3928380 28475394   oracle     640        14680064   82                
 0x00000000 28508163   oracle     640        868220928  82                
 0xb2f44a00 41123844   oracle     660        4096       0                 
 0x27bbfbde 3309577    oracle     755        1079228    1                               
 0x00000000 22708244   oracle     640        33554432   49                
 0x00000000 22741013   oracle     640        2449473536 49                
 0x0fc14ec0 22773782   oracle     640        2097152    49

可以看到上面的信号量有6个,排除0x00000000(这个信号量是派生出来的)

但是实例一共是5个,怀疑standby的内存段异常关闭,并且系统没有清理掉

并且上面有一个权限是755的oracle段,一般都是640的,怀疑是这个导致,并且

查看每个内存段是属于oracle哪个实例,可以通过oracle命令sysresv

[[email protected] ~]$ sysresv

IPC Resources for ORACLE_SID "orcl" :
Shared Memory:
ID              KEY
41385984        0xb2f44a00
Semaphores:
ID              KEY
16220162        0xb38b1d5c
Oracle Instance alive for sid "orcl"

同版本多实例可以指定实例

sysresv -l sid

删除共享内存段

[[email protected] trace]$ ipcrm --hlep
usage: ipcrm [ [-q msqid] [-m shmid] [-s semid]
          [-Q msgkey] [-M shmkey] [-S semkey] ... ]

或者sysresv -f sid删除

删除后重启stanby,一切正常。

时间: 2024-10-22 09:01:11

Process m000 died, see its trace file的相关文章

【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?

在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容? 參考原文: How to Find the Content of Trace File Generated for an Oracle Process after Removing the Trace File by Mistake at OS Level (Doc ID 805083.1) 适用于: Oracle Database - Enterprise Edition - Version

Oracle的跟踪文件(trace file)

跟踪文件通常都是因为通过DBMS_MONITOR(在Oracle Database 9i Relese 2)及更早版本中则是ALTER SESSION SET SQL_TRACE=TRUE启用了跟踪的结果,或者是通过10046事件使用扩展的跟踪工具生成的,如下 这些跟踪文件包含与诊断和性能有关的信息.它们对于了解数据库应用的内部工作有着非凡的意义.在一个正常运行的数据库中,你会经常看到这些跟踪文件,而且远比看到其他类型的跟踪文件多得多. 1 文件位置 不论是使用DBMS_MONITOR.SQL_

innobackupex:Error:xtrabackup child process has died at /usr/bin/innobackupex

使用innobackupex进行数据库备份,报如下错误:innobackupex --compress --parallel=4  --user=root  --password=yoon /export/backup/xtrabackup_56 version 2.1.9 for MySQL server 5.6.17 Linux (x86_64) (revision id: 744)xtrabackup: uses posix_fadvise().xtrabackup: cd to /var

EBS获取并发程序Trace File

http://blog.itpub.net/16832682/viewspace-1249765/ 最近因为项目上出现了PL/SQL性能的问题,因此需要对已经开发好的并发程序进行调优的工作.调优有个很重要的步骤就是获取并发程序的trace file,从而才能知道是哪一段SQL出现了问题.下面就针对如何获取并发程序的trace file做个归纳:1.在并发程序注册页面启动跟踪功能:2.提交并发,待并发跑完之后获取trace ID,可以用如下代码来完成: SELECT 'Request id: '

ksvcreate: Process(m000) creation failed

一测试服务器数据库(Oracle Database 10g Release 10.2.0.5.0 - 64bit Production)突然访问不了,检查发现数据库处于挂起模式(hang mode),检查告警日志,发现有"ksvcreate: Process(m000) creation failed","kkjcre1p: unable to spawn jobq slave process"之类的错误信息.具体如下所示: Sun Jan 17 09:56:05

利用Trace file查找程序发出的SQL

Trace file(追踪文件)是以trc为后续的文本文件,它记录了各种sql操作及所消耗的时 间等,根据trace文件我们就可以了解哪些sql导致了系统的性能瓶颈,进而采取恰当的 方式调优. 查询生产报表—所有制程的WIP: show parameter sql_trace; (如果value是false表示系统当前不会产生trace文件.采取如下操作让系统产生trace 文件.) alter session set sql_trace=true; EXEC DBMS_MONITOR.DATA

oracle中如何使用TKPROF命令查看Trace file

Trace file(追踪文件)是以trc为后续的文本文件,它记录了各种sql操作及所消耗的时间等,根据trace文件我们就可以了解哪些sql导致了系统的性能瓶颈,进而采取恰当的方式调优. 当我们操作oracle数据库,每次都会产生一个会话(session),session中记录了所有操作,这些操作都会记录在trace文件中. 如何使用TKPROF命令查看Trace file: SQL>alter session set sql_trace=true; SQL>select count(*)

error opening trace file: No such file or directory (2)

1.问题描述: 运行报错: 12-25 13:35:32.286: E/Trace(1202): error opening trace file: No such file or directory (2) 注:虽然报错,但程序仍然能运行..... 2.问题分析: (1)网上的一些说法: 很多人在编写Android代码的时候都会遇到这个错误,按照字面翻译是“没有这类文件或者是目录”很多人不解为什么系统会提示这样的错误呢?明明就有啊.其实系统是找不到文件或者是目录! 很多人在写了很多class文

ros rviz: Segmentation fault (core dumped) 与 [rviz -1] process has died [pid 10134, exit code -6]

1. 执行roslaunch 文件打开 某rviz文件.出现了例如以下的错误: [rviz-1] process has died [pid 10134, exit code -6] 2. 执行rosrun rviz rviz  正常,执行某公布图像的节点, 当用rviz加入 这一图像topic时,出现了例如以下的错误: Segmentation fault (core dumped) 我的问题出自解决问题QTerro:Size mismatch for type 'QPaintBufferCa