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

Similar Messages

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 HASH_AREA_SIZE

Guys,
Could someone explain the purpose of altering the SORT_AREA_SIZE and HASH_AREA_SIZE database parameters?
I had come across the following lines of code in one of my new application's package.
ALTER SESSION SET WORKAREA_SIZE_POLICY = MANUAL;
ALTER SESSION SET SORT_AREA_SIZE =xxx;
ALTER SESSION SET HASH_AREA_SIZE =yyy;
Thanks,
Bhagat

Thank you Sankar!
I've to perform ETL operation whereby it extracts data from a remote datasource,does sorting and loads into our database which involves huge amount of hash and sort.
So,I'm wondering how to dynamically set the value of either SORT_AREA_SIZE or HASH_AREA_SIZE or PGA_AGGREGATE_TARGET.Since our database is in 9i,I understand that adjusting the PGA_AGGREGATE_TARGET parameter would do the job for me.
I've read in an article that
The DBA may wish to consider dynamically changing the pga_aggregate_target parameter when any one of the following conditions are true:
Whenever the value of the v$sysstat statistic “estimated PGA memory for one-pass” exceeds pga_aggregate_target, the pga_aggregate_target should be increased.
==>How much should be the increase?
1 select name,value
2 from
3 v$pgastat
4 order by
5* value desc
SQL> /
NAME                                                                  VALUE
bytes processed                                                  1.1742E+10
aggregate PGA target parameter                                    25165824
maximum PGA allocated                                              20128768
total PGA allocated                                                17669120
aggregate PGA auto target                                          12653568
total PGA inuse                                                    11108352
global memory bound                                                 1257472
maximum PGA used for auto workareas                                  688128
cache hit percentage                                                    100
total freeable PGA memory                                                 0
PGA memory freed back to OS                                               0
NAME                                                                  VALUE
maximum PGA used for manual workareas                                     0
over allocation count                                                     0
extra bytes read/written                                                  0
total PGA used for manual workareas                                       0
total PGA used for auto workareas                                         0
SQL> select name c1,cnt c2,decode(total, 0, 0, round(cnt*100/total)) c3
2 from
3 (
4 select name,value cnt,(sum(value) over ()) total
5 from
6 v$sysstat
7 where
8 name like 'workarea exec%'
9 );
Workarea
Profile                                    Count Percentage
workarea executions - optimal          1,098,557        ###
workarea executions - onepass                  0          0
workarea executions - multipass                0          0If I've an Oracle job which runs every minute or so to check the specified values and dynamically make adjustments to pga_aggregate_target,would it be the optimal way to go about?
Many Thanks !!!!
Regards,
Bhagat
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Use of sort_area_size and sort_area_retained_size

Hi,
can u please say me what is the use of sort_area_size and sort_area_retained_size
and where to apply this parameter and will theses parameters will help in executing queries faster?
Thanks
regards
Sathish

Hello Sathish,
sort_area_size specifies the maximum amount of "memory" oracle will use for a sort. after the sort is complete oracle releases all of the memory allocated for the sort
If you have large sorts, and the memory allocated for sorts is low, then temporary tablespace would be used for sorting and therefore result in io, which means performance degradation. You might require more sort areas for inserts and updates of bitmap indexes
sort_area_retained_size specifies the amount of memory that would be retained after a sort run completes. This memory is not releases to the operating system
Where to apply these parameters... look at the statspack report and see the sorts on the disk... use of the temporary ts. If I/O for disk-sort is high, you would get benefit of using larger sort-area
yes it would help your queries to run faster... if disk-sorts are taking place
Regards
Sudhanshu

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.

Best settings for sort_area_size and temporary tablespace??

Hi, I'm trying to tune a data extract from a database which extracts records created by selects which concatenate various fields to form a record less than 100 characters long. The records are then loaded into a reporting cube.
When it is run there are 8 instances of the extract package running which write to a separate file. When the procedures are finished Unix sorts them and merges them together.
In terms of volume I am returning approx 280,000 records per day going back 4 years, with each instance of the procedure given a different date range.
Currently the average procedure takes 4 hours to complete, but the sort and merge takes a further 6 hours.
I would like to let Oracle do the sort, as even tough Oracle and unix sort the records slightly differently, this shouldn't impact the load to the reporting cube too much.
What should I set the sort_area_size to, it currently stands at 1Mb,
shared pool size is 200Mb.
Any advice is welcome!!

