Re: How does Oracle database close client connections

From: Tanel Poder <tanel_at_tanelpoder.com>
Date: Tue, 20 Nov 2018 14:57:03 -0500
Message-ID: <CAMHX9J+tSz3SA8+=tFUCcV2kJy7kmDo6tijOrFCiNhYeTCz06g_at_mail.gmail.com>



Hi Amir,

Yep it's the applications job to close connections that it doesn't need anymore (or release them back to connection pool). Oracle by default does the right thing and does not kill any connections that the application is holding. It doesn't have the visibility into whether the app wants to use the connection again.

So if you have a "connection leak" bug in the app and it can't be fixed for some reason, then you could set a PROFILE to limit the IDLE_TIME for the username this app is using (especially as you seem to already have some sort of a 30 sec timeout in IIS). This would kill idle connections after X minutes regardless if these connections were idle due to a connetion leak bug or they genuinely needed to be idle for a while until the app completed some other task. So you might end up killing wrong sessions that way too and get exceptions in your app.

Note that the IIS timeout might not apply (I don't know) if the application code itself still holds the connection. A typical problem why connection (and cursor leaks) happen is this.

Code runs like this in ideal world:

  1. Get gonnection
  2. Do something
  3. Release Connection
  4. Return

But if some transactions hit an exception and if the developers don't release the connection in an exception handler, you'll get this:

  1. Get connection
  2. Do something Exception
  3. Release Connection
  4. Return

The connection release operation is skipped as the latest SQL hit an exception.

You could query the V$SESSION.PREV_SQL_ID of all those excessive sessions and see if they all have a similar SQL_ID as the last one executed. SQL tracing some sessions would help to see which error you got.

--
Tanel Poder
https://blog.tanelpoder.com/seminar/


On Thu, Nov 15, 2018 at 9:55 PM Hameed, Amir <Amir.Hameed_at_xerox.com> wrote:


> Hi,
>
> I was recently engaged to troubleshoot an issue in a pre-production
> environment which involves Oracle 11.2.0.4 database running on Solaris
> server and IIS running on a Windows VM. On the IIS side, the minimum and
> maximum connection pool settings are set to 100 and 4000 respectively. On
> the Oracle database side, the processes and sessions parameters are set to
> 4000 and 6000 respectively. I have no visibility to IIS and I do not have
> any experience with IIS either. I am relying on my understanding of how
> connection pooling work in WebLogic Server to triage the problem. The
> application processes thousands of invoices in multiple batches and each
> batch can run up to 4000 invoices concurrently. The non-production
> environment has similar setup (at least this is what I have been told).
> When the application team runs load in non-production, it completes
> successfully and we do not see more than 150 connections coming from the VM
> (V$SESSION.MACHINE) and the INACTIVE session count goes down to 100.
> However, the same load when run in the pre-production environment, it
> consumes up to 4000 connections and this is a repeatable process. I have
> been told that IIS is setup the same way in non-production and
> pre-production environments. The default value of releasing idle
> connections frequency in IIS is 30 seconds. However, after processing
> invoices, even though connections established from the IIS VM have INACTIVE
> status, connections are not getting released in the pre-production
> environment and I am trying to understand the mechanism around how Oracle
> database releases connections.
>
>
>
> I believe (and I could be wrong) that Oracle does not automatically close
> INACTIVE connections on its own and this is not the same situation as DCD.
> Is it possible that even though IIS is trying to shrink the connection pool
> but Oracle database is not releasing connections? Both non-production and
> pre-production have same initialization parameters with the only difference
> being the SGA size.
>
>
>
> Any insight will be appreciated.
>
>
>
> Thanks,
>
> Amir
>
-- http://www.freelists.org/webpage/oracle-l
Received on Tue Nov 20 2018 - 20:57:03 CET

Original text of this message