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

  • From: "Rajeev Prabhakar" <rprabha01@xxxxxxxxx>
  • To: norman.dunbar@xxxxxxxxxxxxxxxxxxxxxxxxx
  • Date: Wed, 20 Dec 2006 10:06:13 -0500

Hi Norman

Although, the versions being talked about in the thread in
the below mentioned URL is different, I did notice that the
core issue is quite close (ie.. 2GB limit).

Plus, it is on hp-ux 11.11, same as yours.


On 12/20/06, Jason Heinrich <jheinrich@xxxxxxxx> wrote:

Are you able to modify this code?  Using MONTHS_BETWEEN in your WHERE
is forcing the full table scan, which, I suspect, is causing a large sort
in-memory.  Placing an index on LAST_USED_DATTIM and rewriting your WHERE
clause thusly:

Pk_Utils.fnc_get_sys_par('HOUSE_AUDIT') * (-1) )

would avoid both the scan and the sort.  I don't know if this will solve
of your PGA usage, but it should help.

On 12/20/06 7:57 AM, Norman Dunbar wrote:

> 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.
>      Pk_Trace.ENTER ( 'Delete HAZ_RGBA_REG_BATCH_AUD records' );
> Pk_Utils.fnc_get_sys_par ( 'HOUSE_AUDIT');
> Pk_Trace.LEAVE ;
>         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
> 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.

Jason Heinrich
Oracle Database Administrator
Pensacola Christian College


Other related posts: