前言:
现时兄弟们对“linux oracle监听已经启动但是无法连接”大约比较着重,看官们都需要剖析一些“linux oracle监听已经启动但是无法连接”的相关内容。那么小编在网上搜集了一些关于“linux oracle监听已经启动但是无法连接””的相关文章,希望你们能喜欢,看官们快快来了解一下吧!一、【问题描述】
最近,在系统高峰期的时候,会提示如上的错误,致使无法连接到服务器上的数据库。
二、【分析过程】
1、首先判断是否由于监听配置不正确的原因导致?
系统在正常情况下都可以正常的使用,检查监听配置,完全正确,监听配置不正确的可能性排除.
2、是否因为数据库服务器处于共享服务器模式,是否会因为DISPATCHERS的数量太少,导致在高峰期的时候无法及时的分配客户机连接呢?
把ORACLE的DISPATCHER数量增加到3个,发现在系统高峰的时候还是会出现如此的问题,可确定不是DISPATCHER的问题。
3、判断是否PROCESS、SESSION数量设置的不够,导致ORACLE在高峰期的时候,没有足够的PROCESS对连接上来的客户服务进行分配?
增大PROCESS、SESSION的设置,这种情况基本能够得到解决,出现的频率已经很少,但在一定的情况下,还是会出现以上的提示。
4、在网上查找资料后发现,32位的WIN2003系统ORACLE单进程的限制为1.7G,对于超过的内存,ORACLE也无法使用,导致ORACLE在高峰期对客户机分配到一定数量的时候,导致ORACLE可用的内存不足,导致以上提示..此时,只有通过降低SGA的大小,以使得ORACLE有更多的内存可以对客户端进行分配.
经检查,现场的托管服务器环境为:32位的WIN32以及32位的ORACLE..直接导致ORACLE能够使用的内存不超过1.7G,对SGA的大小进行一定量的减少,系统基本不再出现无法分配的问题。
三、【解决途径】
1、首先修改ORACLE的PROCESS、SESSION数量
查看当前ORALCE PROCESS数量
SQL> show parameter process
查看当前ORALCE SESSION数量
SQL> show parameter session
修改PROCESS数量:
SQL> alter system set processes=1000 scope = spfile;
修改SESSION数量:
SQL> alter system set session=1105 scope = spfile;
注:sessions是个派生值,由processes的值决定,公式sessions=1.1*process + 5
2、降低系统的SGA大小
查看SGA的大小:
SQL> show parameter sga
同时修改sga_max_size和sga_target
SQL> alter system set sga_max_size=1000M scope = spfile;
SQL> alter system set sga_target=1000M scope = spfile;
重启ORACLE服务,问题基本解决。
四、【经验总结】
虽然通过增加PROCESS、SESSION数量并且降低了SGA的大小,使得整个托管的服务器的问题得到解决。但是,通过上面的问题分析可以知道,这只是治标不治本的处理方式,问题的最终原因还是因为32的WIN 2003操作系统+32位的ORACLE导致单进程最高内存不能超过1.7G导致的。所以在以后县区的数据加至现在的服务器中,必将导致这个问题的重现.
所以,最终的解决办法是,将数据库和服务器的操作系统全部升级至64位,或者将服务器使用UNIX的操作系统.
所以,在以后类似的托管服务器或者其他数据库服务器搭建时,一定要注意这个问题,如果客户提供的服务器为32位的,那么,一定要反应出这个问题.
标签: #linux oracle监听已经启动但是无法连接 #oracle数据库突然无法连接 #oracle远程连接无监听程序 #查看oracle32位的 #建立oracle数据库无法访问