Sort_area_size & pga_aggregate_target

Hi,
There is an ETL load job which is failing frequently because of TEMP tablespace issue. I have already extended the temp tablespace from about 6GB to 37GB.
Code is definately an issue. However we can not possibly change it.
I wanted to know what is the difference between sort_area_size and pga_aggregate_target? Can someone please explain these and the scenrios when we need to set which parameter?
Current Environment:
Oracle Database: 10.2.0.3
Platform: HP-UX
SQL> show parameter sort_area
NAME TYPE VALUE
sort_area_retained_size integer 1524288
sort_area_size integer 1524288
SQL> show parameter pga_aggregate
NAME TYPE VALUE
pga_aggregate_target big integer 524288000
SQL> select sum(bytes)/1024/1024/1024 db_size_gb from dba_data_files;
DB_SIZE_GB
108.447266
SQL> select sum(bytes)/1024/1024/1024 db_size_gb from v$tempfile;
DB_SIZE_GB
37.109375
SQL>
Regards
Sudhanshu

pga_aggregate_target is set and automatically sets workarea_size_policy = auto. It is used for sorts, hash joins etc operations. But it is set for all db level and a single session cannot use more than ~5% of it. So if you have one session that has many memory intensive memory operations it might be very useful to set workarea_size_policy = manual and set big sort/hash_area_sizes. Available mmemory VERY MUCH affects large sorts and hash_joins, for exact example how much - you can look at my article Long running Operations in Oracle (entries in v$session_longops) at http://www.gplivna.eu/papers/v$session_longops.htm under the chapter Hash joins can either fly or crawl.
Gints Plivna
http://www.gplivna.eu

Similar Messages

Need help to reduce execution time for a procedure

the following procedure takes to long to execute and the server times out. each individual select works perfectly. It does not have to do with the SORT_AREA_SIZE/PGA_AGGREGATE_TARGET not being large enough. Possible rewriting it in funcions might help i don't know.
Thanks in advance
PROCEDURE GET_RM_WORKABILITY_BY_PLANT
            (p_in_plantcode IN VARCHAR2,
            p_in_statusnum IN NUMBER,
            p_out_cursor     IN OUT tcursor) AS
    BEGIN
      OPEN p_out_cursor FOR
          select comp.segment1,
                  comp.description,
                  comp.organization_id,
                  nvl(sum(jot.qty), 0) job_qty,
                  nvl(moq.qty, 0) onhand_qty
          from   (select jdl.bill_sequence_id bsid,
                            sum(jdl.job_qty) qty
                  from        job_detail_lines jdl
                  where   jdl.job_stat = p_in_statusnum
                    and   jdl.prod_plant_id = p_in_plantcode
                  group by jdl.bill_sequence_id) jot,
                  (select m.inventory_item_id,
                               sum(m.transaction_quantity) qty
                    from   mtl_onhand_quantities m
                    where exists
                              (select 'x'
                             from   plant_codes p1,
                                      plant_codes p
                              where p.plant_code = p_in_plantcode
                                and p1.fac_id = p.fac_id
                                and m.organization_id = p1.organization_id)
                    group by m.inventory_item_id) moq,
                    (select msi.segment1,
                            msi.description,
                            msi.organization_id,
                            msi.inventory_item_id,
                            bom.bill_sequence_id
                    from   bom.bom_bill_of_materials bom,
                            bom.bom_inventory_components bic,
                            mtl_system_items msi,
                            plant_codes pc
                    where pc.plant_code = p_in_plantcode
                      and msi.organization_id = pc.organization_id
                      and msi.item_type||'' IN ('PSSRM', 'PSRM')
                      and bic.component_item_id = msi.inventory_item_id
                      and ((bic.disable_date IS NULL AND SYSDATE>= bic.effectivity_date)
                              or (SYSDATE <= bic.disable_date AND SYSDATE >= bic.effectivity_date))
                      and bom.bill_sequence_id = bic.bill_sequence_id
                      and bom.organization_id = 102) comp
          where moq.inventory_item_id(+) = comp.inventory_item_id
            and jot.bsid(+) = comp.bill_sequence_id
          group by comp.segment1,
                       comp.description,
                     comp.organization_id,
                     moq.qty;
