Re: PGA increasing continuously

With Oracle Support absolving the code of errors, they have assumed responsibility for a memory leak within the RDBMS, JRE, or OS.  Hope they track it down!

On 12/4/2020 12:22 PM, Purav Chovatia wrote:
> I agree. But since I am not a Java developer, so with my limited
> knowledge I verified and the rest I trust them.
>
> They are closing the RseultSet. They are not closing the statement (it
> is a prepared statement) and I guess that is right because it is to be
> executed repeatedly.
>
> Ofcourse, the connection too is not closed except when the application
> is stopped.
>
> We opened another SR with Oracle JDBC team and they said the code is
> ok. I dont mind sharing the code here.
>
> Thanks
>
> On Sat, 5 Dec 2020 at 01:39, Tim Gorman <tim.evdbt_at_gmail.com
> <mailto:tim.evdbt_at_gmail.com>> wrote:
>
> It isn't necessary to incur an "exceeded OPEN_CURSORS" error to
> experience a memory leak due to the memory held by unclosed
> explicit cursors.  I agree that no occurrences of the error make
> that particular cause less likely, but the point is that...
>
> Bad programming hygiene is the root cause of memory leaks. Any
> programmer lazy enough not to bother de-allocating
> dynamically-allocated memory structures (such as cursors or
> arrays) is more prone to blame leaks on the database platform,
> JRE, or operating system, which have millions of hours of
> regression testing against memory leaks.  It is certainly possible
> that there is indeed an undetected memory leak still lurking
> within the RDBMS, JRE, or OS, but the most likely probability is
> simply poor hygiene within the programmer's own coding.
>
> Request they provide proof that they have combed their code for
> memory leaks; this is a far more reasonable request than them
> requesting from you proof that the RDBMS, JRE, or OS doesn't have
> memory leaks.  Lint filters are available to automate this.  Just
> because application code did not previously fail due to memory
> leaks does not mean a leak did not exist, but rather that there
> wasn't enough data to be trigger detection.
>
>
>
> On 12/4/2020 8:28 AM, Purav Chovatia wrote:
>> Yes, according to the developers.
>>
>> But just in case they werent, it should have shown as open
>> cursors, isnt it? And we are not getting any errors around
>> cursors neither are we seeing high count of open cursors.
>>
>> On Fri, 4 Dec 2020 at 9:49 PM, Tim Gorman <tim.evdbt_at_gmail.com
>> <mailto:tim.evdbt_at_gmail.com>> wrote:
>>
>> Are they closing cursors?
>>
>> Hello Experts,
>>
>> Need some help desperately.
>>
>> We have an application that is doing a StoredProc call
>> and a SQL call from a Standalone Java App which uses the
>> Thin driver.
>>
>> The StoredProc does an UPDATE with a WHERE clause on the
>> single column Primary Key.
>> If the SQL%ROWCOUNT=0 then it will do an INSERT.
>>
>> The SQL does a select on the table with a WHERE clause on
>> the Primary Key.
>>
>> No joins. No CLOB/BLOB/LOB. No XML. Prepared Statements
>> used. Only thing that stands out is that the table has
>> 100+ columns.
>>
>> PGA goes on increasing and hence free memory on DB server
>> goes on decreasing.
>>
>> Problem originally started with ojdbc7.jar from 12.1.0.1.
>> We tried the ojdbc7.jar from 12.1.0.2 and the problem
>> worsens.
>> Problem persists with ojdbc6.jar from 11.2.
>> With ojdbc6.jar problem does not reproduce.
>>
>> Problem persists with DB 11.2.0.4, 12.1.0.2. Problem
>> persists on DB server on Linux as well on Solaris.
>>
>> On DB server, we dont see any open cursor problem. No
>> error on App side or on DB side except ORA-04036 in case
>> of 12c because it will cap PGA with pga_aggregate_limit.
>> We dug on PGA front and identified that subheap
>> kxs-heap-p is where the memory is used. But cannot
>> understand what does that mean?
>>
>> Would appreciate any ideas.
>>
>> It was a shock to realize that there is no way beyond
>> identifying the subheap! Developers are ready to fix the
>> issue but they have been requesting to tell what is to be
>> fixed. Is there no way to identify what is eating up the PGA?
>>
>> Thank you.
>>
>

--
http://www.freelists.org/webpage/oracle-l