ORA-27300,ORA-27301,ORA-27302

来源：互联网发布：淘宝市场调查问卷编辑：程序博客网时间：2024/05/21 17:03

运维工程师在一台IBM P750（AIX6.1）上部署了一套oracle（未建库），让我把商用的某库同其做一个DG容灾。我按正常步骤部署了DG。

1.在备库开始日志恢复

alter database recover managed standby database using current logfile disconnect;

2.查看备库是否正常接收日志

select process,client_process,sequence#,status from v$managed_standby;

--正常接收日志

3.查看备库是否正常应用日志

select THREAD#,SEQUENCE#,ARCHIVED,APPLIED,DELETED,STATUS from v$archived_log order by 1,2;

--正常应用日志

但是我在备库的alert日志里发现有如下报错

报错1

Process startup failed, error stack:Errors in file /apps/oracle/diag/rdbms/egbi/egbi2/trace/egbi2_psp0_29949962.trc:ORA-27300: OS system dependent operation:fork failed with status: 2ORA-27301: OS failure message: No such file or directoryORA-27302: failure occurred at: skgpspawn5

报错2

Process startup failed, error stack:Errors in file /apps/oracle/diag/rdbms/egbi/egbi2/trace/egbi2_psp0_29949962.trc:ORA-27300: OS system dependent operation:fork failed with status: 11ORA-27301: OS failure message: Resource temporarily unavailableORA-27302: failure occurred at: skgpspawn3

查看mos后发现是操作系统参数maxuproc设置不正确导致（具体见Doc ID 1125188.1和Doc ID 392006.1），该参数默认只有128，该参数决定了每个操作系统用户允许连接的最大进程数，该参数不足时alert日志中会报如上错误。

正常在装rac时这些参数我们都会提前检查，并设为oracle要求的值（要求值为16384），这里可能是运维根本没有检查该参数

检查该参数

lsattr -E -l sys0 -a maxuproc

root@egisbdb1:/#lsattr -E -l sys0 -a maxuproc
maxuproc 128 Maximum number of PROCESSES allowed per user True

修改该参数（增大maxuproc参数无需重启操作系统可以直接生效，如果是减小该值则需重启操作系统后生效）

chdev -l sys0 -a maxuproc=16384

修改后alert日志中不再报该错误

本文出自 “技术” 博客，请务必保留此出处http://589985.blog.51cto.com/1609992/1382435

0 0