數(shù)據(jù)庫是11g的物理DG
standby database報錯Process m000 died, see its trace file。
現(xiàn)在網上搜索的此錯誤，是資源耗盡不能連接，但是數(shù)據(jù)庫仍然存活。
這種情況通過調整資源數(shù)解決，如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;然后重啟數(shù)據(jù)庫解決。
但是我的問題通過上述方法無法解決。
再次觀察出問題實例，發(fā)現(xiàn)以下：
通過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)可以看出資源已經不可用，懷疑是內存的問題。
這里說明一下，該服務器是用作測試的，上面跑了若干個實例，單節(jié)點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的內存段異常關閉，并且系統(tǒng)沒有清理掉
并且上面有一個權限是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，一切正常。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
