Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Session PGA memory max exceeded 2 GB and crashes.

RE: Session PGA memory max exceeded 2 GB and crashes.

From: Powell, Mark D <mark.powell_at_eds.com>
Date: Wed, 20 Dec 2006 10:40:29 -0500
Message-ID: <D1DC33E67722D54A93F05F702C99E2A9483B4C@usahm208.amer.corp.eds.com> 






By any chance is it possible that the array is being initialized
repeatedly so that in fact you have hundreds or thousands of pl/sql
tables (arrays) rather than just one?



When done using a specific incarnation of a table is it truncated?



Perhaps dbms_session.free_unused_memory would be of use.







-----Original Message-----


From: oracle-l-bounce_at_freelists.org


[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Norman Dunbar

Sent: Wednesday, December 20, 2006 8:57 AM
To: oracle-l_at_freelists.org


Subject: Session PGA memory max exceeded 2 GB and crashes.




Afternoon (UK time) all,



Oracle 8174. (I know, I know !)


HPUX 11.11.



I wonder if anyone has any clues about this problem that I'm seeing on
one of my databases. There is a housekeeping packaged procedure run on a
daily basis to remove old data. It simply core dumps every night.



I've traced it to the following delete statement in the code below.
This delete actually deletes zero rows (no data matches anything
configured yet).



I've also watched the session's PGA memory max increasing to 2 GB and
when it gets there, the session crashes out. I'm puzzled as to how a
delete (with no rows to delete) uses so much PGA. The function call to
Pk_Utils.fnc_get_sys_par ( 'HOUSE_AUDIT') returns a number from an
in-memory array/collection and is currently returning 20. This
array/collection is initialised on package initialisation and is simply
a 64 row 'table' of names and values.



I've tested all the code beloe in isolation and there's nothing I can
see that makes the PGA usage go up and up, there is an slight increase
when the packages are initialised but that's it. It eats up about 1 MB
of PGA per second (rough estimate) and I have absolutely no idea where
it is going or why.



The DELETE does a full table scan of a table with 1,527,000 rows of
average length 102 bytes. The table has 22,008 blocks (8K block size)
and 6 free blocks and was analysed earlier this week - even with my
limited arithmetical abilities, that's a grand total of approx 150MB of
data (as per rows * length) or approx 175 MB if you take blocks * block
size. However, that will be part of the buffer cache and noty in the
PGA.


Obviously, there will be a cursor opened in the PGA but I cannot see why
it would need over 2 GB. The delete uses no UNDO at all - there are no
rows selected for deletion.



BEGIN


     Pk_Trace.ENTER ( 'Delete HAZ_RGBA_REG_BATCH_AUD records' );
	 DELETE HAZ_RGBA_REG_BATCH_AUD
	 WHERE MONTHS_BETWEEN(SYSDATE, LAST_USED_DATTIM) >
Pk_Utils.fnc_get_sys_par ( 'HOUSE_AUDIT');
	 COMMIT;
	 Pk_Trace.LEAVE ;
EXCEPTION
     WHEN OTHERS THEN
        Pk_Trace.REPORT_ERROR;
        RAISE;




END;


In the WHERE clause above, is the PK_UTILS package being called for each
row or just once. 10046 trace didn't give any useful help. (Nor did
single stepping the code in TOAD - it executed as one statement, the
DELETE.)


The PK_UTILS code makes two calls to PK_TRACE internally and this simply
writes a record to a logfile using UTL_FILE.



This is about step 7 of 10 in the houskeeping code and everything before
it uses MONTHS_BETWEEN etc as above - different tables are involved
along with a different parameter from the fnc_get_sys_par call.
That's all. So far, nothing is actually being deleted as we have not hit
anything older than the retention period in any of the preceeding or
following DELETEs.



We are seriously puzzled here.



Each core dump has this in the alert log :



ORA-07445: exception encountered: core dump [11] [3221215928]


[552153088] [0] [] []



ORA-04030: out of process memory when trying to allocate 1048 bytes
(koh-kghu call ,pl/sql vc2)


ORA-06510: PL/SQL: unhandled user-defined exception
ORA-06500: PL/SQL: storage error



An extract of the call stack trace for one of these dumps is :



ORA-07445: exception encountered: core dump [11] [3221215928]


[1609378340] [0] [] []


ORA-04030: out of process memory when trying to allocate 8216 bytes (PLS
non-lib hp,PL/SQL STACK)
ORA-06500: PL/SQL: storage error
----- CAll Stack Trace -----
calling              call     entry                argument values in
hex
location             type     point                (? means dubious


value)

-------------------- -------- --------------------
----------------------------
ssexhd()+344         ?        ksedst()             000000000 ?
                                                   800003FFBFFF0DA0 ?
                                                   C0000000002983D7 ?
                                                   0001F7EE8 ?
_sigreturn()+0       ?        ssexhd()             000000000 ?
000000000 ?
                                                   053440010 ?
                                                   800003FFBFFFD570 ?
lfirist()+424        ?        _sigreturn()         4000000000576418 ?
                                                   8000000100078450 ?
                                                   000000000 ?
                                                   8000000174EC5DA8 ?
lpmterm()+240        ?        lfirist()            C00000000029DCBB ?
                                                   8000000174EC4258 ?
                                                   4000000000ED8D47 ?
                                                   0000000A0 ?
lpminit()+664        ?        lpmterm()            80000001000B7BC4 ?
                                                   4000000000463510 ?
                                                   000007FFF ?
                                                   4000000000468F08 ?
pifictx()+140        ?        lpminit()            800003FFBFFF88D0 ?
                                                   000000000 ?
000000003 ?
                                                   4000000000A60E97 ?





<SNIP>




Metalink doesn't have anyhting for our parameters but a few hits on core
dukp [11] show what appears to be different errors:o(




Any help gratefully received, but I suspect am iTAR/SR is in the
pipeline.




Cheers,


Norman.



Norman Dunbar.


Contract Oracle DBA.


Rivers House, Leeds.



Internal : 7 28 2051


External : 0113 231 2051




Information in this message may be confidential and may be legally
privileged. If you have received this message by mistake, please notify
the sender immediately, delete it and do not copy it to anyone else.



We have checked this email and its attachments for viruses. But you
should still check any attachment before opening it.



We may have to make this message and any reply to it public if asked to
under the Freedom of Information Act, Data Protection Act or for
litigation.  Email messages and attachments sent to or from any
Environment Agency address may also be accessed by someone other than
the sender or recipient, for business purposes.



If we have sent you information and you wish to use it please read our
terms and conditions which you can get by calling us on 08708 506 506.
Find out more about the Environment Agency at
www.environment-agency.gov.uk

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


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


Received on Wed Dec 20 2006 - 09:40:29 CST












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US