点击这里给我发消息 
  设为首页 | 加入收藏 | 网站地图
联系我们
北京总部调度中心
具体地址:北京市海淀区知春路23号量子银座(863软件园)8层802
电话:010-51530012/13
传真:010-51530013
24小时服务热线:13501016950
长途客户:4006-355-119
数据恢复项目
监控录像数据恢复
监控录像数据恢复,大华监控录像恢复,海康监控录像恢复,汉邦高科监控录像恢复
数据库修复
ACCESS、FOXPRO、SQL SERVER、 ORACLE、MYSQL、DB2、NFORMIX、 SYBASE等数据库丢失的恢复
硬盘数据恢复
希捷、日立、IBM、迈拓、三星、 西部数据、昆腾、富士通、东芝、易拓等各种硬盘的数据恢复
RAID数据恢复
RAID0、RAID1、RAID5、RAID6、RAID1+0、RAID0+1.硬盘掉线导致RAID信息丢失、误删除数据、RAID信息丢失、服务器硬盘损坏导致无法读取数据
开盘数据恢复
硬盘磁头卡死、硬盘电机问题、硬盘读取无反应、硬盘内部组件问题、硬盘磁头偏移、硬盘磁头等等相关问题。
存储介质恢复
U盘、光盘、软盘、MP3、MP4、CF、SD、xD、MMC、SM、SMC、记忆棒、录音笔、磁带、微硬盘、硬盘、等。
当前位置:首页 > 技术交流

数据库故障oracle与防火墙

来源: 发布时间:2012-3-19 点击量:   【返回

最近有两次Oracle数据库故障与防火墙有关。这里的防火墙是硬件网络防火墙,而不是软件防火墙。

  先说说简单的。一个运行在Windows系统上的Oracle 9i,客户端不能连接数据库,但是用tnsping测试没有问题。解决问题的办法很简单,但是我们仍然需要了解一下引起这个问题的原因。

  这个问题首先得从客户通通过监听连接数据库的整个过程说起,此处指专用服务器连接模式:

  服务器上的监听进程在1521端口上进行侦听

  客户端发起一个数据库连接请求

  监听进程fork一个Oracle服务器进程(Server Process),也可称之为影子进程 (Shadow Process)。服务器进程选择一个大于1024的端口号进行侦听,监听进程把这个端口号发回到客户端,要求客户端重新连接这个指定的端口。

  客户端重新连接监听指定的新端口,也就是重新进行连接。

  客户端与Server Process直接对话,不再通过监听,进行会话认证(登录),执行SQL等等。

  从上述过程可以看到,客户端最终连接的端口实际上并不是1521。由于防火墙一般只开放了几个端口,对Oracle数据库只开放了1521端口,这样在客户端进行第二次连接时,不能通过防火墙,导致连接数据库失败。

  值得庆幸的是,只有Windows平台上的9i及以下版本的Oracle才会有这个问题。Oracle在Linux以及Unix平台下,多个进程间可以对端口进行复用,Oracle Server Process仍然使用的是跟监听进程一个端口(1521)。通过在linux使用strace跟踪客户端连接数据库的过程可以发现,客户端只连接了一次,并没有进行第二次连接,与上面描述的流程相比已经发生了变化。在Windows平台上,10g及以上版本的库,也同样利用端口复用,避免了这样的问题。

  那么Windows上运行的Oracle 9i怎么解决这个问题呢?答案很简单,在Windows注册表的\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn(这里n指Oracle Home的序号,只有一个Oracle Home时是0)键下面增加一项USE_SHARED_SOCKET,其值为TRUE。然后重启监听及Oracle服务(注意要重启Oracle的服务,而不仅仅是重启数据库),就可以解决此问题。实际上10g就是默认USE_SHARED_SOCKET为TRUE。

  对于这种问题,或者是让防火墙打开针对数据库主机的所有端口访问,也能解决。但是这种方案往往会被负责安全的人否决。

  下面这个由防火墙导致的问题,就相对复杂一点了。

  某个应用经常报ORA-3113错误,检查发现ORA-3113来源于数据库的一个db link。为了方便下面的描述,将应用直接连接的数据库称为DB_A,DB_A通过db link连接的对端的数据库称为DB_B。在DB_B主机上没有发现任何有关的trace和日志,应用执行的SQL也是非常简单的SELECT语句,返回的数据量也不大。但出错的语句并不是固定的某一个SQL。在应用连接的数据库DB_A上做ORA-3113 error stack的trace,也没有发现有价值的东西。

  导致ORA-3113错误的原因很多。大家可以参考ITPUB上的一篇贴子《ORA-03113错误分析》。

  在这个ORA-3113错误的问题中,数据库DB_B没有任何日志,出现这种情况的一个很可能的原因是,DB_B上的Server Process已经中止,但又不是在执行SQL过程中出错异常中止了,比如被KILL掉,网络连接中断等。被KILL掉这个原因,首先被排除,因为这个错误出现得很多,每天都有。询问维护人员,称也没有进行过KILL操作。那么最大的可能性应该是网络了。顺着这条线索,我们在DB_A上用netstat -na命令检查到DB_B的网络连接,与DB_B中v$session中的会话进行比较,发现DB_A连接到DB_B的数据库会话,比netstat 命令看到的网络连接数少得多。

  这是一个重大的突破。首先要怀疑的是防火墙。因为防火墙导致Oracle连接异常的情况非常多。访问数据库的DBA,这两个数据库分别在不同的业务网络中,中间使用了Cisco的防火墙。请防火墙维护工程师检查防火墙的设置,发现防火墙设置了TCP连接超时(这个术语是防火墙工程师告诉给我的,实际上我个人认为这个术语字面含义跟其实际的作用相差较大)设置为1小时。也就是,对于通过防火墙的所有TCP连接,如果在1小时内没有任何活动,就会被防火墙拆除,这样就会导致连接中断。在拆除连接时,也不会向连接的两端发送任何数据来通知连接已经拆除。

  而出问题的业务系统,使用的高峰期是在正常的工作时间内,最高时会导致DB_A会产生数十个连接到DB_B。但是在业务低谷期或经过一个晚上,防火墙将拆除大部分甚至是所有的连接。而下一次使用时,应用通过连接池选择DB_A中的一个会话,这个会话的db link之前已经连接到DB_B,但是网络连接已经被防火墙拆除,但是这个会话并不知道,仍然会认为这个连接有效,结果试图向DB_B提交SQL时,就出现了ORA-3113错误。

  实际上,很多使用网络连接的应用,可以使用称之为KeepAlive的特性,来保持TCP连接的活动性。在打开一个连接时,通过setsockopt函数,设置socket为SO_KEEPALIVE,这样,在OS层,如果一个TCP连接在指定的时间内没有活动,会发送一个探测包到连接的对端,检测连接的对端是否仍然存在。如果这个时间小于防火墙中设置的“超时”时间,防火墙就会检查到连接中仍然有数据,就不会断开这个连接。

  操作系统中keep alive的相关设置,不同的系统有不同的设置方法。比如在Linux中,在sysctl中设置net.ipv4.tcp_keepalive_time = 120,表示探测时间为120秒,即2分钟。在AIX中,通过no命令将tcp_keepidle参数设置为240,表示探测时间为120秒。注意AIX中这个参数的单位是1/2秒,而在Linux中是1秒。

  还好Oracle提供了类似的机制。也就是DCD(Dead Conneciton Detection)。在$ORACLE_HOME/network/admin/sqlnet.ora文件中增加如下一行:

  expire_time=NNN

  这里NNN为分钟数,Oracle数据库会在会话IDLE时间超过这个指定的时间时,检测这个会话的对端(即客户端)是否还有效。避免客户端由于异常退出,导致会话一直存在。

  因此,我们可以通过在DB_B数据库中的sqlnet.ora文件中设置expire_time来解决上面提到的ORA-3113问题。


