将JDBC连接与Oracle侦听器日志文件内容相关联

时间:2010-12-20 14:07:27

标签: oracle jdbc

环境

使用jdbc连接池的各种应用程序: WebLogic 8(及更高版本)和Tomcat 6应用程序服务器, 各种版本的Oracle数据库(从9.2.0.7到10.2.0.4) 在各种平台上(RHEL 5.5,Solaris 9,Solari 10等)。

我正在尝试理解侦听器日志文件中以下条目的含义(注意频率):

07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59576)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59578)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59577)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59579)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59580)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59581)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59583)) * establish * <my_sid> * 0
07-DEC-2010 09:32:30 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59582)) * establish * <my_sid> * 0
07-DEC-2010 09:32:32 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59589)) * establish * <my_sid> * 0
07-DEC-2010 09:32:43 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59600)) * establish * <my_sid> * 0
07-DEC-2010 09:32:43 * (CONNECT_DATA=(SID=<my_sid>)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=<my_user>))) * (ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=59601)) * establish * <my_sid> * 0

所有这些应用程序都使用连接池,v $ session.logon_time反映连接池被激活的时间(通常是应用程序服务器启动时间)和预期的连接数。

所以我试图理解侦听器日志中那些频繁的条目代表什么。

这些是新的新连接(我想它们不是)或者它们只代表通过连接池现有连接的常规流量(如果不是这种情况,我不明白为什么端口是更改(我知道侦听器在初始握手期间将客户端重定向到空闲端口,但我不明白为什么在连接池已经启动后发生这种情况)

这可能是一种不使用连接池的心跳吗?

不幸的是,在这种情况下,应用程序用户将禁用审核 所以我在dba_audit_trail中没有详细信息。

这些是来自此特定日志文件的一些数字:

$ tail -1000 listener_<my_sid>.log | awk 'END {
    for (i in count)
  if (count[i] > 10)
    print i, count[i]
}
  /__jdbc__/ {
    sub(/:[^:]*$/, x, $2)
    count[$2]++
  }'
09:14 13
09:17 32
08:45 14
09:19 12
08:49 13
09:32 33
09:35 20
09:37 17
09:38 29
08:30 35
09:03 13
09:05 13
08:33 13
08:51 11
09:24 28

记录无序,但这与此无关, 我想要了解每分钟这35个条目的含义。

我在不同客户站点的各种不同的Java应用服务器环境中观察到这种行为,并且我没有发现任何异常的资源使用情况。

配置的连接池连接在v $ session中正确显示:例如,使用50 x app节点(min = max)我在v $ session中看到50个连接x app节点,v $ session.logon_time正确反映了各自的时间应用节点已启动。

这让我觉得即使操作系统端口随每个请求而改变,这些请求也会使用已建立的连接池物理连接。

如果其他人可以在使用jdbc连接池的不同应用程序环境中运行上述awk脚本(仅在Solaris上使用nawk),那就更好了。只是为了比较这些数字。

说实话,我在所有我们的应用程序环境中观察到相同的行为,并且只是在两个由完全不同的应用程序管理员和开发人员管理的客户站点上注意到它。

当然,存在常见的错误配置并非不可能。

===================

更新:2011/02/28

其中一个环境的更多细节。

  • 4个WL实例(2个节点)
  • 15个数据源

配置:

initial-capacity: 5
max-capacity:     varies, from 20 to 150
capacity-increment: varies, from 1 to 5
connection-reserve-timeout-seconds: 10
test-frequency-seconds: varies, from 120 to 240
inactive-connection-timeout-seconds: 0
seconds-to-trust-an-idle-pool-connection: 10

以下信息适用于其中一个节点(2个WL实例):

SQL> select sysdate from dual;

SYSDATE
--------------------
28/FEB/2011 12:03:50


SQL> select
  username, machine, logon_time, count(1)
from
  v$session
where
  machine='node1'
group by
  username, machine, logon_time
order by
  1,2,3;    2    3    4    5    6    7    8    9   10

