Oracle启动后 隔几天就会莫名其妙自动挂掉 每次看alert日志都是 terminating the instance due to error 490报错导致
请问哪位专家知道原因？？
PMON (ospid: 28705): terminating the instance due to error 490
Sun Oct 23 08:05:04 2022
System state dump requested by (instance=1, osid=28705 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /data/oracle/app/oracle/diag/rdbms/lcfa/lcfa/trace/lcfa_diag_28715_20221023080504.trc
Dumping diagnostic data in directory=[cdmp_20221023080504], requested by (instance=1, osid=28705 (PMON)), summary=[abnormal instance termination].
Instance terminated by PMON, pid = 28705
PMON (ospid: 16817): terminating the instance due to error 490
Sun Oct 30 08:05:04 2022
System state dump requested by (instance=1, osid=16817 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /data/oracle/app/oracle/diag/rdbms/lcfa/lcfa/trace/lcfa_diag_16829_20221030080504.trc
Dumping diagnostic data in directory=[cdmp_20221030080504], requested by (instance=1, osid=16817 (PMON)), summary=[abnormal instance termination].
Instance terminated by PMON, pid = 16817
PSP0進程在10g中開始引入，主要功能是啟動其他的Oracle進程。這個進程也是一個十分關鍵的核心進程，一旦出現問題，將導致數據庫實例故障。
Errors in file /opt/oracle/admin/orcl/bdump/orcl_pmon_32149.trc:
ORA-00490: PSP process terminated with error
Mon Sep 26 14:14:55 2011
PMON: terminating Instance due to error 490
Instance terminated by PMON, pid = 32149
至此，我們已經看到了八個關鍵核心進程。
下面我們來看一下cjq0進程。它是一個任務隊列的調度進程，負責從job$表中找到需要執行的任務，並分配job進程執行，如果job進程不足，會自動產生新的job進程（在job_queue_processes參數限制范圍內）。下面來看看殺掉這個進程會有什么結果。
Mon Sep 26 09:07:18 2011
Restarting dead background process CJQ0
Mon Sep 26 09:07:18 2011
CJQ0 started with pid=25, OS id=12226
可以看出cjq進程如果被殺掉，cjq0進程會被重啟。
既然cjq0都可以殺，那么cjq0產生的JXXX進程我們就不用做實驗了，肯定是能殺的了。其實老白也是經常殺掉JOB進程的，在某些系統中，經常會有一些JOB進程占用大量的系統資源，從而導致數據庫性能問題。這時，為了恢復OLTP應用的性能，殺掉JOB進程是最簡單的方法。不過在殺掉JOB進程之前一定要做仔細的分析，如果JOB進程中正在做一個數據量很大的大型修改事務，那么殺掉這個JOB，可能會導致大量的回滾操作，從而對系統性能產生更為不利的影響。
下一個我們要來研究的是arch進程，在Oracle 10g中，arch進程一般是arc0, arc1，...。我們來殺掉一個arch進程，看看會有什么結果。
Mon Sep 26 09:56:27 2011
ARCH: Detected ARCH process failure
ARCH: STARTING ARCH PROCESSES
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0 started with pid=16, OS id=6646
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
可以看出，arc0進程被殺掉后，會自動重啟，而數據庫實例沒有發生故障。因此arch進程如果出現故障，在必要情況下，我們是可以殺掉該進程的。
下面我們來看一下QMON進程，QMON進程是隊列監控同步進程（QMNC）和隊列服務進程（QXXX）的統稱。
Mon Sep 26 09:10:46 2011
Restarting dead background process CJQ0
Mon Sep 26 09:10:46 2011
CJQ0 started with pid=25, OS id=12347
從上面的測試可以看出，QMON進程是可以殺的，殺掉QMON進程的后果是相關進程重啟。
MMON和M000是Oracle 10g引入的新后台進程，MMON是管理監控進程，M000是MMON的SLAVE進程，協助MMON進程工作。如果這些進程出現故障會有什么結果呢?
Mon Sep 26 10:11:39 2011
Restarting dead background process MMON
MMON started with pid=11, OS id=11860
MMON進程是可以自動重啟的，當然也在可殺范圍內了。
類似的MMNL進程也是AWR新增的進程，主要作用是將AWR數據從內存中刷新到表中。這個進程如果被殺掉也是可以自動重啟的。在這里我們就不一一列出實驗數據了：
DISPATCHER進程DXXX：如果被殺掉，ALERT會報錯，不會導致實例宕機，根據需要進行重啟。
共享服務進程SXXX：如果被殺掉，不會導致實例宕機，根據需要進行重啟。
並行進程PXXX/PZXX：並行進程，如果被殺掉，不會導致實例宕機，進程根據需要進行重啟。
高級隊列從屬進程QXXX：如果被殺掉，不會導致實例宕機，進程根據需要進行重啟。如果存在高級隊列操作，殺掉此類進程要十分慎重。
Oracle 10g引入了ASM后，也新增了一些和ASM有關的進程。首先ASM實例具有一系列的后台進程，其次，RDBMS為了訪問ASM也新增了一系列的后台進程。我們來看看ASM實例的后台進程。
ASM實例也擁有類似RDBMS實例的核心進程，另外ASM實例新增了一些其他的后台進程，下面我們做一個簡單的了解。
ASMB：當數據庫實例使用SPFILE時啟動的ASM后台進程。這個進程是十分關鍵的，一旦出現故障將導致ASM實例宕機。
RBAL：DISKGROUP做rebalance的后台進程，該進程一旦有故障將導致ASM實例宕掉。
DBW0：DB writes，和RDBMS的DB WRITER類似，不過是將ASM CACHE中的數據寫入磁盤，該進程一旦有問題將導致ASM實例故障。
SMON：恢復進程，類似於RDBMS的SMON進程，處理DISKGROUP的恢復操作，一旦有問題將導致ASM實例故障。
CKPT：Checkpoint進程，類似於RDBMS的CKPT進程，一旦有問題將導致ASM實例故障。
PSP0：啟動其他ASM實例進程的進程，一旦有問題將導致ASM實例故障。
GMON：群組監控進程，用於節點監控和狀態表的維護，一旦有問題將導致ASM實例故障。
ora_ASMB：特殊的ASM前台進程。
KATE：Konductor or ASM Temporary Errands，用來執行ONLINE磁盤的臨時任務進程。
VKTM：管理快速計時器的進程。
PING：計量網絡延時的進程。
DIA?：類似於數據庫的diag進程。
DIAG：類似於數據庫的diag進程。
LGWR：Log writer, 和數據庫類似，處理磁盤組的REDO信息。
LMON：鎖監控進程，類似於數據庫的LMON進程。
LMS?：鎖監控SLAVE進程，類似於數據庫的LMS進程。
MMAN：SGA自動調整進程，類似於數據庫的MMAN。
b???：用於離線磁盤的SLAVE進程。
x???：磁盤組重配置后刪除磁盤的SALVE進程。
pz??：用於GLOBAL VIEW查詢的並行SLAVE進程。
Oracle 11g在后台進程方面有了較多的改變，這種改變有時候甚至讓我們感覺Oracle數據庫變陌生了，需要重新認識Oracle 11g的后台進程結構。下面是新增的后台進程。
ACMS（atomic controlfile to memory service），這是每個實例都有的代理進程，在RAC環境下，對控制進程事務的提交和回退起到輔助作用。
DBRM（database resource manager），用於資源管理和資源計划相關的任務。
DIA0 （diagnosability process 0），目前只有“0”，沒有其他進程，用於數據庫的掛起檢測和死鎖處理。
DIAG（diagnosability），進行診斷DUMP，執行全局oradebug命令。
EMNC（event monitor coordinator），用於數據庫事件管理和發布的進程。
FBDA（flashback data archiver process），閃回區歸檔進程，用於將跟蹤表的歷史記錄寫入歸檔日志，管理閃回數據區的空間。
GTX0-j （global transaction），在RAC環境中為XA全局事務提供透明的服務，只在RAC環境中出現。系統會根據XA事務的負載情況確定啟動幾個這種進程。
KATE，當磁盤離線時代理ASM metadata的I/O。
MARK，當寫入一個離線磁盤出錯時記錄這個ALLOCATION UNIT為過期狀態。
SMCO（space management coordinator），執行空間管理有關的作業，比如空間預分配和空間回收。可以動態生成Wnnn SLAVE進程。
VKTM（virtual keeper of time），每秒更新一次時間，在高優先級情況下可以提供20毫秒的基准時間計數。
DSKM（slave diskmon），用於RDBMS和ASM實例之間的聯系通道。Master Diskmon守護進程處理I/O隔離信息，I/O資源管理計划將Transaction Commit Cache信息傳輸到SAGE存儲，也用來在節點和SAGE存儲服務器之間實現skgxp ANT協議。如果沒有配置SAGE存儲，diskmon slave進程會在實例啟動后自動關閉。