What should I set the sort_area_size to, it currently stands at 1Mb <<How would we know, you provide absolutely no information on user load and how much free memory your server has available. And are the sessions in question connected using dedicated sessions or shared server connections?
Based on 280K 100 byte rows per day X 4 years the sort is going to disk. I would make sure my temp tablespace was stripped accross as many disk units as possible. And you should probably verify that you have at least 22G of sort available within the database. ( I figured at 200 days of data per year not 365 so if you have data for 7 days a week the temp estimate has to go up)
HTH -- Mark D Powell --

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

ORDER BY clause introduces dramatic performance difference

Hi All,
Oracle 11G on Windows 2008 R2.
I have a basic SELECT * from TableA ORDER BY col1, col2, col3 statement that gives very different runtimes.
With the ORDER BY it takes 9 mins.
Without the ORDER BY it takes 8 seconds.
I know that ORDER BY, in general, is an expensive operation, and if possible, move that operation to the application layer but in this case it's not possible. I've read that i can adjust 1 or 2 parameters to affect how sort operations are handled by the optmizer - sort_area_size and pga_aggregate_target. The latter one being the one i'm 'supposed' to change for a better effect.
We use automatic memory management and have given Oracle db 6GB out of 16GB on the dedicated database server.
Question:
1) Any thoughts as to what i can change pga_aggregate_target to?
2) Or should i just change the AMM to get more memory and let Oracle handle the memory allocation itself, hoping that more memory will mean faster sort results?
Thx in advance.