END;

Ok, so how does it perform if you use the bom info as an in-line query outer join to job detail lines?
SELECT v.plant_code,
       v.segment1,
       v.description,
       v.organization_id,
       v.inventory_item_id,
       SUM (jdl.job_qty) job_qty
FROM (
SELECT pc.plant_code,
       msi.segment1,
       msi.description,
       msi.organization_id,
       msi.inventory_item_id,
       bom.bill_sequence_id
FROM bom.bom_bill_of_materials bom,
       bom.bom_inventory_components bic,
       mtl_system_items msi,
       plant_codes pc
WHERE pc.plant_code = p_in_plantcode
   AND msi.organization_id = pc.organization_id
   AND msi.item_type || '' IN ('PSSRM', 'PSRM')
   AND bic.component_item_id = msi.inventory_item_id
   AND bic.effectivity_date <= SYSDATE
   AND (   bic.disable_date IS NULL
        OR bic.disable_date >= SYSDATE)
   AND bom.bill_sequence_id = bic.bill_sequence_id
   AND bom.organization_id = 102
       ) v,
       job_detail_lines jdl
WHERE jdl.prod_plant_id(+) = v.plant_code
   AND jdl.bsid(+) = v.bill_sequence_id
   AND jdl.job_stat(+) = p_in_statusnum
GROUP BY
       v.plant_code,
       v.segment1,
       v.description,
       v.organization_id,
       v.inventory_item_id;

Benchmarks on select statements

Hi,
I'm during preparing test on select statement to check what clause cause the most slow down. Therefore I prepare 3 select statement:
1) select which transform all columns in source table for oracle's functions like: substr, rpad, decode, nvl,upper, mod, greatest, length, power, instr etc..
2) select with big where clause (about 7 lines) which take from 2 tables
3) select which have where, group by, having and order by clauses
Perhaps I will have first result today. But I am very interested what is your experience in this subject?? Which case cause the biggest slow down?
Best.

Hi Tut,
what is your experience in this subject?? Every database is different, but in general:
1) select which transform all columns in source table for oracle's functions like: substr, rpad, decode, nvl,upper, mod, greatest, length, power, instr etc..Very low overhead.
2) select with big where clause (about 7 lines) which take from 2 tablesLong time to parse, and sometime Oracle does not get the cardinality right and joins the tables in the wrong order. To fix this issue:
1 - apply histograms. I have my notes here: http://www.dba-oracle.com/art_otn_cbo_p4.htm
2 - Use an ORDERED hint to enforce the best table join order: I have my notes here: http://www.dba-oracle.com/t_table_join_order.htm
3) select which have where, group by, having and order by clausesJust make sure that you have a large enough PGA to void sorts to disk (sort_area_size, pga_aggregate_target)
Hope this answers your questions . . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference":
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Query slower due to sorting('order by')

I have a query which when sorted is about 5 times slower.
The 'order by' is on 3 different fields from 3 different tables, there are indexes present for all 3 columns. The number of records returned is about 5000.
Any Ideas !!

Sinantopuz was on to something -- but we could be talking about memory versus disk. Is SORT_AREA_SIZE too small? Or maybe you are using PGA_AGGREGATE_TARGET?
If WORKAREA_SIZE_POLICY = AUTO, then reference PGA_AGGREGRATE_TARGET (show parameters pga_aggregate_target in SQL*Plus).
Otherwise, review the SORT_AREA_SIZE.
The SET AUTOTRACE will show disk sorts versus memory sorts. Disk sorts should be avoided by increasing your sort area (SORT_AREA_SIZE, PGA_AGGREGATE_TARGET, maybe even HASH_AREA_SIZE).
Good luck.

Minimum parameters and values required for 11g database

Hi
Can anyone please provide me with the list of parameters and the minimum value required for these parameters in 11g database (11.1.0.6.0).
Thanks