原文出自【比特网】,转载请保留原文链接:http://network.chinabyte.com/252/12292252.shtml



上一条: 没有了... | 下一条: Windows Server 8中的重复数据删除功能
最新文章 
· 服务器虚拟化带来的六大存储瓶颈 6-5
· 服务器虚拟化的经验未必适合桌面… 6-5
· 服务器虚拟化怎样选择具体实施方… 6-5
· 选购虚拟化服务器的五大注意事项 6-5
· 如何创建虚拟机备份并避免一些常… 6-5
· 嵌入云服务器:如何控制服务器升… 6-5
· 云时代:政府CIO应该“未雨绸缪”… 6-5
· 存储虚拟化和服务器虚拟化紧密相… 5-31
相关文章
· 西数的微博开通了! 2-20
· 关注微博,有好礼相送! 2-20
· 西数科技培训 2-22
· 西数科技的培训课程表 2-22
· R-Studio5.0 2-22
· 聚焦MySQL性能优化 空间数据库开… 2-22
· SQL Server 2000数据库管理中的维… 2-22
· 程序员基础 MySQL数据库开发必备… 2-22
 
友情链接: 北京服务器数据恢复 | 数据安全论坛 | 重庆数据恢复 | 天津数据恢复 | 监控录像数据恢复 | 数据恢复实验室 | 保定分类信息网 | 南京数据恢复 | 南京硬盘恢复 | 数据恢复 | 电子取证 | U盘数据恢复 | 西数数据恢复博客 | 昆明数据恢复 |
版权所有:北京西数科技有限公司 Copyright @ 2003-2012 All rights reserved 京ICP备10217323号
公司地址:北京市海淀区知春路23号量子银座(863软件园)8层802 | 邮编:230031 1024*768显示最佳
公司电话:010-51530012 /13 13501016950