Thank you for the tip, here are the explain plans
WITHOUT ORDER BY:
"PLAN_TABLE_OUTPUT"
"Plan hash value: 2332686131"
"| Id | Operation                         | Name                | Rows | Bytes | Cost (%CPU)| Time     |"
"|   0 | SELECT STATEMENT                  |                     |     1 |   242 | 3234   (1)| 00:00:39 |"
"|   1 | NESTED LOOPS                     |                     |       |       |            |          |"
"|   2 |   NESTED LOOPS                    |                     |     2 |    52 |     6   (0)| 00:00:01 |"
"|* 3 |    INDEX RANGE SCAN               | ISD_TRAFFIC_BOOST_I |     4 |    76 |     3   (0)| 00:00:01 |"
"|* 4 |    INDEX UNIQUE SCAN              | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 5 |   TABLE ACCESS BY INDEX ROWID     | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|   6 | NESTED LOOPS                     |                     |       |       |            |          |"
"|   7 |   NESTED LOOPS                    |                     |     2 |    44 |     6   (0)| 00:00:01 |"
"|* 8 |    INDEX RANGE SCAN               | ISD_TRAFFIC_BOOST_I |     4 |    60 |     3   (0)| 00:00:01 |"
"|* 9 |    INDEX UNIQUE SCAN              | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 10 |   TABLE ACCESS BY INDEX ROWID     | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"| 11 | NESTED LOOPS                     |                     |       |       |            |          |"
"| 12 |   NESTED LOOPS                    |                     |     1 |   242 | 3234   (1)| 00:00:39 |"
"| 13 |    NESTED LOOPS                   |                     |     1 |   233 | 3233   (1)| 00:00:39 |"
"| 14 |     NESTED LOOPS                  |                     |     1 |   222 | 3231   (1)| 00:00:39 |"
"| 15 |      NESTED LOOPS                 |                     |     1 |   214 | 3230   (1)| 00:00:39 |"
"| 16 |       NESTED LOOPS                |                     |     1 |   205 | 3229   (1)| 00:00:39 |"
"|* 17 |        HASH JOIN                  |                     |     7 | 1267 | 3222   (1)| 00:00:39 |"
"|* 18 |         TABLE ACCESS FULL         | M_REQ_TO_POS        | 3424 | 71904 |   584   (1)| 00:00:08 |"
"|* 19 |         HASH JOIN                 |                     | 3232 |   505K| 2638   (1)| 00:00:32 |"
"| 20 |          SORT UNIQUE              |                     | 4577 | 45770 |     7   (0)| 00:00:01 |"
"| 21 |           INDEX FAST FULL SCAN    | PTBP_UK             | 4577 | 45770 |     7   (0)| 00:00:01 |"
"|* 22 |          HASH JOIN                |                     | 2376 |   348K| 2630   (1)| 00:00:32 |"
"|* 23 |           HASH JOIN               |                     | 2298 |   302K| 2353   (1)| 00:00:29 |"
"|* 24 |            HASH JOIN RIGHT OUTER |                     | 2298 |   271K| 2277   (1)| 00:00:28 |"
"| 25 |             VIEW                  | index$_join$_009    |    14 |   126 |     3 (34)| 00:00:01 |"
"|* 26 |              HASH JOIN            |                     |       |       |            |          |"
"| 27 |               INDEX FAST FULL SCAN| FRT_PK              |    14 |   126 |     1   (0)| 00:00:01 |"
"| 28 |               INDEX FAST FULL SCAN| FRT_UK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|* 29 |             TABLE ACCESS FULL     | M_ITEM_SHIPS        | 2298 |   251K| 2274   (1)| 00:00:28 |"
"|* 30 |            INDEX RANGE SCAN       | APOLI_UK            | 18650 |   254K|    75   (0)| 00:00:01 |"
"| 31 |           TABLE ACCESS FULL       | M_REQ_LI_TO_POLIS   |   105K| 1541K|   276   (1)| 00:00:04 |"
"| 32 |        TABLE ACCESS BY INDEX ROWID| M_PO_LINE_ITEMS     |     1 |    24 |     1   (0)| 00:00:01 |"
"|* 33 |         INDEX UNIQUE SCAN         | POLI_PK             |     1 |       |     0   (0)| 00:00:01 |"
"| 34 |       TABLE ACCESS BY INDEX ROWID | M_UNITS             |     1 |     9 |     1   (0)| 00:00:01 |"
"|* 35 |        INDEX UNIQUE SCAN          | UNIT_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|* 36 |      TABLE ACCESS BY INDEX ROWID | M_REQS              |     1 |     8 |     1   (0)| 00:00:01 |"
"|* 37 |       INDEX UNIQUE SCAN           | R_PK                |     1 |       |     0   (0)| 00:00:01 |"
"| 38 |     TABLE ACCESS BY INDEX ROWID   | M_IDENTS            |     1 |    11 |     2   (0)| 00:00:01 |"
"|* 39 |      INDEX UNIQUE SCAN            | I_PK                |     1 |       |     1   (0)| 00:00:01 |"
"|* 40 |    INDEX UNIQUE SCAN              | CC_PK               |     1 |       |     0   (0)| 00:00:01 |"
"| 41 |   TABLE ACCESS BY INDEX ROWID     | M_COMMODITY_CODES   |     1 |     9 |     1   (0)| 00:00:01 |"
"Predicate Information (identified by operation id):"
"   3 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   4 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"   5 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"   8 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   9 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
" 10 - filter(""MRS"".""DELV_DATE_IND""='Y')"
" 17 - access(""RLTP"".""R_ID""=""RP"".""R_ID"" AND ""PTBP"".""RP_ID""=""RP"".""RP_ID"")"
" 18 - filter(""RP"".""RLI_ID"" IS NULL)"
" 19 - access(""PTBP"".""POH_ID""=""RLTP"".""POH_ID"")"
" 22 - access(""APOLI"".""POLI_ID""=""RLTP"".""POLI_ID"")"
" 23 - access(""ISH"".""PROJ_ID""=""APOLI"".""PROJ_ID"" AND ""ISH"".""POLI_ID""=""APOLI"".""POLI_ID"")"
" 24 - access(""ISH"".""FRT_ID""=""FRT"".""FRT_ID""(+))"
" 26 - access(ROWID=ROWID)"
" 29 - filter(""ISH"".""PROJ_ID""='H333966' AND UPPER(NVL(""ISH"".""OWL"",'NON')) NOT LIKE 'EXCLUDE%' "
"              AND ""ISH"".""ITEM_SHIP_QTY"">0)"
" 30 - access(""APOLI"".""PROJ_ID""='H333966')"
" 33 - access(""POLI"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"       filter(""POLI"".""POLI_ID""=""ISH"".""POLI_ID"")"
" 35 - access(""QTY_UNIT"".""UNIT_ID""=""ISH"".""QTY_UNIT_ID"")"
" 36 - filter(""R"".""R_SUPP""=""M_PCK_EXPED_WORKLOAD"".""GET_MAX_ISH_R_SUPPL""(""POLI"".""POLI_ID""))"
" 37 - access(""R"".""R_ID""=""RP"".""R_ID"")"
" 39 - access(""MI"".""IDENT""=""POLI"".""IDENT"")"
" 40 - access(""MI"".""COMMODITY_ID""=""MCC"".""COMMODITY_ID"")"WITH THE ORDER BY:
"PLAN_TABLE_OUTPUT"
"Plan hash value: 3346887832"
"| Id | Operation                          | Name                | Rows | Bytes | Cost (%CPU)| Time     |"
"|   0 | SELECT STATEMENT                   |                     |     1 |   242 | 3235   (1)| 00:00:39 |"
"|   1 | NESTED LOOPS                      |                     |       |       |            |          |"
"|   2 |   NESTED LOOPS                     |                     |     2 |    52 |     6   (0)| 00:00:01 |"
"|* 3 |    INDEX RANGE SCAN                | ISD_TRAFFIC_BOOST_I |     4 |    76 |     3   (0)| 00:00:01 |"
"|* 4 |    INDEX UNIQUE SCAN               | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 5 |   TABLE ACCESS BY INDEX ROWID      | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"|   6 | NESTED LOOPS                      |                     |       |       |            |          |"
"|   7 |   NESTED LOOPS                     |                     |     2 |    44 |     6   (0)| 00:00:01 |"
"|* 8 |    INDEX RANGE SCAN                | ISD_TRAFFIC_BOOST_I |     4 |    60 |     3   (0)| 00:00:01 |"
"|* 9 |    INDEX UNIQUE SCAN               | RMS_PK              |     1 |       |     0   (0)| 00:00:01 |"
"|* 10 |   TABLE ACCESS BY INDEX ROWID      | M_RM_SCHEDULES      |     1 |     7 |     1   (0)| 00:00:01 |"
"| 11 | SORT ORDER BY                     |                     |     1 |   242 | 3235   (1)| 00:00:39 |"
"| 12 |   NESTED LOOPS                     |                     |       |       |            |          |"
"| 13 |    NESTED LOOPS                    |                     |     1 |   242 | 3234   (1)| 00:00:39 |"
"| 14 |     NESTED LOOPS                   |                     |     1 |   233 | 3233   (1)| 00:00:39 |"
"| 15 |      NESTED LOOPS                  |                     |     1 |   222 | 3231   (1)| 00:00:39 |"
"| 16 |       NESTED LOOPS                 |                     |     1 |   214 | 3230   (1)| 00:00:39 |"
"| 17 |        NESTED LOOPS                |                     |     1 |   205 | 3229   (1)| 00:00:39 |"
"|* 18 |         HASH JOIN                  |                     |     7 | 1267 | 3222   (1)| 00:00:39 |"
"|* 19 |          TABLE ACCESS FULL         | M_REQ_TO_POS        | 3424 | 71904 |   584   (1)| 00:00:08 |"
"|* 20 |          HASH JOIN                 |                     | 3232 |   505K| 2638   (1)| 00:00:32 |"
"| 21 |           SORT UNIQUE              |                     | 4577 | 45770 |     7   (0)| 00:00:01 |"
"| 22 |            INDEX FAST FULL SCAN    | PTBP_UK             | 4577 | 45770 |     7   (0)| 00:00:01 |"
"|* 23 |           HASH JOIN                |                     | 2376 |   348K| 2630   (1)| 00:00:32 |"
"|* 24 |            HASH JOIN               |                     | 2298 |   302K| 2353   (1)| 00:00:29 |"
"|* 25 |             HASH JOIN RIGHT OUTER |                     | 2298 |   271K| 2277   (1)| 00:00:28 |"
"| 26 |              VIEW                  | index$_join$_009    |    14 |   126 |     3 (34)| 00:00:01 |"
"|* 27 |               HASH JOIN            |                     |       |       |            |          |"
"| 28 |                INDEX FAST FULL SCAN| FRT_PK              |    14 |   126 |     1   (0)| 00:00:01 |"
"| 29 |                INDEX FAST FULL SCAN| FRT_UK              |    14 |   126 |     1   (0)| 00:00:01 |"
"|* 30 |              TABLE ACCESS FULL     | M_ITEM_SHIPS        | 2298 |   251K| 2274   (1)| 00:00:28 |"
"|* 31 |             INDEX RANGE SCAN       | APOLI_UK            | 18650 |   254K|    75   (0)| 00:00:01 |"
"| 32 |            TABLE ACCESS FULL       | M_REQ_LI_TO_POLIS   |   105K| 1541K|   276   (1)| 00:00:04 |"
"| 33 |         TABLE ACCESS BY INDEX ROWID| M_PO_LINE_ITEMS     |     1 |    24 |     1   (0)| 00:00:01 |"
"|* 34 |          INDEX UNIQUE SCAN         | POLI_PK             |     1 |       |     0   (0)| 00:00:01 |"
"| 35 |        TABLE ACCESS BY INDEX ROWID | M_UNITS             |     1 |     9 |     1   (0)| 00:00:01 |"
"|* 36 |         INDEX UNIQUE SCAN          | UNIT_PK             |     1 |       |     0   (0)| 00:00:01 |"
"|* 37 |       TABLE ACCESS BY INDEX ROWID | M_REQS              |     1 |     8 |     1   (0)| 00:00:01 |"
"|* 38 |        INDEX UNIQUE SCAN           | R_PK                |     1 |       |     0   (0)| 00:00:01 |"
"| 39 |      TABLE ACCESS BY INDEX ROWID   | M_IDENTS            |     1 |    11 |     2   (0)| 00:00:01 |"
"|* 40 |       INDEX UNIQUE SCAN            | I_PK                |     1 |       |     1   (0)| 00:00:01 |"
"|* 41 |     INDEX UNIQUE SCAN              | CC_PK               |     1 |       |     0   (0)| 00:00:01 |"
"| 42 |    TABLE ACCESS BY INDEX ROWID     | M_COMMODITY_CODES   |     1 |     9 |     1   (0)| 00:00:01 |"
"Predicate Information (identified by operation id):"
"   3 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   4 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
"   5 - filter(""MRS"".""DELV_DATE_IND""='Y')"
"   8 - access(""MISD"".""ITEM_SHIP_ID""=:B1)"
"   9 - access(""MRS"".""RMS_ID""=""MISD"".""RMS_ID"")"
" 10 - filter(""MRS"".""DELV_DATE_IND""='Y')"
" 18 - access(""RLTP"".""R_ID""=""RP"".""R_ID"" AND ""PTBP"".""RP_ID""=""RP"".""RP_ID"")"
" 19 - filter(""RP"".""RLI_ID"" IS NULL)"
" 20 - access(""PTBP"".""POH_ID""=""RLTP"".""POH_ID"")"
" 23 - access(""APOLI"".""POLI_ID""=""RLTP"".""POLI_ID"")"
" 24 - access(""ISH"".""PROJ_ID""=""APOLI"".""PROJ_ID"" AND ""ISH"".""POLI_ID""=""APOLI"".""POLI_ID"")"
" 25 - access(""ISH"".""FRT_ID""=""FRT"".""FRT_ID""(+))"
" 27 - access(ROWID=ROWID)"
" 30 - filter(""ISH"".""PROJ_ID""='H333966' AND UPPER(NVL(""ISH"".""OWL"",'NON')) NOT LIKE 'EXCLUDE%' AND "
"              ""ISH"".""ITEM_SHIP_QTY"">0)"
" 31 - access(""APOLI"".""PROJ_ID""='H333966')"
" 34 - access(""POLI"".""POLI_ID""=""APOLI"".""POLI_ID"")"
"       filter(""POLI"".""POLI_ID""=""ISH"".""POLI_ID"")"
" 36 - access(""QTY_UNIT"".""UNIT_ID""=""ISH"".""QTY_UNIT_ID"")"
" 37 - filter(""R"".""R_SUPP""=""M_PCK_EXPED_WORKLOAD"".""GET_MAX_ISH_R_SUPPL""(""POLI"".""POLI_ID""))"
" 38 - access(""R"".""R_ID""=""RP"".""R_ID"")"
" 40 - access(""MI"".""IDENT""=""POLI"".""IDENT"")"
" 41 - access(""MI"".""COMMODITY_ID""=""MCC"".""COMMODITY_ID"")"

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

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 --

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.