user8940828 wrote:
Thanks for your help
But this basic parameters did not mention the following parmeters . What can be the mimimum value that can be assigned to these parameters.
dml_locks
log_checkpoint_interval
log_checkpoint_timeout
open_cursors
open_links
parallel_max_servers
processes
session_cached_cursors
session_max_open_files
job_queue_processes
log_buffer
shared_pool_size
sort_area_retained_size
sort_area_size
db_cache_size
pga_aggregate_target
ThanksI suggest you to start letting the default parameters and then tune them step-by-step.
Eg:
- open_links => If you dont have database links you can avoid to set it.
- processes: number of backgroud processes + expected session/users for your application. if you have 1000 users connecting at the same time you would set a value higher than 1000.
- shared_pool_size, db_cache_size, sort_area_size, pga_aggregate_target are not mandatory if you use automatic memory management by Oracle.
- etc.

Pga_aggregate_target and sort_area_size

Hi. all.
when using pga_aggregate_target, sort_area_size is meaningless?
Or, I have to set sort_area_size=0??
- pga_aggregate_target=500M
- workarea_size_policy=auto
- sort_area_size=65536
Thanks and regards.

May be this can help you understand in more detail.
PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server processes attached to the instance.
Setting PGA_AGGREGATE_TARGET to a nonzero value has the effect of automatically setting the WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working areas used by memory-intensive SQL operators (such as sort, group-by, hash-join, bitmap merge, and bitmap create) will be automatically sized. A nonzero value for this parameter is the default since, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever is greater.
Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL workareas are sized using the AREASIZE parameters.
Oracle attempts to keep the amount of private memory below the target specified by this parameter by adapting the size of the work areas to private memory. When increasing the value of this parameter, you indirectly increase the memory allotted to work areas. Consequently, more memory-intensive operations are able to run fully in memory and less will work their way over to disk.
When setting this parameter, you should examine the total memory on your system that is available to the Oracle instance and subtract the SGA. You can assign the remaining memory to PGA_AGGREGATE_TARGET.

SORT_AREA_SIZE and PGA_AGGREGATE_TARGET

I am using SAP R/3 kernel 4.6D with oracle 10g.
I found that in init.ora file SORT_AREA_SIZE is still defined even if the PGA_AGGREGATE_TARGET is defined and since the datbase is 10G WORK_AREA_SIZE_POLICY is by default auto.
I would like to know is the SORT_AREA_SIZE is required specifically (I mean to say whether SAP uses anywhere in its application "alter session set workarea_size_policy = manual;" kinda statement?) for SAP otherwise automatic PGA management is supposed to manage the scenario...
Shall I remove SORT_AREA_SIZE from the init.ora?
Regards,

SORT_AREA_SIZE is no longer required in SAP environments as soon as you set WORKAREA_SIZE_POLICY = AUTO.
Kind regards
Martin

How to increase the size of sort_area_size

How to increase the size of sort_area_size and what size should be according to the PROD database
Thanks

