5、开始挖掘

　　从监听器日志文件中能挖掘出些什么有用的信息呢?下面就列出几个挖掘的方向，如果你受到启发，完全可以进一步进行挖掘。

　　5.1.查看监听器停止情况

　　因为监听器每次启动和停止都会在日志中记录，所以可以从日志中挖掘出所有的监听器停止信息，无论是正常停止还是异常停止，在监听器日志中的CONNECT_STRING部分的COMMAND字段都会显示为“stop”，下面是具体的SQL语句：　

　　输出内容为：　

　　才输出内容可以看出，在10/16/05 05:35:41，用户test_user01在主机test_host01上对LISTENER这个监听器执行过stop命令。

　　5.2.查看程序使用情况

　　如果想知道都有些什么程序访问过数据库，可以使用动态视图v$session得到当前会话的程序名称，但对于历史记录可能只有通过监听器日志来查找了，在监听器日志的CONNECT_STRING字段中包含了一个PROGRAM变量，它的值就是客户端连接数据库时使用的程序名称了，下面是挖掘程序使用情况的SQL语句：　　

　　输出内容如下：　　

　　从上面的输出内容中可以看出，最常用的是sqlplus.exe，最后的1093表示自Oracle数据库安装以来总的会话数，它并不等于前面程序使用次数的和，因为还有一些会话使用的可能是其它访问机制。

　　5.3.服务名使用情况

　　如果你有一个RAC数据库环境，你可能会使用一些诸如负载均衡的方案，实现会话故障字自动转移，客户端连接数据库就必须使用服务名，而不能使用SID来连接数据库，下面是一个客户端连接tnsnames.ora文件的部分内容：　

　　注意这里使用的服务名是ora，有三个节点host1，host2，host3，在这个例子中，如果节点host1失效了，连接到它的会话就会自动转移到其它有效节点，如果使用SID连接的话，就不能自动转移，并且在CONNECT_STRING字段中的SID变量就会不为空，如果使用服务名连接，就会为空。使用下面的SQL语句查询还有多少人在使用SID连接，而没有使用服务名：

　　输出结果：

　　从输出结果可以看出还是有人直接使用了SID：ora和ora02连接数据库，但实际上没有哪个SID叫做ora，这可能是有人在猜测SID，这样就可以采取进一步措施，查看究竟是哪些机器这样在连接：　

　　输出结果为：　

　　这里为了方便阅读，我将字段竖向显示了，从中可以看出客户端的IP地址为192.168.1.105，使用的是TCP协议进行连接，主机名是_jdbc_，这通常表明它是一个JDBC瘦客户端，而且还有日期和时间，这样就可以进行目标定位了，从IP地址看，这应该是来自内网的一名用户，于是可以找到使用IP的人员，告诉他在什么时候，企图使用SID ora连接数据库，但他失败了，相信对方一定很吃惊!

　　5.4.监听器密码

　　如果为监听器设置了密码，那么客户端在连接时也必须提供密码才能连接，如果黑客或不怀好意的人尝试进行字典破解，那么破解过程会在监听器日志中留下记录，当使用了不正确的密码进行连接时，会在日志中记录下TNS-01190错误，但在记录这样一条日志信息时，只有四个字段，而不是常见的六个字段，我们只要明白最后一个表示返回代码，下面是一条日志示例：　

　　最后的1190就表示返回代码，下面是查询返回代码为1190的SQL语句：　

　　查询结果为：　

　　这里只输出了一条结果，如果我们的系统中存在test_user01这个用户，那可能不会是黑客在尝试密码，而如果出现了大量的这种记录，那可能就是被黑客盯上了。类似的错误代码还有12508，1169，11508表示有人想改变日志文件的默认目录，但没有成功，1169表示有人想执行某个命令，但他不知道密码而没有执行成功。

　　小结

　　如果单纯使用文本编辑器打开监听器日志文件查找其中的某些关键字，如TNS-01190，通过这种方式虽然可以找到一些有用的信息，但想要实现汇总统计的功能就必须借助数据表来实现了，本文只列出了一些简单的应用统计，其实还可以从不同角度进行查询统计，只要充分发挥想象力，还可以统计出更多有用的信息，还可以结合Oracle本身的审计功能进行综合查询。