| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: pga workarea and ora-04030
Hi,
I followed you advice and made small testprogram see below: I only get the ora-06500 which I have had before in the original program as A followup error so to me it seems to be reproducible.
In manuals I only find that the index
Of a pl/sql table cannot be more than 2**31, which is something like
2.000.000.000
I found on metalink some posts which suggested this might be functioning
better enlarging shared pool and also max user data (ulimit of oracle)
We increased maxdseg in the ux-kernel parameters to 4Gb to increase this
limit (was 2Gb). There is 4Gb available of physical memory in the box.
Using a shared pool 0f 500Mb, pga_aggregate_target 100Mb setting 100.000.000 elements -> 22 minutes and it fails Exception raised insert i= 68102540
Using 1 table, shared pool 2Gb
setting 1.000.000 elements -> 14 seconds
setting 10.000.000 elements -> 282 seconds
setting 100.000.000 elements -> 12 min 24 seconds fails
21:54:37 VU_2>exec testarray( 100000000 );
Exception raised insert i= 17613935
Running with a second table involved: after 17 minutes 29 seconds
22:40:20 VU_2>exec testarray( 100000000 );
Exception raised insert i= 8806960
So it is reduced by 50%. But why is the result with a smaller sga
Giving me more elements set?
Watching the oracle serverprocess with top utility
I see the memory resident part
Most of the time around 2600M but more interesting the process is
Most of the time sleeping, what the heck is it doing all the time before
Going into an error?
1 ? 4728 oracle 128 20 4116M 2626M sleep 7:49 1.20 1.20 oracleVU_2
I cannot find any other restriction then 2**31 limit on the index. I don't know how to calculate how much memory this is taking because watching sqlworkarea of pgastat doesn't show any useful info in this case. But it looks to I'm hitting a limit somehow.
Can somebody explain which limit this is and how is it composed or influenced (temp, sga ?) ?
Is this reproducible on other systems / versions ?( Metalink post reports This also on early 8.1.x versions , I couldn't find this on 9.x versions)
create or replace procedure testarray( psize number ) as
begin
declare
TYPE nAllotment_tabtyp IS TABLE OF number
INDEX BY BINARY_INTEGER;
assarray nAllotment_tabtyp;
uitleg := 'insert i2= ' || i;
assarray2(i) := i;
*/
end loop;
EXCEPTION
WHEN OTHERS THEN
dbms_output.enable(20000);
dbms_output.put_line(' Exception raised ' || uitleg );
end;
The workarea_policy stuff does not apply
to things like pl/sql tables, only to tuneable
memory. Given that you don't have the
problem when you disable p_a_t and w_p,
it may be that there is some buggy event
occurring where the workarea_policy code
is being infringed by an abuse of pga memory.
You could try setting up test cases where you use a pl/sql loop to build a pl/sql table. Make it a procedure with an input parameter that is the table size, and see how big the table has to before the procedure crashes. Fiddle with the p_a_t, and w_p (they can be set separately) to see if the crash point moves.
This may give you (or Oracle Corp) some clues.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
> Hi,
>
> I have posted a problem before which I can only solve with a workaround
but
> because I'm not getting
> satisdactory answers from Oracle I'm trying alternatives.
> - problem is a batch pl/sql package which ends with ora-4030
> - batch runs fine on oracle 7.3.4, we migrated to oracle 9.2.0.4
> recently
> - setting pga_aggegrate_target=0 and workarea_size_policy=manual
> solves the error
> - This is the only batch which results in errors
>
> Due to recent posts I have tried smm_max_size set to 100Mb and I still get
> this error. All of the following
> is done with _smm_max_size set and first setting pga_aggegrate_target=50M
> and workarea_size_policy=auto
>
>
> Monitoring v$sql_workarea_active leads me a max. use of 532Kb. The
figures
> below didn't change during the batch
> I only saw temporarily another workarea for the same sid
> OPTYPE ACTTIME WA_SIZE EXP_SIZE ACT MAXMEM
PASS
> TEMPSEG TBLSP
> ---------- ---------- ---------- ---------- ---------- ---------- --------
--Received on Fri Jan 09 2004 - 16:34:35 CST
> ---------- -------------------------------
> GROUP BY ( 1378396893 532480 532480 532480 532480
0
>
> 14:30:44 SQL> /
>
> NAME
VALUE
> UNIT
> ---------------------------------------------------------------- ---------
-
> ------------
> aggregate PGA target parameter
104857600
> bytes
> aggregate PGA auto target
6553600
> bytes
> global memory bound
104857600
> bytes
> total PGA inuse
1105825792
> bytes
> total PGA allocated
1129529344
> bytes
> maximum PGA allocated
1135382528
> bytes
> total freeable PGA memory
458752
> bytes
> PGA memory freed back to OS
1303117824
> bytes
> total PGA used for auto workareas
737280
> bytes
> maximum PGA used for auto workareas
1163264
> bytes
> total PGA used for manual workareas
0
> bytes
>
> NAME
VALUE
> UNIT
> ---------------------------------------------------------------- ---------
-
> ------------
> maximum PGA used for manual workareas
16384
> bytes
> over allocation count
979
> bytes processed
3141169152
> bytes
> extra bytes read/written
0
> bytes
> cache hit percentage
100
> percent
>
> a) Why do I see manual workarea used despite workarea_size_policy=auto
?
> It is a test environment with just me and a developer on it
> b) Total pga used reports as 737Kb and total pga allocated finishes on
> 1.1Gb How can I relate this to the workarea?
> c) What's the exact connection with the _smm_max_size?
>
> When I increase the pga_aggregate_target to 2Gb and the smm_max_size also
> the program fails around
> the following numbers from pgastat
> QL> /
>
> NAME
VALUE
> UNIT
> ---------------------------------------------------------------- ---------
-
> ------------
> aggregate PGA target parameter
2147483648
> bytes
> aggregate PGA auto target
1895003136
> bytes
> global memory bound
2097152000
> bytes
> total PGA inuse
41918464
> bytes
> total PGA allocated
1137232896
> bytes
> maximum PGA allocated
1137249280
> bytes
> total freeable PGA memory
1074987008
> bytes
> PGA memory freed back to OS
131072
> bytes
> total PGA used for auto workareas
0
> bytes
> maximum PGA used for auto workareas
0
> bytes
> total PGA used for manual workareas
0
> bytes
>
> NAME
VALUE
> UNIT
> ---------------------------------------------------------------- ---------
-
> ------------
> maximum PGA used for manual workareas
2347008
> bytes
> over allocation count
0
> bytes processed
1603424256
> bytes
> extra bytes read/written
6708224
> bytes
> cache hit percentage
99.58
> percent
>
> d) What is remarkable that auto workareas are now on 0, the manual
stuff
> might be by another testuser, the total pga_allocated is just a little bit
> higher.
>
> I am completely confused by now and I hope you can shed some light on
this.
>
> Regards,
>
> Jeroen
>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: jonathan_at_jlcomp.demon.co.uk Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jeroen van Sluisdam INET: jeroen.van.sluisdam_at_vrijuit.nl Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
 |
 |