Hi!
 
Not entirely the truth. In huge reporting/OLAP environments you just can't have that much memory that all sorts are running entirely in memory. What you should look out for are multipass sorts, the ones which require reading and writing the same to disk multiple times. So keep the merge phases 0, but if not got enough memory, keep the merge phases as low as possible (1).
 
You can somewhat monitor the merge passes with following:
 
SQL> select name, value from v$sysstat where name like '%workarea%'; -- or use v$sesstat
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
workarea memory allocated                                                 0
workarea executions - optimal                                          1755
workarea executions - onepass                                             0
workarea executions - multipass                                           0
 
Also, if you use parallel queries for your reporting, it might be so that some parallel slaves do have two sort areas in use, one for sortin the queried data, other for merging the results with other slaves.
 
 
Also you could set event 10032 and play with sort_area_size (reduce it), to see when you start seeing "intermediate runs" in addition to "initial runs". But more - if you got enough memory, then keep the size at 100M and don't worry about it - Oracle only allocates that much of memory for sort that it needs, no memory is wasted.
 
Tanel.

You want a sorts to disk ratio of 1 percent or less.  To find this run this;
 
dispatch> column name format a30
dispatch> select name, value
  2  from v$sysstat
  3  where name like 'sort%';
 
NAME                               VALUE
------------------------------ ---------
sorts (memory)                    283420
sorts (disk)                          64
sorts (rows)                    29507963
 
 
the ratio of sorts = round((64/283420)*100,3)
ratio of sorts = 0.023%
 
Learned this from the Oracle DBA 101 book, one of the best buys I made.
 
Dave
-----Original Message-----
From: Bart Kersteter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2003 9:39 AM
To: Multiple recipients of list ORACLE-L
Subject: SORT_AREA_SIZE question

Hello,
 
I joined this list last week, so I apologize in advance if I'm asking a question that has previously been answered.
 
I am responsible for a reporting database/data mart that is approximately 175 GB.  Our main fact table ranges from 1-14 GB depending upon how far along we are into our financial year.  I have large reports that run full table scans on this table daily.  In an effort to keep as much of the sorting in memory as possible I have specified SORT_AREA_SIZE to be 100MB.  Some of the tuning books I am reading now are making me second-guess myself and I am wondering if this is overkill.
 
Can anyone provide some advice on how large they are setting their SORT_AREA_SIZE values for their DSS systems? 
 
Thanks in advance,
 
Bart
 

Please Note
The information in this E-mail message is legally privileged
and confidential information intended only for the use of the
individual(s) named above. If you, the reader of this message,
are not the intended recipient, you are hereby notified that
you should not further disseminate, distribute, or forward this
E-mail message. If you have received this E-mail in error,
please notify the sender. Thank you


Reply via email to