診斷指南 - Ksvcreate: Process(xxxx) Creation Failed / ORA-00445: Background Process "xxxx" Did Not Start After n Seconds (文件 ID 2178468.1)

轉到底部

文件內容

用途

排錯步驟

這個訊息意味著什麼?

OS 配置檢查

資料庫配置檢查

已知問題

已確認的 bug

Bug 13036685

OS 相關的 Bug

參考

適用於:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 和更高版本
本文件所含資訊適用於所有平臺

用途

本文可用於 alert log 中如下訊息的診斷指南，請注意實際的程式型別和數字可能不同於本文列出的訊息，因此本文適用於所有如下形式的訊息：

Process %s died, see its trace file
kkjcre1p: unable to spawn %s slave process

Process %s died, see its trace file
ksvcreate: Process(%s) creation failed

您可能也會發現類似如下的訊息：

ORA-00445: background process "J000" did not start after 120 seconds

本文也列出了一些能導致 ORA-445 錯誤的已知問題。

排錯步驟

這個訊息意味著什麼?

這個訊息表明我們在作業系統級別孵化一個新的程式來滿足使用者請求的時候失敗了。該問題有多種原因。比較典型的情況是作業系統資源短缺或者作業系統配置不當，因此該問題應當從 OS 方面診斷。不過有些情況也可能是 oracle database 造成的。

預設的120秒的超時期限可以透過如下 event 動態延長，並且不需要重新啟動：

$ sqlplus / as sysdba
alter system set events '10281 trace name context forever, level xxx';
-- 以上的 xxxxxx 是新指定的超時期限，單位是秒。

例如：alter system set events '10281 trace name context forever, level 300';

OS 配置檢查

該錯誤通常由於 OS 資源短缺或者 OS 配置不當，典型的情況是 memory 或者 swap 不足導致無法建立一個新程式。請按如下的清單來檢查 OS 的設定情況。

執行 Health Check 和 Validation(HCVE) 指令碼來校驗 OS 配置情況

Note 250262.1: RDA 4 - Health Check / Validation Engine Guide

檢查資源相關的建議並且做出相應的改動。如下2篇文章對更好的理解這些建議有幫助:

Note 169706.1: Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2)
Note 225349.1: Address Windowing Extensions (AWE) or VLM on Windows Platforms
（通常在記憶體大於 4G 的32位 windows 作業系統中，需要在 boot.ini 檔案中開啟 /3GB 開關）

檢查 user limitation(ulimit) 設定 (UNIX-only)

以 oracle 使用者 (或者 oracle software 的 owner)

# ulimit -a

最小滿足要求的值可以在如下文章中找到：

Note 169706.1: Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2)

校驗 SWAP space 配置

對於 swap space 配置的一些準則：

如果您有 1 ~ 2Gb 的實體記憶體, 那麼您需要配置1.5倍實體記憶體的 swap space。
對於 2 ~ 8Gb 的實體記憶體, swap space 的大小必須等於實體記憶體大小。
對於大於 8Gb 的實體記憶體, swap space 需要實體記憶體0.75倍的大小。

檢查 OS 錯誤和 trace 檔案

您可以檢查錯誤發生時間 OS Log 中的錯誤。

Note 1349613.1: How To Gather The OS Logs For Each Specific OS Platform

同時檢查錯誤產生的 trace 檔案。注意 trace 檔案中問題發生時間的 'load verage' 和 memory 以及 swap 的狀態。

用 OS Watcher 來監控資源使用情況

之前的步驟主要用來檢查 OS 配置方面的問題，但是問題也可能是臨時資源達到頂峰或者系統負載過高引發的。請在 alert.log 中檢查問題發生的時間週期，如果它總是發生在大約相同的時間段，那麼您遇到了臨時資源達到頂峰的情況。這通常發生在系統負載很高的情況下。

OS Watcher 是一個 Oracle 提供的工具，它允許您從 OS 的角度來監控系統：

Note 301137.1: OS Watcher User Guide
Note 946107.1: What Is The OSWATCHER (OSW) Effect On The Server Performance And What Are The Alternative Commands?

由於 Linux 的 Address Space Layout Randomization (ASLR)引發的問題

這個問題發生在 Redhat 5 和 Oracle 11.2.0.2 上.您可以透過如下命令檢查 ASLR 是否被使用：

# /sbin/sysctl -a | grep randomize
kernel.randomize_va_space = 1

如果以上引數被設定成非 0 的值，那麼 ASLR 正在被使用. 詳情參考如下 Note：

Note 1345364.1: ORA-00445: Background Process "xxxx" Did Not Start After 120 Seconds

解決方案是關掉 ASLR。

資料庫配置檢查

PGA_AGGREGATE_TARGET 被設定為 TRUE

引數 pga_aggregate_target 是一個數字型別的引數，不是 boolean 型別的引數，因此必須被設定成一個數字型的值方可正常工作。如果其被設定成了一個文字串，我們會嘗試將它轉換成一個有意義的值，但這個值可能對您的環境來說是不足的。

解決方案：正確地將 PGA_AGGREGATE_TARGET 設定成一個數字值。

PRE_PAGE_SGA 設定成 TRUE 或者在 PRE_PAGE_SGA 設定為 TRUE 的情況下

