linux kernel引发的oracle问题及解决

时间:2022-05-04
本文章向大家介绍linux kernel引发的oracle问题及解决,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

最近测试环境的连接数老是不够用,session/process 都相应的从5000提到了8000,但还是不够,而且还是不断有新环境需要增加。最后根据评估,session数需要50000左右

根据粗略的计算来说,process也需要调整,按照如下的公式.

sessions=(1.1*process+5)

把semmns做了大幅度的调整,从32000调到了70000

> cat /proc/sys/kernel/sem
250     32000   100     256
> sysctl -a |grep sem
kernel.sem = 250        70000   100     256 

第二天收到邮件说变更已经部上去了。说Process只调到了16000,当时看到邮件也没在意。

以下是监控的指标图,几分钟抓一个session报告。生成的图表如下。

开始两天,发现有了很大的改进,连接能够正常关闭,而且session数不到7000的样子。根据反馈没发现连接数的问题。

过了两天发现session数到8000以上就开始很吃力了。而且会时不时的有一些连接不上的情况。我写了个脚本,抓session快照的时候也有时候连不上库。

查看alert和listener日志,有以下的错误信息。

-->from Listener.log
03-DEC-2013 12:43:41 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=testwrk34))(sid=TEST)) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.19.192.41)(PORT=56631)) * establish * TEST * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12536: TNS:operation would block
  TNS-12560: TNS:protocol adapter error
   TNS-00506: Operation would block
Linux Error: 11: Resource temporarily unavailable
-->from DB alert log
Errors in file /opt/app/oracle/aaa/admin/TEST/diag/rdbms/TEST/TEST/trace/TEST_psp0_30562.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5
Tue Dec 03 12:38:05 2013

在MOS上查看相关的信息,说是nproc的配置太低了,无法分配进程了。

但是查看nproc的情况,感觉没什么问题。

*               soft    nproc   32768
*               hard    nproc   65536

我就有些糊涂了。查看机器上其它的实例进程数,加起来都不到200个。

继续查看session的情况。最后反复验证,确认session数到8000的时候就开始有问题了。就开始琢磨nproc为什么没生效。

想到几天前的邮件,一查看,终于发现了端倪。

他们当时起库的时候,发现已经报了proc的错误,当调整process的时候,库直接起不来了。

SQL> startup
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semids_per_proc failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: sskgpwcr2
ORA-27303: additional information: semids = 264, maxprocs = 45000
SQL> exit                                             

起库的哥们已查看nproc的配置,db process设置为16000的时候库才能起来,然后他就直接设置为了16000,然后还有一些其他的问题,直接顺手解决了。

test2 @test1:/root > grep nproc /etc/security/limits.conf 
#        - nproc - max number of processes
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
*               soft    nproc   8192
*               hard    nproc   16384
SQL> startup
ORA-04031: unable to allocate 15193312 bytes of shared memory ("shared pool","unknown object","sga heap(3,0)","KEWS sesstat values")
SQL>
Tunning sga 
*.sga_max_size= 6442450944  ==> 8442450944
*.sga_target=6442450944     ==> 8442450944
SQL> startup
ORACLE instance started.
Total System Global Area 8417955840 bytes
Fixed Size                  2233168 bytes
Variable Size            3321892016 bytes
Database Buffers         5066719232 bytes
Redo Buffers               27111424 bytes
Database mounted.
Database opened.

查看邮件的情况,才发现nproc是在第二天早晨被unix team从8000调到16000的。问题的原因就找到了。

kernel的变更没有生效,只能稍候处理。

这个问题的定位确实有些曲折,希望在操作的时候保留日志之类的东西,这样诊断问题会有根据。