Comments on: Troubleshooting PGA leak with PGA heap dump

By: Steve Howard

Steve Howard — Mon, 08 Mar 2010 15:01:52 +0000

Dion,

This is really good stuff, and help me immensely this morning while troubleshooting what looked like a leak in a sessions PGA. Thanks for taking the time to post it.

Thanks,

Steve

By: Dion Cho

Dion Cho — Mon, 24 Aug 2009 09:33:05 +0000

@Hans.

Thansk for the adding.

Without proper data(including PGA heap dump + corresponding subheap dump) when 4030 took place, there would be not much thing to tell for me.

You might like to post the question on the OTN forum and/or freelist.

Regards.

By: Hans-Peter Sloot

Hans-Peter Sloot — Mon, 24 Aug 2009 08:32:35 +0000

Hi Dion,

Sorry I should have added.
The ulimit where checked again and again.
The impdp shows various ORA-04030. Until now we have generated at least 4 different.
I have no direct access to the instance.
The dba’s managed to get a heap dump for (sort subheap,sort key) generated while impdp is creating indexes. The heapdump shows that the sort subheap has only 6k free whereas 64k is requested. The total pga is 358M with 6M free in various subheaps.
Metalink is not of much help.
Oracle Support isn’t either alas.
The just tell us to exclude indexes + statistics + procedure etc.

Regards Hans-Peter

By: Dion Cho

Dion Cho — Fri, 21 Aug 2009 23:52:18 +0000

Hans.

1. Have you checked your OS configuration?
2. And tried analyzing PGA heap dump?
3. And searched metalink for that?

By: Hans-Peter Sloot

Hans-Peter Sloot — Thu, 20 Aug 2009 09:48:27 +0000

Hello Don,

With impdp we get
ORA-04030: out of process memory when trying to allocate 2080 bytes (kxs-heap-c,kghsseg: qcstxsInit)
As far as we know no real memory shortage.

Could impdp use array bulk inserts and hit the same bug?

Regards Hans-Peter

By: Blogroll Report 06/06/09 – 12/06/09 « Coskan’s Approach to Oracle

Fri, 12 Jun 2009 19:33:07 +0000

[...] 1-How to deal with memory leaks by using memory dumps. (PGA leak bug) Jonathan Lewis – PGA Leaks Dion Cho – Troubleshooting PGA leak with PGA heap dump [...]

By: Dion Cho

Dion Cho — Wed, 10 Jun 2009 02:41:19 +0000

@Polarski

Thanks for the work.

That’s why I left the comment “this works only for local database”. It was just a dirty sample and you made it better!

By: B. Polarski

B. Polarski — Tue, 09 Jun 2009 12:53:14 +0000

humm… and the rest must also be transformed:

select
to_number(regexp_replace(column_value,’.*sz=[[:space:]]+([[:digit:]]+)[[:space:]].*’,'\1′)) csize,
rtrim(regexp_replace(column_value,’.*sz=[[:space:]]+[[:digit:]]+[[:space:]]+([[:alnum:]]+)[[:space:]].*’,'\1′)) atype,
rtrim(regexp_replace(column_value,’.*["]+(.*)["].*’,'\1′)) ctype,
rtrim(regexp_replace(column_value,’.*["]+.*["](.*)’,'\1′)) ds
from table(get_trace_file2(‘&1′))

By: B. Polarski

B. Polarski — Tue, 09 Jun 2009 12:16:16 +0000

The script heap_analyse must be refined. Spacing in trace file is platform dependent. On my Linux x86_64 the following line “select to_number(substr(column_value, 21, 9)) as csize,” return empty string and the to_number make it error. After investigation the heap size value in trace file was at 30 not 21.

I suggest using regexp_replace to extract values
” select to_number(regexp_replace(column_value,’.*sz=[[:space:]]+([[:digit:]]+)[[:space:]].*’,'\1′)) as csize”

tested it and it worked.

By: Dion Cho

Dion Cho — Tue, 09 Jun 2009 07:23:05 +0000

@Jonathan.

Thank you for the infos.

I would look into those views for further investigation.