数据库是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进程显示
[oracle@rac2 ~]$ 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
[oracle@rac2 ~]$ 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
删除共享内存段
[oracle@rac2 trace]$ ipcrm --hlep
usage: ipcrm [ [-q msqid] [-m shmid] [-s semid]
[-Q msgkey] [-M shmkey] [-S semkey] ... ]
或者sysresv -f sid删除
删除后重启stanby,一切正常。