PRE_PAGE_SGA 會讓 Oracle 在例項啟動的時候讀取整個 SGA 到 active memory 中。作業系統 page table entries 需要對所有的 SGA page 做 prebuild。這個設定可能加長例項啟動所需的時間，但是它通常會減少啟動後達到最大效能容量所需的時間。PRE_PAGE_SGA 會增加程式啟動的時間，因為每個程式的啟動必須訪問所有的 SGA page，這可能導致 PMON 程式花更多的時間來啟動並且可能超出預設的120秒的 timeout 導致例項無法啟動。

設定 PRE_PAGE_SGA 為 TRUE 會增加程式啟動的時間，因為每個程式的啟動必須訪問所有的 SGA page，如果您的系統需要反覆的建立和銷燬程式，比如持續的 logon 和 logoff，這可能會帶來顯著的開銷。

檢查 PRE_PAGE_SGA 是否設定為 TRUE
--或者--
驗證產生的 trace 檔案是否出現 function: ksmprepage()

解決方案：將 PRE_PAGE_SGA 設定為 FALSE 可以避免以上程式碼執行，這樣 page 只會在需要的時候被訪問而不是在程式啟動的時候訪問所有的 pages。這樣可以避免或者減輕問題的發生。但是底層的原因仍然是作業系統資源短缺。

注意: 在 12.1.0.2 及以上版本上，pre_page_sga 的預設值已經被改為 true。Oracle 推薦在 12c 以下的版本中關閉 pre_page_sga。

已知問題

已確認的 bug

Bug 13036685

被關成 12830339 的重複bug

ORA-00445: BACKGROUND PROCESS "XXXX" DID NOT START AFTER 120 SECONDS

<<Bug 5583049: 'Ksvcreate: Process(m000) creation failed' after Standby Database Open Read Only Multiple Times

Note 418553.1: 'Ksvcreate: Process(m000) creation failed' after Standby Database Open Read Only Multiple Times

<< Bug 8426816: PMON may hang cleaning up a dead process (rare)

Note 1233079.1:Ksvcreate: Process(M001) Creation Failed , Database hang

OS 相關的 Bug

如下是被確認為 OS 問題的 Bug 列表。

Unpublished Bug 8336987: TB:SH:ORA-00445: BACKGROUND PROCESS "PZ99" DID NOT START AFTER 120 SECONDS
---> Platform 226 - Linux x86-64
程式長時間處於 D 狀態，例如處於 uninterruptible state in the kernel 的狀態，這是一個 Linux ext3 檔案系統上的已知問題，當有很多 I/O 活動的時候，檔案系統必須 flush out 它的 journal，此時其他的 I/O 請求被凍結了。如果您願意，您可以嘗試改變您的 ext3 檔案系統的 mount option 讓其包含 -o data=writeback 然後觀察問題是否重現。

Unpublished Bug 7562673: FAILED IN SPAWNING MMON SLAVES AND FLOODING OF MMON TRACES IN AQ TEST
--> Status 92 - Closed, Not a Bug
WARNING: Slow process spawn detected for OS id=4260, M000 The process exec took more than 133 secs.
原因: oracle 執行檔案在遠端主機上。網路問題會延遲可執行檔案的載入從而延遲了程式的執行，解決辦法是將 oracle image/oracle home 複製到本地磁碟。

Unpublished Bug 7377880: STARETL: ORA-00445: BACKGROUND PROCESS "M000" DID NOT START AFTER 120 SECONDS
--> Status 32 - Not a Bug
問題看起來是主機上執行著過多的活動應用，解決辦法是關閉一些活動應用。

Unpublished Bug 9866293: GE+RAC: INSTANCE CRASH BECAUSE SMON DIED WITH ORA-00445
--> Status 92 - Closed, Not a Bug
在負載很高的系統上程式的啟動是非常耗時的。對於高負荷、或者高網路延遲並且 oracle image 放在遠端主機上的情況，可能會有很長的 fork/exec 時間。在這種特定情況下，往往 ps 和 gdb 在dump 被孵化程式的診斷資訊上也會發生超時，這是表明系統負載高或者網路延遲的一個很好證據。

Unpublished Bug 9543620: SQL EXEC PART:ORA-00445: BACKGROUND PROCESS "P059" DID NOT START AFTER 120 SECONDS
--> Status 92 - Closed, Not a Bug
這僅僅是一個系統負載相關的問題。ps 和 gdb 在提取被孵化程式的診斷資訊時超時了，如果 oracle image 或者依賴的 library 在遠端主機上，通常意味著 NFS 延遲，如果放在本地磁碟上，那麼一般是由於 disk 延遲引發。

目前來說,這些 bug 所定位的可能原因有：
1. 主機上有過多的活動。
2. NFS 延遲。
3. 磁碟延遲（影響 I/O）。
4. 網路延遲。

這些是 ORA-445 的4個可能原因. 這些原因沒有一個與 RDBMS 自身有關.我們推薦您聯合您的網路、儲存、作業系統管理員來共同分析問題。

Ksvcreate:Process(xx) Creation Failed/ORA-00445:Background Process "xx"

適用於:

用途

排錯步驟

這個訊息意味著什麼?

OS 配置檢查

資料庫配置檢查

已知問題

已確認的 bug

Bug 13036685

OS 相關的 Bug

相關文章