网上倒是有篇帖子问题类似,而且解决了。http://www.erp100.com/thread-6248-1-1.html不过它是10g、Windows版的。他的问题是:因为没有安装oracle10g的第二张盘,没有安装jdbc的驱动程序
而我这边是11gR2,Linux系统,采用静默安装。其实解压了两个文件,也不知道是否漏装了,或是其它问题,请大侠指点:
linux.x64_11gR2_database_1of2.zip
linux.x64_11gR2_database_2of2.zip
而我这边是11gR2,Linux系统,采用静默安装。其实解压了两个文件,也不知道是否漏装了,或是其它问题,请大侠指点:
linux.x64_11gR2_database_1of2.zip
linux.x64_11gR2_database_2of2.zip
SQLNET.INBOUND_CONNECT_TIMEOUT = 30
SQLNET.RECV_TIMEOUT = 30
SQLNET.SEND_TIMEOUT = 30在 listener.ora 增加:
INBOUND_CONNECT_TIMEOUT_LISTENER = 30然后重新启动监听试一下
为什么会出现这样的情况呢?网上搜索后得知,在Oracle11G中,
有这样两个参数SQLNET.INBOUND_CONNECT_TIMEOUT 和INBOUND_CONNECT_TIMEOUT_listenername;他们的默认值为60s,
这两个参数负责登陆用户与服务器验证的超时时间,在10GR2以前的版本默认是0s,为了防止Denial of Service (DOS)攻击,
在以后的版本中才设置为60s。如果在登录过程中,服务器没有给出及时的响应,那么将会在60后给出错误提示,
这个超时时间显然有点过长,导致用户重复登陆的频率加大,频繁的登录引起数据库负载过大。 解决问题:减少着两个参数的超时时间,把它们分别设为3和2s。
Metalink上给出的解决方案如下:
1. set INBOUND_CONNECT_TIMEOUT_=0 in listener.ora
2. set SQLNET.INBOUND_CONNECT_TIMEOUT = 0 in sqlnet.ora of server.
3. stop and start both listener and database.
4. Now try to connect to DB and observe the behaviour
1. set INBOUND_CONNECT_TIMEOUT_=0 in listener.ora
2. set SQLNET.INBOUND_CONNECT_TIMEOUT = 0 in sqlnet.ora of server.
3. stop and start both listener and database.
4. Now try to connect to DB and observe the behaviour
今天还在报错,然后下午在跑一段Sql,又出现新的错误:
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x118] [PC:0x1CE6BBF, kkqfppDrv1()+101] [flags: 0x0, count: 1]
DDE: Problem Key 'ORA 7445 [kkqfppDrv1()+101]' was flood controlled (0x2) (incident: 29074)
ORA-07445: 出现异常错误: 核心转储 [kkqfppDrv1()+101] [SIGSEGV] [ADDR:0x118] [PC:0x1CE6BBF] [Address not mapped to object] []
ssexhd: crashing the process...
Shadow_Core_Dump = PARTIAL
网上一篇类似的帖子说,是发现SWAP过小导致启动的时候报错:
http://qqmengxue.itpub.net/post/42175/515974
没搞清楚OS-ERRO:该去哪个路径看。
设置超时时间一般没用。
如果此时从客户段连接服务器会提示:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
问题的原因是服务器无法相应客户端给出的连接字符串。我的问题是因为我的hosts表有问题导致了。
listener.ora中给定的主机名在hosts表中没有设定正确的ip。
如果还不行,使用netca重新创建监听。