系统上线,一下子有几百人用,数据库出现异常
ORA-12516: TNS: 监听程序找不到符合协议堆栈要求的可用处理程
一开始以为数据库出了问题呢。
使用sqlplus连接以后,查看当前会话数、processes和sessions值,发现session数和2个参数的值已经非常逼近
SQL> select count(*) from v$session;
COUNT(*)---------- 88
SQL> show parameter processes
NAME TYPE VALUE
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 100
SQL> show parameter sessions
NAME TYPE VALUE
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
logmnr_max_persistent_sessions integer 1
sessions integer 110
shared_server_sessions integer
2、修改processes和sessions值
SQL> alter system set processes=300 scope=spfile; 系统已更改。
SQL> alter system set sessions=335 scope=spfile; 系统已更改。
3、查看processes和sessions参数,但更改并未生效
SQL> show parameter processes NAME TYPE VALUE db_writer_processes integer 1 gcs_server_processes integer 0 job_queue_processes integer 10 log_archive_max_processes integer 2 processes integer 100 SQL> show parameter sessions NAME TYPE VALUE license_max_sessions integer 0 license_sessions_warning integer 0 logmnr_max_persistent_sessions integer 1 sessions integer 110 shared_server_sessions integer
4、重启数据库,使更改生效 SQL> shutdown SQL> startup SQL> show parameter processes NAME TYPE VALUE db_writer_processes integer 1 gcs_server_processes integer 0 job_queue_processes integer 10 log_archive_max_processes integer 2 processes integer 300 SQL> show parameter sessions NAME TYPE VALUE java_soft_sessionspace_limit integer 0 license_max_sessions integer 0 license_sessions_warning integer 0 logmnr_max_persistent_sessions integer 1 sessions integer 335 shared_server_sessions integer
其他:
ORACLE的连接数(sessions)与其参数文件中的进程数(process)有关,它们的关系如下:
sessions=(1.1*process+5)
但是我们增加process数时,往往数据库不能启动了。这因为我们还漏调了一个unix系统参数:它是/etc/proc/kernel 中semmns,这是unix系统的信号量参数。每个process会占用一个信号量。semmns调整后,需要重新启动unix操作系统,参数才能生效。不过它的大小会受制于硬件的内存或ORACLE SGA。范围可从200——2000不等。
上面说的是unix,在RHEL5中, 就修改/etc/sysctl.conf里面的信号量:
kernel.sem = 2000 32000 100 128 //传说中参数依次为SEMMSL(每个用户拥有信号量最大数);SEMMNS(系统信号量最大数);SEMOPM(每次semopm系统调用操作数);SEMMNI(系统信号量级数最大数).
所以要修改的是第二个参数
semmns的计算公式为: SEMMNS>processes+instance_processes+system
processes=数据库参数processes的值
instance_processes=5(smon,pmon,dbwr,lgwr,arch)
system=系统所占用信号量。系统所占用信号量可用下列命令查出:
#ipcs -s
其中列NSEMS显示系统已占用信号量。
其它一些跟连接有关的参数,如 licence_max_sessions, licence_sessions_warning 等默认设置都为零,也就是没有限制。我们可以放心大胆地使用数据库了。
分享到:
相关推荐
kettle连接oracle12C--报错ORA-28040 没有匹配的验证协议
Oracle报错ORA-12516 TNS:listener could not find available handler with matching protocol stack
oracle启动失败,ORA-00702报错,windows,linux系统下解决办法
1.Navicat OCI引⽤位置可以从Navicat菜单栏“⼯具”-》“选项”-》环境-》“OCI”中找到 2.Navicat替换的⽂件
用oracle数据库新建连接时遇到ora-12505,此问题解决后又出现ora-12519错误,郁闷的半天,经过一番折腾问题解决,下面小编把我的两种解决方案分享给大家,仅供参考。 解决方案一: 今天工作时在新建连接的时候遇到...
错误描述:oracle远程连接服务器出现 ORA-12170 TNS:连接超时 错误检查:有很多是oracle自身安装的问题,但是我这里服务器配置正常,监听正常,服务正常,远程可以ping通服务器。 这里主要是防火墙问题,解决办法: ...
客户端进行连接的时候,系统不定期出现ora-12520,ora-12516的连接问题, 问题解决方案建议: 1、增加process和session的连接数。 2、检查连接的应用,是不是有没有释放的连接。 3、将修改参数local_listener中的vip为...
oracle数据库优化之后,报错报错“ora-00838”的处理方法
Oracle 11gr2连Oracle 19c 报ORA-28040 ORA-01017解决方法
oracle报错ora-12541:TNS无监听程序
Oracle数据库报错ORA-00904: 标识符无效问题解决办法,有可能是字段名或者表名写错了,也有可能是
关于oracle做恢复操作时启动数据库报错,通常是由于rman做了恢复操作导致的报错. 通过继续执行恢复指令而恢复数据库,成功启动数据库.
解决navicat报错ORA-12737(OCI报错) 解决navicat报错ORA-12737(OCI报错)
oracledb_exporter 是prometheus 的一个对Oracle监控的Exporter , Prometheus+Grafana 对Oracle实现监控
使用工具IMPDP导入数据时ORA-39002、ORA-39070错误排查。使用工具IMPDP导入数据时ORA-39002、ORA-39070错误排查 使用工具IMPDP导入数据时ORA-39002、ORA-39070错误排查
ORACLE的ora-12505报错以及连接问题的解决
NULL 博文链接:https://rongren.iteye.com/blog/1886071
CLOB字段类型报错 ORA-01704:文字字符串过长的解决
ora报错分类及解决方案