【故障处理】因GREP“花哨”功能导致ORA-12157错误的排查过程

2019-12-30 11:40:13

这个ORA-12157错误已经纠缠我有三天时间了，这个错误曾经一度让我感到很绝望。
在一步一步的排查后，“罪魁祸首”终于渐渐的浮出水面。

注：这里讲述的ORA-12157发生的原因只是导致发生这个错误的一种可能，还有很多种情况会导致这个错误发生，ORA-12157错误，发生原因的介绍非常的笼统，很难一蹴而就的确认问题的出处，类似7445、600等错误，需要一一甄别。

这里简单记录一下排查问题的过程。

操作系统:RedHat 5.3

1.在Oracle的oerr工具中查询到的错误解释如下
ora10g@testdb183 /home/oracle$ oerr ora 12157
12157, 00000, "TNS:internal network communication error"
// *Cause: Internal error during network communication.
// *Action: Not normally visible to the user. For further details, turn
// on tracing and reexecute the operation. If error persists, contact
// Worldwide Customer Support.

通过上面的解释，可以认定毫无任何参考价值。
Metalink上也没有太多的关于ORA-12157错误的资料。

2.问题是这样被暴露出来的
为完成异机RMAN恢复，在测试数据库上需要将10.2.0.1的数据库升级到与生产数据库一致的10.2.0.3版本数据库，在软件升级完成后，使用“sqlplus / as sysdba”方式登录数据库，ORA-12157错误发生了，无论使用什么手段都无法登陆到数据库中，更不用说完成后续任务了。报错现象如下：
ora10g@testdb /home/oracle$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Tue Aug 18 19:17:04 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

ERROR:
ORA-12157: TNS:internal network communication error

Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error

Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error

SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
ora10g@testdb /home/oracle$

3.故障排查过程
1）个思路：升级用的介质有问题
顺着这个思路，进行了测试。
找来曾经用于生产数据库升级的10.2.0.3的升级介质，重新升级了两次，同样的错误又频繁的出现。
否定了这个原因。

2）第二个思路：主机网卡有问题
找来网络工程师，进行了从硬到软的测试，测试结果：一切正常。
问题不在这里

3）第三个思路：升级后的sqlplus工具问题
升级后，将生产环境的sqlplus工具拷贝过来，测试，发现故障依旧。
还不是问题的出处。

4）第四个思路：从操作系统开始彻底的重做
重新安装操作系统，重新部署Oracle环境。
发现这一次的测试，在全新安装完Oracle软件之后，同样的报出这个错误，无语~~~

5）第五个思路：既然彻底重新安装都有问题，我开始怀疑是主机硬件的问题，于是我选择了一台近新到的一台主机，开始又一次的全新安装
令我彻底无语的时候发生了，竟然还是报错，难道是传说中的RP问题？

6）测试和排查到此我已经倍受打击，在诸多失败尝试后，我选择了冷静的思考与回归
首先全新的物理主机的安装都会出现这个ORA-12157错误，这是不正常的。
可以肯定，问题一定出在在安装配置的细节，开始细细的检查每一个配置细节。
细心的与曾经不下上百次的成功安装和测试经验进行对比，真相终于要浮出水面了。

所有的配置都没有变化，变化的部分是“.bash_profile”内容。
这个文件中多了“一行”信息，如下：
export GREP_OPTIONS='--color=always'

曾经添加，设置的目的是高亮的形式显示grep关键字结果。

就是这行的信息就是导致了无数次的升级和安装失败“罪魁祸首”！

在取消了这些信息之后，一切都恢复应有的“平静”与“正常”。

4.小结
不可以按照思维定势去做事，用朴素的方法做好每一件事件。
不要追求“花哨”的功能，以“简单实用”为根本准则。
希望这个故障处理过程能给您也起到警示的作用。

鉴于这是在升级后出的问题，如果返工时没有备份，结果将更加惨烈，所以，在每一次重大操作之前，一定要备份（可以tar整个oracle目录，也可以exp，也可以RMAN）。
有了备份就有了后路。

Goodluck.

-- The End --