Processes引數設定引起的故障解決一例

 

很多情況下，我們是不推薦修改Oracle預設的引數（特別是一些隱含引數）。Oracle的預設值引數可以適應大部分情況，但是一些時候還是要注意進行適當的修改，來適應實際開發的需要。

 

今天進行資料庫例行檢查，發現在alert_log中出現報錯資訊。

 

--Alert Log相關部分

Tue May 03 14:44:25 2011

ORA-00020: maximum number of processes 150 exceeded

ORA-20 errors will not be written to the alert log for

 the next minute. Please look at trace files to see all

 the ORA-20 errors.

Tue May 03 14:45:24 2011

Process J001 submission failed with error = 20

kkjcre1p: unable to spawn jobq slave process

Errors in file /nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_cjq0_12320848.trc:

 

 

這個程式碼片段報錯兩個。首先在下午2點44分25秒的時候，報錯ORA-00020，提示說當前的process數量超過了約定的150個。其次是在一分鐘之後，報錯說後臺程式J001不能連線資料庫，別資料庫例項剔除。

 

檢查對應生成的trace檔案，可以看到。

 

--Trace File內容

Trace file /nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_cjq0_12320848.trc

 

（篇幅原因，有省略…）

*** 2011-05-03 14:45:24.033

ORA-00020: No more process state objects available

Setting Resource Manager plan SCHEDULER[0x3004]:DEFAULT_MAINTENANCE_PLAN via scheduler window

 

*** 2011-05-03 22:00:00.057

Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter

 

 

在trace檔案的反映情況上，在開始一個資源管理作業的時候，啟動的J001程式。在這個過程中，因為不能建立新的程式，所以報錯。

 

從時間和關聯上，可以認定兩個錯誤是一個原因。最開始報錯的Ora-20錯誤是原因，而之後的J001程式被剔除是結果。

 

檢查20錯誤的資訊。

 

[oracle@oracle11g ~]$ oerr ora 00020

00020, 00000, "maximum number of processes (%s) exceeded"

// *Cause:  All process state objects are in use.

// *Action: Increase the value of the PROCESSES initialization parameter.

 

 

 

錯誤提示告訴我們，當系統中程式的數量超過了設定引數Processes的值時，就會出現20錯誤，同時將超出限額的程式踢出系統。於是乎J001作業程式就被剔除了程式，形成了之後的報錯。

 

當前系統中processes的取值是多少呢？

 

 

SQL> show parameter processes;

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

aq_tm_processes                      integer     0

db_writer_processes                  integer     1

gcs_server_processes                 integer     0

global_txn_processes                 integer     1

job_queue_processes                  integer     1000

log_archive_max_processes            integer     4

processes                            integer     150

 

 

此時採用的是預設值150。這樣問題就清楚了，當進行某些前臺操作的時候，系統中程式的個數就會同時增加到一個峰值，超過我們通常的150限額。

 

處理的方法也比較簡單，就是將processes引數設定為一個比較大的取值，就不會出現這個問題了。

 

SQL> alter system set processes=400 scope=spfile;

 

System altered

 

 

注意，這個引數是不能online修改，要求必須重新啟動資料庫伺服器。

 

後記：之後經過和開發團隊溝通，確定了問題的原因。通常應用所形成的連線數目比較少，但是在使用一種資料庫單元測試工具，進行批次資料匯入的時候，就會同時開啟多個process連線進行匯入。當多個組同時進行單元測試的時候，會形成一個連線峰值，超過預設的processes上限。

 

經驗還是：預設值不可全信，要仔細衡量才好。