SGA_MAX_SIZE and SGA_TARGET in Oracle 10G

We have the following H/W with Solaris 9
SPARC-IV 16 CPUs
32GB RAM
128GB swap
What is the optimal size of sga_target and sga_max_size that can be configured for a heavy batch processing oracle server. Nothing runs except oracle in the above server.
We have currently 3GB SGA size , however our heavy queries are very slow.
We have huge updates on tables with more than 200Millions rows.
Do we need to have JAVA_POOL if the java stored procedure are NOT used.
However we are connecting to this database using JDBC also.
Moreover ASM is enabled in this server.
You expert suggetions are always welcome.

That's not a question that can be answered easily. It depends very much on where the time is going. Three main targets:
Writing the log file - which is largely about use of disks, not memory.
Reading data - lots of single block reads suggest looking at a bigger cache
Reading and writing temp because of large sorts/hash joins - pga configuration
One difficulty with TEMP is that the I/Os are often asynchronous, so a session can do a lot of TEMP I/O without recording much time - which means it can cause a problem elsewhere without suffering a problem itself.
You didn't mention the pga_aggregate_size - which is an important consideration in 10g and can be more important than the sga sizing in DSS and batch-like processing. Between them, the SGA and PGA_aggregate_target should probably account for a very large fraction of your memory - but (since you are on Solaris) make sure you look into large memory pages and intimate shared memory, otherwise you may need to leave a lot of memory available for the O/S memory management mechanisms.
As far as the java pool is concerned, check v$sgastat for pools which constantly show free memory, and reclaim any large free volumes.
Bottom line - if you've got the memory in the box, you might as well use it in the best possible place; but at the moment we don't have enough information to tell us where it would be most useful.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Sga_max_size and sga_target values