user10869960 wrote:
Hi,
Many Thanks Charles
Oracle does not recommend using the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option. Oracle recommends that you enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead. SORT_AREA_SIZE is retained for backward compatibility."
--How can i know the instance is configured with the shared server option or not?This might be a tough question to answer. A shared server configuration may be enabled, but the clients may still connect using dedicated sessions, in which case PGA_AGGREGATE_TARGET would still apply.
From
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2088.htm
V$SESSION includes a column named SERVER which will contain one of the following for each of the sessions: DEDICATED, SHARED, PSEUDO, or NONE. As a quick check, you could query V$SESSION to see if any sessions are connected using a shared server connection.
From:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/manproc.htm
There are several parameters which are used to configure shared server support, as well as several views to monitor shared server.
As Robert mentioned, when the WORKAREA_SIZE_POLICY is set to AUTO, the SORT_AREA_SIZE setting is not used, unless a shared server configuration is in use.
--What default value is WORKAREA_SIZE_POLICY and SORT_AREA_SIZE ?From:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams157.htm
"Setting PGA_AGGREGATE_TARGET to a nonzero value has the effect of automatically setting the WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working areas used by memory-intensive SQL operators (such as sort, group-by, hash-join, bitmap merge, and bitmap create) will be automatically sized. A nonzero value for this parameter is the default since, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever is greater."
Actually I am facing performence issue since long time till now i did not get the solution even i have raised SRs but i could not.When the issue occur system seems hang.what i monitored whenever hdisk0 and hdisk1 use 100% the issue occur.
Regards,
SajidWhen you say that you have had a performance issue for a long time, is it a performance problem faced by a single SQL statement, a single user, a single application, or everything on the server? If you are able to identify a single user, or SQL statement that is experiencing poor performance, I suggest starting with a 10046 trace at level 8 (wait events) or level 12 (wait events and bind variables) to determine why the execution appears to be slow. If you have not yet determined a specific user or SQL statement that is experiencing performance problems, you might start with either a Statspack Report or an AWR Report (AWR requires a separate license).
If you believe that temp tablespace usage may be a contributing factor to the performance problem, you may want to periodically run this query, which will indicate currently in use temp tablespace usage:
{code}
SELECT /*+ ORDERED */
TU.USERNAME,
S.SID,
S.SERIAL#,
S.SQL_ID,
S.SQL_ADDRESS,
TU.SEGTYPE,
TU.EXTENTS,
TU.BLOCKS,
SQL.SQL_TEXT
FROM
V$TEMPSEG_USAGE TU,
V$SESSION S,
V$SQL SQL
WHERE
TU.SESSION_ADDR=S.SADDR
AND TU.SESSION_NUM=S.SERIAL#
AND S.SQL_ID=SQL.SQL_ID
AND S.SQL_ADDRESS=SQL.ADDRESS;
{code}
The SID and SERIAL# returned by the above could then be used to enable a 10046 trace for a session. The SQL_ID (and CHILD_NUMBER from V$SESSION in recent releases) could be used with DBMS_XPLAN.DISPLAY_CURSOR to return the execution plan for the SQL statement.
You could also take a look in V$SQL_WORKAREA_ACTIVE to determine which, if any, SQL statement are resulting in single-pass, or multi-pass executions, which both access the temp tablespace.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Sort_area_size & hash_area_size on 10g

I am confused as to whether I need to have sort_area_size and hash_area size set in my 10.2.0.3 database. I know the Oracle documentation states the following:
"Oracle does not recommend using the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option. Oracle recommends that you enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead." This is the same statement made for hash_area_size as well.
I have SHARED_SERVERS set to 1. So do I need to have sort_area_size and hash_area_size configured? Or will pga_aggregate_target take over anyway?
And does anyone have any suggestions on sizing pga_aggregate_target?
Oracle Doc says 20% of SGA. And I have seen recommendations where SGA should be sized 60-80% of total memory. Seems extreme.

It is extreme. The SGA can be anywhere from 5% - 50% of the total memory depending on the size of memory, size of the database, type of database application (OLTP, Warehouse, DSS, OLAP), and user load.
What else is on the machine besides the database is a big factor in how much memory can be allocated.
Metalink has documents on sizing the SGA. You can size the PGA based on the expected concurrent user session count X an average memory per user + some extra for the unusual. How much memory you need per user depends on the application code tool set and coding stype.
It is a bit of a guessing game. I like to start small but probably adequate allocation and add more resource as the load grows based on statistics.
HTH -- Mark D Powell --
HTH -- Mark D Powell --

SORT_AREA_SIZE+Oracle dedicated servers

Hi Friends,
I am using Oracle 10g server release 2,Today i have gone through the Orcale docs,its written there that
"Oracle does not recommend using the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option. Oracle recommends that you enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead. SORT_AREA_SIZE is retained for backward compatibility"
My database is designed in dedicated mode..now how to handle large sorts in that case,as oracle recommends something different
thanx
somy

