Session PGA memory max exceeded 2 GB and crashes.
- From: "Norman Dunbar" <norman.dunbar@xxxxxxxxxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 20 Dec 2006 13:57:04 +0000
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
