转帖ORA-27300: OS system dependent operation:fork failed with status: 12

os : aix 5.3 + hacmp 5.4.1
db : 10.2.0. 3 rac

alert.log
Mon Sep  1 03:49:17 2008
Process startup failed, error stack:
Mon Sep  1 03:49:17 2008
Errors in file /app/oracle/admin/racdb/bdump/racdb1_psp0_479298.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
Mon Sep  1 03:49:18 2008
Process PZ96 died, see its trace file


trace.log
Redo thread mounted by this instance: 1
Oracle process number: 4
Unix process pid: 479298, image: oracle@racdb1 (PSP0)

*** SERVICE NAME ORA-27300: OS system dependent operation:fork failed with status: 12 - 无法无天耗 - 无法无天耗的移动U盘SYS$BACKGROUND) 2008-09-01 03:46:42.179
*** SESSION ID ORA-27300: OS system dependent operation:fork failed with status: 12 - 无法无天耗 - 无法无天耗的移动U盘553.1) 2008-09-01 03:46:42.179
*** 2008-09-01 03:46:42.179
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
*** 2008-09-01 03:47:41.144
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
*** 2008-09-01 03:49:15.684

分析:
   1. 发现alert.log 发现很多ORA-27301: OS failure message: Not enough space 以为是 磁盘空间不足, 检查磁盘发现没有满.
   2. 检查trace.log , 发现是process PSP0 启动不了,  process-spawner (PSP0): spawns Oracle processes , 为oracle主要后台进程.
   3. crs_stat -t  发现 数据库实例1已经down 掉,各个rac1资源已经offline..说明PSP0已经启动不了. 由此可知 ORA-27301: OS failure message: Not enough space 可能是由于系统内存不足的原因.
   4. metalink 查询. Doc ID:  Note:560309.1
      正是由于ram/swap 不足导致, 建议设置.
      RAM                              SWAP
      1GB to 2GB                   1.5 times RAM
      > 2GB and <= 8GB             1 times RAM
      > 8GB                      .75 times RAM
     而当前aix 系统的ram:8G, swap: 4G 可知远小于需要设置的swap.
   5. 查到原因 ,修改就很简单了. 利用smitty chps 修改系统的swap 即可. 然后利用 lsps -a 或者topas 查看swap .
   6. 系统运行3.4个月一直很正常,修改swap 以后需要继续观察.

附录: Doc ID:  Note:560309.1   
Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3
This problem can occur on any platform.

Symptoms
The database can not start up due to the following errors:

*** SERVICE NAME ORA-27300: OS system dependent operation:fork failed with status: 12 - 无法无天耗 - 无法无天耗的移动U盘SYS$BACKGROUND) 2008-03-24 17:02:34.855
*** SESSION ID ORA-27300: OS system dependent operation:fork failed with status: 12 - 无法无天耗 - 无法无天耗的移动U盘1104.1) 2008-03-24 17:02:34.855
*** 2008-03-24 17:02:34.855
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
*** 2008-03-24 17:02:38.158
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3

Cause
This issue is mainly caused by lack of memory / swap. Checking the memory configuration on the server, we have found the following:

Total Physical Memory 38912 MB
Swap: Max Size 17664 MiB
So, RAM is 38 GB, SWAP space is only 17 GB

Solution
-We should increase the server swap space (paging space) . The general rule of thumb is that swap space should be:
RAM                              SWAP
1GB to 2GB                   1.5 times RAM
> 2GB and <= 8GB          1 times RAM
> 8GB                            .75 times RAM

So in our case, the recommended swap space is @28 GB .

We can also try to increase physical memory, if possible.

We should also check the ulimits for Oracle user.:
memory - unlimited
data       - unlimited
cpu        - unlimited
stack      - at least 32768
nofile      - OS dependent

We should also check memory parameters in the pfile/spfile that add more load to the memory consumption on the server.  In our issue, we found these settings which added more pressure to the memory:
-lock_sga=true
-large db_keep_cache_size=14000m.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12778571/viewspace-703997/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/12778571/viewspace-703997/

### 解决 ORA-01034 和 ORA-27101 错误的方法 当遇到 `ORA-01034: ORACLE not available` 和 `ORA-27101: shared memory realm does not exist` 的错误时,通常意味着 Oracle 实例未能成功启动或未正常运行。以下是详细的排查和解决步骤: #### 1. 检查 Oracle 监听器和服务状态 确保 Oracle 监听器已启动并正在运行。可以通过命令行工具执行以下操作来启动监听器: ```bash lsnrctl start ``` 这一步骤可以确认监听器是否处于活动状态[^1]。 #### 2. 验证 Oracle SID 设置 确认环境变量中的 Oracle SID 是否正确指向目标数据库实例。如果不确定具体的 SID 名称,可以在安装目录下的配置文件中查找相关信息。 #### 3. 使用 OS 身份验证方式尝试启动数据库 有时即使服务看似已经开启,实际的数据库实例可能并未完全初始化。此时可尝试使用操作系统级别的权限来进行手动启动: ```bash sqlplus / as sysdba startup exit; ``` 上述 SQL*Plus 命令允许管理员绕过常规的身份认证流程直接访问并激活数据库引擎[^3]。 #### 4. 审阅日志文件获取更多信息 对于更深入的问题诊断,建议查阅位于 `$ORACLE_HOME/diag/rdbms/<dbname>/<instance_name>/trace/alert_<instance_name>.log` 下的日志条目。这些记录能够提供关于最近一次失败的具体原因说明[^4]。 #### 5. 排除资源竞争可能性 如果有其他应用程序占用了过多系统资源,则可能导致 Oracle 进程无法获得足够的内存空间完成加载过程。利用 Linux 自带的任务管理指令监控服务器上的活跃进程及其消耗情况可以帮助识别潜在冲突源: ```bash ps -eo user,pid,ppid,%mem,%cpu,comm --sort=-%mem | head ``` 这条命令会列出按内存占用量排序后的前十位程序列表[^5]。 通过遵循以上指南应该能有效处理大多数情况下由 ORA-01034 及其关联编号所引发的技术难题。不过需要注意的是,在实施任何更改之前最好先备份现有设置以防万一;另外针对特定版本特性也可能存在差异化的修复路径,请参照官方文档寻求最权威指导。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值