Oracle document covers nicely the [PGA Memory Management|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#PFGRF01401]
Check out [V$PGA_TARGET_ADVICE|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#i49570] for getting an idea about the ideal size of your PGA.
Thanks,
Karthick.

Sorts and pga_aggregate_target

Hi All,
I am on Oracle v11.2.
I would like to verify my understanding of pga_aggregate_target here.
Query and plan of the same query shown below
SQL> select name, value from v$parameter where name like '%area_size' or name like 'pga%';
NAME                           VALUE
create_bitmap_area_size        8388608
bitmap_merge_area_size         1048576
hash_area_size                 131072
sort_area_size                 65536
pga_aggregate_target           2147483648
5 rows selected.
Elapsed: 00:00:00.11
SQL>
SQL> set autotrace on
SQL>
SQL> select * from ( select * from TABLE_A order by ap_first_inserted desc ) where rownum < 11 ;
                             ..... Output data ..........
10 rows selected.
Elapsed: 00:00:55.11
Execution Plan
Plan hash value: 712899093
| Id | Operation               | Name         | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT        |              |    10 |   870 |       |   823K (1)| 02:44:37 |
|* 1 | COUNT STOPKEY          |              |       |       |       |            |          |
|   2 |   VIEW                  |              |    50M| 4199M|       |   823K (1)| 02:44:37 |
|* 3 |    SORT ORDER BY STOPKEY|              |    50M| 2751M| 3876M|   823K (1)| 02:44:37 |
|   4 |     TABLE ACCESS FULL   | TABLE_A      |    50M| 2751M|       |   122K (1)| 00:24:30 |
Predicate Information (identified by operation id):
   1 - filter(ROWNUM<11)
   3 - filter(ROWNUM<11)
Statistics
          1 recursive calls
          0 db block gets
     446865 consistent gets
     446755 physical reads
          0 redo size
       1028 bytes sent via SQL*Net to client
        359 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
         10 rows processedTABLE_A has 50 million records.
Am I correct in saying that, this query, mainly the SORT operation is completly executed in memory (stats after plan show "0" sorts (disk) ) ?
In the plan, under columns TempSpc, it shows "3876M". What is this? does that mean 3876 MB of space ? in that case it is much bigger than the 2GB pga_aggregate_target or it is 3876 million bytes (which is still 3 and half GB) ? if the size of data being sorted exceeds 2GB, will Oracle use disk space?
I checked in DBA_SEGMENTS, the data segment of TABLE_A has taken up about 3.5GB space.
Thanks in advance.

Thanks Jonathan.
So, basically due to the rownum filter, not much memory/disk space was used.
I ran another query which uses dense_rank function and it produced this stats
Statistics
       2631 recursive calls
      66486 db block gets
      44394 consistent gets
      54296 physical reads
   61478516 redo size
        775 bytes sent via SQL*Net to client
       4179 bytes received via SQL*Net from client
          4 SQL*Net roundtrips to/from client
          1 sorts (memory)
          1 sorts (disk)
    1006295 rows processedThere was 1 memory sort and 1 disk sort.
The parameters are like
SQL> select name, value from v$parameter where name like '%area_size' or name like 'pga%';
NAME                           VALUE
create_bitmap_area_size        8388608
bitmap_merge_area_size         1048576
hash_area_size                 10485760
sort_area_size                 10485760
pga_aggregate_target           0
5 rows selected.But this is a QA database.
The production database has parameters
SQL> select name, value from v$parameter where name like '%area_size' or name like 'pga%';
NAME                           VALUE
create_bitmap_area_size        8388608
bitmap_merge_area_size         1048576
hash_area_size                 131072
sort_area_size                 65536
pga_aggregate_target           2147483648
5 rows selected.Now, as the documentation says (v11.2), pga_aggregate_target parameter will be in effect in case of the prod database. Am I correct in saying that, if my query gets enough memory allocation from pga_aggregate_target (of 2GB), there should be no need of any disk sorting?

SORT_AREA_SIZE and blob update in plsql?

Can someone please answer the below questions I have.
- The tables t1 and t2 both have around 1.5 million rows.
- Table t1 has PK defined on col1 and col2
- Table t2 has unique index defined on col1 and col2
1) Does the below query use the SORT_AREA_SIZE while running the query?
2) The below query when explain planned uses NESTED LOOP and FULL TABLE SCAN on table2. I am currently running the below in a cursor for loop to update a blob column on table1. It is taking long time? What are the alternative ways I can tune this query or tune PLSQL to update blob columns in table t1.
<pre>
SELECT rownum as rec, t1.col1, t1.col2, t2.col1, t2.col2,
replace(replace(t2.col1, 'str1','strn'), 'str2','strn')
FROM table1 t1, table2 t2
where t1.col1 = t2.col1
and t1.col2 = t2.col2
</pre>
<pre>
<b>EXPLAIN PLAN OUTPUT</b>
OPERATION OPTIONS OBJECT_NAME POSITION
SELECT STATEMENT 408
COUNT 1
NESTED LOOPS 1
TABLE ACCESS FULL TABLE2 1
INDEX UNIQUE SCAN SYS_C000001 2
</pre>

