今天遇到一个比较简单的问题，由于基础不好，忙得跟热锅上的蚂蚁一样，到处乱找资料做诊断，到头来还是越想越远，没有掌握到问题的根本原因，自然也处理不好问题，让自己和客户走了不少弯路。

　　问题描述：

　　问题不想过于描述的太细，大概说一遍

　　商务接到客户的MSN信息，说容灾库的listener起不来了，起来的时候报错：

　　我的处理过程描述：

　　根据TNS错误号TNS-12547:TNS:lost contact我在google上搜索，给出了两种情况和处理方法：

　　listener.log文件大于2G，处理方法是mv，或者rm这个文件，系统会自动创建一个新的(我的10G实验库上是这样的)。

　　在主机的/etc/hosts文件中没有127.0.0.1 localhost这一项，处理方法是加上。

　　我原以为肯定逃不出这两种情况中的一种，可是登录上去一查看，不行了，listener.log才300M没有超过2G，而且/etc/hosts/里清晰的写着“127.0.0.1 loopback localhost”(不清楚这里的“loopback”做什么用，但肯定不是问题所在)，这下傻眼了，没办法，也只好硬着头皮让客户将listener.ora文件rename掉，重新生成一个新，看能不能成功启动listener。

　　客户照着我提供的方法做之后(不清楚他做的时候中间的过程)，listener还是起不了，意料之中的事。

　　这时我已经让新生成的listener.log内容所迷惑，内容如下：

　　这是我已经脱离正常的分析轨迹，转向去着重分析log里面的内容了，根据TNS-12546: TNS:permission denied这个内容去搜索，搜来了一大堆的资料，跟出现问题南辕北辙，这里不谈了。反正是到最后实在不知道怎办了，没办法，只好求救了。

　　正确的处理过程描述：

　　打电话给经理高，高听过问题描述过程后，让我将主机135.10.34.38的listener.ora、sqlnet.ora的信息搜集给他看(抓重点抓得真准!)，之后高让我ps -ef看listener的进程还在不，有的话就KILL -9然后再启一下listener，我照做了还是不行，高那边犹豫了一会，解决问题的核心出现了!

　　他让我在sqlnet.ora中添上135.10.34.38这个IP，然后再重启listener，我一查，主机38上的sqlnet.ora果然没有这个IP，怪不得另外一个节点可以正常起而这个节点不行呢，知道原因了，哈哈，加上之后，重启listener，成功!

　　个人总结：

　　关于sqlnet.ora

　　question：sqlnet.ora中的IP限制，是限制什么操作?

　　answer：tcp链接(经典!)

　　客户这边他们使用sqlnet.ora来实现限制登录IP功能，下面是一篇从网上截下的一篇文章内容，说的很详细……

　　修改sqlnet.ora,实现客户端IP限制

　　如果要在网络上做一些IP地址的限制，一般情况下我们首先想到的是用网络层的防火墙软件。要找网管来设置。

　　但是如果网管不在，或者仅仅想在数据库层来实现IP地址的限制，DBA们只要修改Server端的一个网络配置文件

　　sqlnet.ora文件就可以了。

　　(Oracle9i以上版本，在目录$ORACLE_HOME/network/admin 或者 %ORACLE_HOME%\network\admin 下)

　　增加如下内容：

　　tcp.validnode_checking=yes

　　#允许访问的ip

　　tcp.invited_nodes =(ip1,ip2,……)

　　#不允许访问的ip

　　tcp.excluded_nodes=(ip1,ip2,……)

　　修改sqlnet.ora后，重新启动listener服务，改动就可以生效了。

　　如果我们从未允许的IP客户端连接过来，会出现以下错误：

　　ERROR: ORA-12537: TNS: 连接已关闭

　　这种在Oracle网络层实现客户端IP访问限制的方法在防火墙后面的公司内部网或者托管机房的内部网里可以采用。

　　这下终于明白了为什么以前IP是135.10.22.74时不管用PL/SQLdev工具登录也行，用CRT登录主机，然后sqlplus登录也行，而使用其它IP的时间却不能用PL/SQLdev，原来是在sqlnet.ora设置了

　   这两个限制IP的参数，哈哈，困惑一下解开了。

　　反正又重新复习了一遍关于Oracle网络架构问题，listener.ora、tnsnames.ora、sqlnet.ora的作用和相互连接，以前看过老忘，今天遇到问题了整理一下，思路就比较清晰不好忘了，呵呵。