memory leak is been observed in the load report and my DBA points its all application code drives the memory leak and he has nothing to dig on memeory leak on DB side so he is pushing onus to development.
In my code i have a bulk fetch for every minute 100 records will be fetched but its a unique scan. C++ application calls this procedure
the load ran for 21 hours below is the sheet which tells the memory utilization for every hour on two nodes ( node 1& node 2)
my point is if the application behavoiur causes the memory leak then the leak should be consistently same on both the nodes.
but node 1 and node 2 behaviours are not same the leak is varying on both the nodes so is this still a code behaviour ?
our DBA is technically limited always pushing issues to Development team saying application causing these issues. Log file sync issue came he pushed to development team
stating application issue.
please look below the chart which tells the memory utilization behaviour. so what to be done on memory leak my bulk fetch is requirment if 100 records every minute is a trouble
then is it a limitation on oracle side or anything on DBA still to tune on his DB please explain
S.No Memory Utilization
Node 1 Node 2
1 HOUR 6773.00 7284.75
2 HOUR 6981.00 7418.25
3 HOUR 6847.00 7213.00
4 HOUR 6942.25 7255.50
5 HOUR 7017.50 7273.00
6 HOUR 7081.75 6986.00
7 HOUR 7119.50 6913.75
8 HOUR 7158.50 6941.50
9 HOUR 7182.75 6961.25
10 HOUR 7204.00 6982.00
11 HOUR 7224.50 6990.25
12 HOUR 7241.75 6996.50
13 HOUR 7255.50 7004.50
14 HOUR 7272.75 7010.50
15 HOUR 7282.50 7017.50
16 HOUR 7255.50 7019.25
17 HOUR 7265.00 7023.50
18 HOUR 7265.75 7025.75
19 HOUR 7270.25 7027.00
20 HOUR 7276.50 7031.75
Thanks in advance
Edited by: Naveenkumar on Feb 18, 2013 4:39 PM
I do not see this as either a RAC or database issue. There are lots of issues that can look like a memory leak. Are you malloc'ing for each collect? or using just the first malloc? Are you properly releasing connections and/or malloc'ed memory? Does the app connect to one or both nodes?
It is late and that is all I can think of for now...
Thanks for reply,
This memory leak observed in oracle database. Are you properly releasing connections and/or malloc'ed memory?
C++ apps once establish the DB connection it will be forever also malloc is pertained to c++ how come it influence oracle DB memory leak Does the app connect to one or both nodes?
yes both nodes
Can you perhaps explain what you mean by "memory leak" and how you have diagnosed it? You did not mention your operatng system, but on any decent OS one would expect memory utilization %age to stabilize in the nineties. Your memory utilization looks reasonably level, varying by a couple of hundred from the mean. Why do you think there is a problem?
Oracle Certified Master DBA
John raises the crux of the issue - what did you see and how did you see it?
Memory leakage in the SGA will not cause growth, but less space in the SGA being available for creating new data structures. Memory leakage in the PGA means private process memory of Oracle dedicated, shared and perhaps job, server processes growing. Memory leakage in the client OCI driver will cause memory growth in the client process's private memory.
The only serious memory leakage I have seen in Oracle, was in the client process using Perl-DBI to connect via OCI (9i Net) to a 9i database. Private process memory of the Perl client grew to 100's of MB - and was released when a close database was done (no need to terminate the client). Which implied that the Perl-DBI library was likely leaking SQL statement and/or environment handles.
I have never seen mass Oracle caused leakage in server processes. What I have seen numerous times, is drastic memory increase in PGA. Always caused by shoddy code that abuses PL/SQL by creating enormous data structures - like unlimited bulk fetching, caching row data in PL/SQL "tables" (no such thing exists - these are arrays and nothing like SQL tables), and so on.
So the WHAT you saw and WHERE you saw it, are needed for a meaningful diagnosis of what the potential problems could be.