It's a little hard to read your post. If you use any HTML tags then all bbcode tags are ignored - perhaps you included some HTML tags when you posted?
Anyway, the AREASIZE settings depend on your Oracle version. From 9i onwards they are not used if workarea_size_policy is set to AUTO, in which case a percentage of pga_aggregate_target is used instead.

Temp Tablespace Extent Management and workarea_size_policy / sort_area_size

So, in the past (8i etc) we used to size temporary tablespace like (n*sort_area_size) + db_block_size.
Now in 9i / 10g we have the workarea_size_policy setting and pga_aggregate_target. How would we set extent sizes for the temporary tablespace? We let Oracle control the areasize parameters on the fly.
Any suggestions out there? Typically, I like 1MB for no particular reason other than it matches my stripe size on the underlying disk. However, oracle will only write in chunks of your sort_area_size.
Are there any guidelines out there where we can guess at what Oracle will use for the Sort_area_size?
Thanks,
BradW

Thanks. I realize that. The only thing I was wondering about is what to set the extent sizes to be for the locally managed temp tablespace.
I was curious what Oracle will set the sort_area_size to be during run time with in the PGA aggregate we specify....
Just curious on the internal mechanisms so that I can tweak my temp tablespace a little bit.
Thanks,
BradW

ORA-12500 and sort_area_size value

Hi,
I've hit an ORA-12500 'listener failed to start a dedicated server process' error after the increase of sort_area_size from 250M to 500M. DB server has plenty of RAM which would easily accomodate additinal memory for PGA. Has anyone experinced that before? Thanks.

There's (normally) no need to set SORT_AREA_SIZE, when a PGA is configured. From the parameter reference:
Oracle does not recommend using the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option. Oracle recommends that you enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead. SORT_AREA_SIZE is retained for backward compatibility.
Werner

DOUBT REGARDING SORT_AREA_SIZE

Hello,
me a Jr.Dba when i executed a large query which contains indexes so many
disks sorts are happening.so i wan't to increase the SORT_AREA_SIZE.
If i wan't to increase BUFFER_CACHE_SIZE i simply take the assistance of
V$DB_CACHE_ADVICE to know what is the next efficient value for BUFFER_CACHE_SIZE .
like the above is there any thing else for SORT_AREA_SIZE ,i am not gettitng
how much i should increase the parameter SORT_AREA_SIZE.Can u plz assist me on this
Regards,
Vamsi

Hi user581473,
if you are running on 9i and above SORT_AREA_SIZE will not be effective at all as long as you have not set WORKAREA_SIZE_POLICY to MANUAL.
It defaults to AUTO!
As of 9i we have PGA_AGGREGATE_TARGET which is used a pool for PGA memory needed for workareas.
Only if you set this to MANUAL the paramteres SORT_AREA_SIZE, CREATE_BITMAP_AREA_SIZE and HASH_AREA_SIZE will be effective.
Otherwise the optimizer thinks that every sorting can get 5% of PGA_AGGREGATE_TARGET for serial and 30% for parallel execution for the sorting in memory and create an execution plan based on this assumption.
This applies only to dedicated servers in 9i and to shared servers as well as of 10g.
If you are running a large operation you should set WORK_AREA_SIZE_POLICY to MANUAL on session level and also adjust your AREASIZE parameters for this session.
So the reports and batch jpobs use manual PGA management and all the others (OLTP) can use the default.
Hope it helps,
=;-)

Sort_area_size & pga_aggregate_target

Similar Messages

Maybe you are looking for