木马防护软件引起的DB Link故障

7月19日，晴。

这几天没啥事，在办公室很是无聊，看Oracle相关的书看得多了，便觉得有些累，然后就上上网，看看新闻。没一会儿也开始觉得无聊。不过，一个客户的来电，使我有了事做。

原来客户报告数据库有一个JOB总是不能正确执行，现象是那个JOB似乎一直都处于运行状态，然而并没有按预定的时间完成。使用toad来手动调用JOB执行的存储过程，toad就会失去响应，一直处于阻塞状态，不能再进行任何操作。

了解到客户的这套数据库是运行在Windows 2003之后，我又感到痛苦起来。因为如果是运行在Linux/Unix下的Oracle数据库，我可以拨号到客户的VPN上，然后使用字符界面的SQLPLUS或者telnet连上去，即使在网络性能不好的情况下，仍然可以保证相对流畅的操作。在最坏的情况下，我用电话线拨号上网也都能够顺利操作数据库。然而，如果不幸遇上Windows系统，就只能通过QQ或远程桌面进行操作，而办公室里上网用的只不过是多人共用的2MB ADSL，在这种情况下，将会是对我耐心的严重考验。“看看今天有没有耐心坚持下来”，我心里嘀咕。

我通过这套系统的DBA的QQ连接上了这套出现问题的数据库。在受网络太慢所带来的痛苦中，一步一步进行了下面的操作。

1. 从DBA那里得到job的存储过程名，在toad中手工执行该存储过程，toad挂起。

2. 用SQLPLUS连接到数据库，检查V$SESSION_WAIT，发现执行存储过程的会话正在等待library cache pin。看起来是在解析SQL时就出了问题，那么就排除了是存储过程中SQL的性能太慢导致出现问题的可能了。

3. 通过V$SESSION的SQL_HASH_VALUE，发现等待library cache pin的SQL语句比较简单，如下：

select sid,event,p1raw from v$session_wait where event like 'library cachepin%';

SID EVENT P1RAW
---------- ------------------------------ --------
164 librarycache pin 1BD820A8

select sql_text from v$sqlarea where hash_value=(select sql_hash_value fromv$session where sid=164) /*这里sid是从v$session_wait得到的。*/

SQL_TEXT

-------------------------------------------------------

selectflag from acct.account@zw where ......

通过以下代码中的SQL可以从X$KGLOB得到正在pin的对象：

Select kglnaown,kglnaobj,kglnadlk from x$kglob where kglhdadr=’ 1BD820A8’;

/*这里addr为v$session_wait中的p1raw列*/

KGLNAOWN KGLNAOBJ KGLNADLK

--------- --------- ---------

ACCT ACCOUNT ZW

从上面的结果可以看到，正在pin的对象是DB Link上的ACCT.ACCOUNT表。

4. 所谓librarycache pin，就是指将对象（存储过程，表等）的相关信息，以及这个对象的依赖关系等载入内存——Shared Pool。由于正在pin的对象是一个远程对象，那么发生library cache pin的原因，可能是DB Link问题导致的，也可能是远程数据库的某个操作导致的。我们可以用SQLPLUS执行下面一条简单的SQL来判断DB Link是否可用：

select * from dual@zw

不幸的是，这么一条简单的SQL，就导致了SQLPLUS被挂起，失去任何响应。在另一个SQLPLUS会话中，检查发现被挂起的SQLPLUS会话，仍然是在等待library cache pin。看起来是DB Link出现了问题，因为不太可能会有ddl操作发生在DUAL表上。

5. 在SQLPLUS下，新建一个DB Link，名为zw_link，执行select * from dual@zw_link，执行此SQL仍然会导致客户端挂起。

6. 在查询DB Link上的数据时，没有报TNS名称不对，也没有连接不通，也没有报用户名和密码错误，那么问题出在哪里呢？如果不通过DB Link，而直接在数据库服务器上使用SQLPLUS连接到远程数据库，如下所示，结果会怎么样呢？

sqlplus xxx/xxx@zw

结果是令人振奋的，Windows桌面弹出一个对话框，对话框显示的是Windows木马防火墙提示是否允许SQLPLUS程序访问ZW的IP地址的信息。看来是由于木马防火墙引起的问题。

7. 查看系统中运行的进程，推断Windows木马防火墙软件是通过线程注入到其他进程的方式，对进程的网络访问进行控制。当进程要访问网络时，弹出对话框选择是否允许访问网络，但Oracle进程是以服务方式运行的，没有设置为与桌面交互，所以弹出的对话框不能显示，所以一直处于等待连接状态。

8. 询问DBA，才知这个“Windows木马防火墙”是最近才安装的。试图卸载这个软件，居然卸不掉。只能重新启动数据库服务器到安全模式，才将这个软件卸载掉。

9. 检查数据库链接已经正常，手工执行存储过程，存储过程正常执行。检查存储过程运行产生的日志，也显示正常。至此问题解决。

这个问题就是因为有人随随便便地在数据库服务器上安装了一个软件，从而导致了系统的不正常。看起来，在Windows系统上安装与网络、病毒防护相关的软件时，也需要认真测试，避免造成系统不可用。

我个人是非常不喜欢将生产用的Oracle数据库运行在Windows平台上的，在这个平台上，我遇到的问题包括：

1. Oracle服务莫名其妙中止，除了在Windows的事件日志中看到有服务异常中止的简单提示外，没有任何日志指出发生了什么问题。这种情况下，要么升级数据库版本，要么重新安装操作系统。特别是后者，完全就是碰运气。

2. 系统染上病毒，将数据库的在线日志和UNDO表空间损坏，导致数据库宕掉，再也启动不了。用非常规手段修复，又造成数据丢失。

3. 防病毒软件锁住数据文件，导致数据文件不能写入。

虽然为了安全，有时不得不在Windows上运行网络安全防护和病毒防护软件，但是在安装这些软件之前，最好还是进行充分的测试，以保证这些软件不会干扰Oracle数据库的正常运行和带来其他的负面影响。

文章来源：《Oracle DBA手记1 - 老熊的DBA工作手记》