Session PGA memory max exceeded 2 GB and crashes.

From: Norman Dunbar <norman.dunbar_at_environment-agency.gov.uk>
Date: Wed, 20 Dec 2006 13:57:04 +0000
Message-Id: <s5894147.054@environment-agency.gov.uk>

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

Received on Wed Dec 20 2006 - 07:57:04 CST