|
|
 转到底部
|
|
文档内容
|
|
用途 |
|
|
排错步骤 |
| 这个消息意味着什么? |
| OS 配置检查 |
| 数据库配置检查 |
| 已知问题 |
| 已确认的 bug |
| Bug 13036685 |
| OS 相关的 Bug |
|
|
参考 |
适用于:
Oracle Database - Enterprise Edition - 版本 10.1.0.2 和更高版本本文档所含信息适用于所有平台
用途
本文可用于 alert log 中如下消息的诊断指南，请注意实际的进程类型和数字可能不同于本文列出的消息，因此本文适用于所有如下形式的消息：
kkjcre1p: unable to spawn %s slave process
Process %s died, see its trace file
ksvcreate: Process(%s) creation failed
您可能也会发现类似如下的消息：
本文也列出了一些能导致 ORA-445 错误的已知问题。
排错步骤
这个消息意味着什么?
这个消息表明我们在操作系统级别孵化一个新的进程来满足用户请求的时候失败了。该问题有多种原因。比较典型的情况是操作系统资源短缺或者操作系统配置不当，因此该问题应当从 OS 方面诊断。不过有些情况也可能是 oracle database 造成的。
默认的120秒的超时期限可以通过如下 event 动态延长，并且不需要重新启动：
alter system set events '10281 trace name context forever, level xxx';
-- 以上的 xxxxxx 是新指定的超时期限，单位是秒。
OS 配置检查
该错误通常由于 OS 资源短缺或者 OS 配置不当，典型的情况是 memory 或者 swap 不足导致无法创建一个新进程。请按如下的清单来检查 OS 的设置情况。
- 执行 Health Check 和 Validation(HCVE) 脚本来校验 OS 配置情况
检查资源相关的建议并且做出相应的改动。如下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 中的错误。
同时检查错误产生的 trace 文件。注意 trace 文件中问题发生时间的 'load verage' 和 memory 以及 swap 的状态。
- 用 OS Watcher 来监控资源使用情况
OS Watcher 是一个 Oracle 提供的工具，它允许您从 OS 的角度来监控系统：
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：
解决方案是关掉 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。这样可以避免或者减轻问题的发生。但是底层的原因仍然是操作系统资源短缺。
已知问题
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 自身有关.我们推荐您联合您的网络、存储、操作系统管理员来共同分析问题。