I have an 11g database on windows with 4GB RAM, I have set the MEMORY_MAX_TARGET and MEMORY_TARGET, what should I do with the pre-existing sga_max_size and sga_target values

memory_target = sga_target + max(pga_aggregate_target, maximum PGA allocated)
MEMORY_MAX_TARGET = sum of the SGA and instance PGA sizes.
For Automatic memory management
set
ALTER SYSTEM SET SGA_TARGET = 0;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 0;
Note:
In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a nonzero value, provided that it does not exceed the value of MEMORY_MAX_TARGET.
Note:
The preceding steps instruct you to set SGA_TARGET and PGA_AGGREGATE_TARGET to zero so that the sizes of the SGA and instance PGA are tuned up and down as required, without restrictions. You can omit the statements that set these parameter values to zero and leave either or both of the values as positive numbers. In this case, the values act as minimum values for the sizes of the SGA or instance PGA.
Reference

Session and memory details!

Hi!
My log file shows as follows:
metrics Web threads (busy/total): 0/5 Sessions: 575 Total Memory=57624 Free=25022
What's does it mean?Is it a good sign?I am having 575 live sessions?Can anybody explain pl!Thanks

Dear Mark.
Thanks for your reply.
I have tested how much connection is possible by changing the value of
large pool and java pool. Shared pool and pga_aggregate_target are the same.
The database is 10.2.0.2.0 and the os is 32-bit windows enterprise edition sp1.
Thus, there is 2Giga limitation in memory usage for oracle without VLM
configuration.
<pre>
TEST 1 TEST2
Shared Pool     500     500
Large Pool      50     33
Java Pool     50     33
PGA     500     500
</pre>
In test1, the max number of connection is 329.
In test2, the max number of connection is 351.
In both test1 and test2, the size of shared pool and pga are the same.
I just decrease large pool size and java pool size about 34Mega bytes.
As a result, 21 more connection was successful.
I think this means that a session memory is allocated to other area
outside sga and pga.
Thanks and Regards.
Message was edited by:
user507290

SORT_AREA_SIZE and PGA_AGGREGATE_TARGET

Similar Messages

Maybe you are looking for