RE: connection pools and listener log

From: Herring Dave - dherri <Dave.Herring_at_acxiom.com>
Date: Mon, 18 Apr 2011 17:38:06 +0000
Message-ID: <BD475CE0B3EE894DA0CAB36CE2F7DEB4050D84E6_at_LITIGMBCRP01.Corp.Acxiom.net>



I'm finally getting back to this as I had a moment or 2 inbetween day-to-day support tasks. I believe I can now account for the connection count discrepency.

Oracle initially said internal operations like "ping", "service_update", "services" account for the difference between counts found in the listener log and "logons cumulative" in the database, but those internal operations were not being counted plus they account for a tiny % of the overall listener log entries.

What I did find was the client was using incorrect connection strings from the app servers. We've got a 4-node RAC with services for 2 nodes being OLTP and 2 nodes being batch. Let's say "inst1and2" is for the OLTP service and "inst3and4" for batch. In this example, via jdbc the app servers were using the following to connect:

(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = racvip3)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = racvip4)(PORT = 1521)) (LOAD_BALANCE = yes)(FAILOVER = ON) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = inst1and2)(FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC))))

racvip3 and 4 house "inst3and4", so obviously they're confused. What happens is the connection request comes in to the listener on racvip3 / 4, logs an "establish" connection in it's listener log, then redirects the connection to racvip1 / 2 for "inst1and2". Then the listener on racvip1 / 2 ALSO logs an "establish" connection in it's listener log, which is why we're getting nearly the double of connection counts in the listener logs than from "logons cumulative".

What I don't get is why the listeners aren't recording some sort of redirect command in their logs. I could have sworn I had read somewhere that when a connection is redirected to another node in a RAC, the listener will record the event in it's logfile, but I haven't found any in ours, even though this is happening thousands of times per hour! Needless to say I'll be speaking with the app team soon on getting this fixed.

DAVID HERRING
DBA
Acxiom Corporation

EML   dave.herring_at_acxiom.com
TEL    630.944.4762
MBL   630.430.5988 

1501 Opus Pl, Downers Grove, IL 60515, USA WWW.ACXIOM.COM The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.

-----Original Message-----
From: Herring Dave - dherri
Sent: Friday, February 25, 2011 5:46 PM
To: oracle-l-freelists
Subject: connection pools and listener log

Folks,

I'm trying to match up database logons with what I'm seeing in the local listener log and coming up way short, so hopefully one of you can enlighten me.

Our configuration is Oracle 10gR2 on RHEL 4.6. There are a number of application servers that connect using a connection pool. I reviewed AWR "logons cumulative" statistic recently and saw that 1 instance regularly gets around 1,000 per hr. Checking the local listener log for "established" I found a number more like 10,000 per hour. How can that be? Don't "established" connections via the listener have to match up with the database "logons cumulative"? If not, what is it that's being sent by the application that the listener sees as a request to "establish" a connection but not really connect to the database?

Thx.

DAVID HERRING
DBA
Acxiom Corporation

EML   dave.herring_at_acxiom.com
TEL    630.944.4762
MBL   630.430.5988 

1501 Opus Pl, Downers Grove, IL 60515, USA WWW.ACXIOM.COM
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 18 2011 - 12:38:06 CDT

Original text of this message