USERNAME   MACHINE    LOGON_TIME             COUNT(1)
---------- ---------- -------------------- ----------
C_USER       node1     26/FEB/2011 20:25:01          1
C_USER       node1     26/FEB/2011 20:25:19          3
C_USER       node1     26/FEB/2011 20:25:20          2
C_USER       node1     26/FEB/2011 22:45:32          1
C_USER       node1     26/FEB/2011 22:45:46          5
C_USER       node1     27/FEB/2011 10:39:42          1
C_USER       node1     28/FEB/2011 09:25:16          1
C_USER       node1     28/FEB/2011 10:01:05          1
C_USER       node1     28/FEB/2011 10:01:06          1
C_USER       node1     28/FEB/2011 10:23:32          1
C_USER       node1     28/FEB/2011 10:23:33          6
C_USER       node1     28/FEB/2011 10:23:34          3
C_USER       node1     28/FEB/2011 10:36:09          1
C_USER       node1     28/FEB/2011 10:46:21          1
C_USER       node1     28/FEB/2011 11:00:17          1
C_USER       node1     28/FEB/2011 11:00:18          3
C_USER       node1     28/FEB/2011 11:16:26          2
C_USER       node1     28/FEB/2011 11:24:07          1
C_USER       node1     28/FEB/2011 11:24:08          1
C_USER       node1     28/FEB/2011 11:30:32          4
C_USER       node1     28/FEB/2011 11:30:33          1
C_USER       node1     28/FEB/2011 11:43:10          5
C_USER       node1     28/FEB/2011 11:50:36          9
C_USER       node1     28/FEB/2011 11:50:37          1
C_USER       node1     28/FEB/2011 11:54:16          2
C_USER       node1     28/FEB/2011 11:54:17          2
C_USER       node1     28/FEB/2011 12:01:52          2
C_USER       node1     28/FEB/2011 12:01:54          1
C_USER       node1     28/FEB/2011 12:01:55          4
S_USER       node1     26/FEB/2011 20:25:21          1
S_USER       node1     26/FEB/2011 22:45:47          1
W_USER       node1     23/FEB/2011 07:03:33          1
W_USER       node1     26/FEB/2011 20:25:05          1
W_USER       node1     26/FEB/2011 20:25:07          5
W_USER       node1     26/FEB/2011 20:25:15          3
W_USER       node1     26/FEB/2011 20:25:16          7
W_USER       node1     26/FEB/2011 20:25:17          1
W_USER       node1     26/FEB/2011 20:25:18          7
W_USER       node1     26/FEB/2011 20:25:19          3
W_USER       node1     26/FEB/2011 22:45:35          1
W_USER       node1     26/FEB/2011 22:45:37          4
W_USER       node1     26/FEB/2011 22:45:38          5
W_USER       node1     26/FEB/2011 22:45:42          5
W_USER       node1     26/FEB/2011 22:45:43          5
W_USER       node1     26/FEB/2011 22:45:44          3
W_USER       node1     26/FEB/2011 22:45:45          7
W_USER       node1     26/FEB/2011 22:45:46          1
W_USER       node1     27/FEB/2011 16:51:48          4

48 rows selected.

$ date
Mon Feb 28 12:19:35 CET 2011
$ tail -5000 listener_<snipped>.log | nawk 'END {
    for (i in count)
  if (count[i] > 10)
    print i, count[i]
}
  /__jdbc__.*HOST=<snipped>/ {
    sub(/:[^:]*$/, x, $2)
    count[$2]++
  }'| sort
07:29 13
08:57 13
09:09 18
09:24 18
09:29 27
09:32 13
09:37 17
09:51 12
10:01 13
10:06 27
10:12 17
10:19 13
10:20 12
10:22 17
10:23 16
10:35 17
11:00 13
11:21 18
11:24 17
11:38 13
11:43 32
11:50 13
11:54 23
12:01 15
12:05 17
12:10 28
12:17 18

1 个答案:

答案 0 :(得分:1)

我认为要明白这一点,您还需要在遇到此行为的环境中从应用程序服务器发布数据源配置。

数据源定义连接池,以及调整大小等方面的行为。

我认为数据源定义中使用的参数是专有的,因此可能需要返回JDBC提供程序的文档 - 这很可能是Oracle,并将覆盖Weblogic文档集。

希望这会有所帮助。