Performace Tuning concern

Hi All,
I have been going through Performance Tuning in oracle database and I have come accross some ambigious contents regarding the below mentioned two points.
1.AMM:It is recommended by oracle to use AMM from 10g onwards as it handles the memory allocation to SGA components on its own but I have also read a case study posted by some XYZ dba saying that AMM was found to degrade the perfromance of their database instead of the other way round.
2.Commit:Does frequent commit after transactions improve the performace or does it degrades it?
Appreciate your Inputs on this.
Regards,
Sphinx

$phinx19 wrote:
1.AMM:It is recommended by oracle to use AMM from 10g onwards as it handles the memory allocation to SGA components on its own but I have also read a case study posted by some XYZ dba saying that AMM was found to degrade the perfromance of their database instead of the other way round.All databases instances are not used equally and for the same purposes. There a huge chasms of differences between Oracle instances - from h/w architecture, to s/w architecture.
So a recommendation, like using AMM, does not necessarily hold true for every single Oracle instance and all situations.
2.Commit:Does frequent commit after transactions improve the performace or does it degrades it?Wrong question IMO.
Correct question: Do you want to muck up the integrity of the business transaction by committing a single business transaction piecemeal via multiple database transactions?

Similar Messages

Performace Tuning

Hi Gurus ,
I know the basic funds of performace tuning.But Can you please tell me the best step by step how to do performace tuning on a production server .Guide for sql tuning,Database tuning,Operating System Tuning.
I give interview in oracle last day but in last round one of manager rejected me because i was weak on performance tuning.
So want real hard code hands on it.Please help
Regards
Sahil Soni

user5415179 wrote:
Hi Gurus ,
I know the basic funds of performace tuning.But Can you please tell me the best step by step how to do performace tuning on a production server .Guide for sql tuning,Database tuning,Operating System Tuning.
I give interview in oracle last day but in last round one of manager rejected me because i was weak on performance tuning.
So want real hard code hands on it.Please help
Regards
Sahil Soni
If you have access to Metalink (now called My Oracle Support), search for Doc ID 233112.1 Diagnosing Query Tuning Problems, and Doc ID 390374.1 Oracle Performance Diagnostic Guide (OPDG).
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Performace tuning: how to pass data between different batch job programs?

Hi everyone,
    now i have one problem about performance tuning using threading in SAP programs: split one big program into two programs - one is main program and the other is sub program. using batch jobs, we can submit multi jobs of sub program at the same time.
    does anybody know how to pass data between different batch jobs? I don't want to use temp files. can ABAP memory can implement this?
    thanks!

Wei,
Yes we can transfer the data by using
SAP Memory OR ABAP Memory.
Ex: V_count TYPE i.
V_count = 100.
LOOP AT itab.
IF v_count EQ 25.
Here For every batch job
EXPORT data TO MEMORY ID 'ABC'
   Function module
    JOB_OPEN
   JOB_SUBMIT
   JOB_CLOSE.
ENDIF.
ENDLOOP .
IN your 2nd program.
INITIALIZATION.
IMPORT data FROM MEMORY IF 'ABC'.
FREE memory if .---When you free the memory you will get recent data.
Don't forget to reward if useful.

DB Performace & tuning

Hello everyone,
I am just a beginner in Oracle DBA and I would like to know what are the best practices in tuning oracle databases?
I've read some documentation regarding DB performance and, for instance, I've found section about tuning PCT parameters for db blocks. I wonder if this could be done on production database without rebuilding tablespace??
Could give me some key points and advices (from real life) in oracle database tuning ?
Message was edited by:
Pawel S.

Hi,
You can also use this,
spool tuning_stats.txt
ttitle 'SYSTEM STATISTICS'
select 'LIBRARY CACHE STATISTICS:' from dual;
ttitle off
select 'PINS - # of times an item in the library cache was executed - '||
sum(pins),
'RELOADS - # of library cache misses on execution steps - '||
sum (reloads),
'RELOADS / PINS * 100 = '||round((sum(reloads) / sum(pins) *
100),2)||'%'
from v$librarycache
prompt Increase memory until RELOADS is near 0 but watch out for
prompt Paging/swapping
prompt To increase library cache, increase SHARED_POOL_SIZE
prompt
prompt ** NOTE: Increasing SHARED_POOL_SIZE will increase the SGA size.
prompt
prompt Library Cache Misses indicate that the Shared Pool is not big
prompt enough to hold the shared SQL area for all concurrently open cursors.
prompt If you have no Library Cache misses (PINS = 0), you may get a small
prompt increase in performance by setting CURSOR_SPACE_FOR_TIME = TRUE which
prompt prevents ORACLE from deallocating a shared SQL area while an
prompt application
prompt cursor associated with it is open.
prompt
prompt For Multi-threaded server, add 1K to SHARED_POOL_SIZE per user.
prompt
prompt------------------------------------------------------------------------
column xn1 format a50
column xn2 format a50
column xn3 format a50
column xv1 new_value xxv1 noprint
column xv2 new_value xxv2 noprint
column xv3 new_value xxv3 noprint
column d1 format a50
column d2 format a50
prompt HIT RATIO:
prompt
prompt Values Hit Ratio is calculated against:
prompt
select lpad(name,20,' ')||' = '||value xn1, value xv1
from v$sysstat
where name = 'db block gets'
select lpad(name,20,' ')||' = '||value xn2, value xv2
from v$sysstat
where name = 'consistent gets'
select lpad(name,20,' ')||' = '||value xn3, value xv3
from v$sysstat b
where name = 'physical reads'
set pages 60
select 'Logical reads = db block gets + consistent gets ',
lpad ('Logical Reads = ',24,' ')||to_char(&xxv1+&xxv2) d1
from dual
select 'Hit Ratio = (logical reads - physical reads) / logical reads',
lpad('Hit Ratio = ',24,' ')||
round( (((&xxv2+&xxv1) - &xxv3) / (&xxv2+&xxv1))*100,2 )||'%' d2
from dual
prompt If the hit ratio is less than 60%-70%, increase the initialization
prompt parameter DB_BLOCK_BUFFERS. ** NOTE: Increasing this parameter will
prompt increase the SGA size.
prompt
prompt------------------------------------------------------------------------
col name format a30
col gets format 9,999,999
col waits format 9,999,999
prompt ROLLBACK CONTENTION STATISTICS:
prompt
prompt GETS - # of gets on the rollback segment header
prompt WAITS - # of waits for the rollback segment header
set head on;
select name, waits, gets
from v$rollstat, v$rollname
where v$rollstat.usn = v$rollname.usn
set head off
select 'The average of waits/gets is '||
round((sum(waits) / sum(gets)) * 100,2)||'%'
From v$rollstat
prompt
prompt If the ratio of waits to gets is more than 1% or 2%, consider
prompt creating more rollback segments
prompt
prompt Another way to gauge rollback contention is:
prompt
column xn1 format 9999999
column xv1 new_value xxv1 noprint
set head on
select class, count
from v$waitstat
where class in ('system undo header', 'system undo block',
'undo header', 'undo block' )
set head off
select 'Total requests = '||sum(count) xn1, sum(count) xv1
from v$waitstat
select 'Contention for system undo header = '||
(round(count/(&xxv1+0.00000000001),4)) * 100||'%'
from v$waitstat
where class = 'system undo header'
select 'Contention for system undo block = '||
(round(count/(&xxv1+0.00000000001),4)) * 100||'%'
from v$waitstat
where class = 'system undo block'
select 'Contention for undo header = '||
(round(count/(&xxv1+0.00000000001),4)) * 100||'%'
from v$waitstat
where class = 'undo header'
select 'Contention for undo block = '||
(round(count/(&xxv1+0.00000000001),4)) * 100||'%'
from v$waitstat
where class = 'undo block'
prompt
prompt If the percentage for an area is more than 1% or 2%, consider
prompt creating more rollback segments. Note: This value is usually very
prompt small
prompt and has been rounded to 4 places.
prompt
prompt------------------------------------------------------------------------
prompt REDO CONTENTION STATISTICS:
prompt
prompt The following shows how often user processes had to wait for space in
prompt the redo log buffer:
select name||' = '||value
from v$sysstat
where name = 'redo log space requests'
prompt
prompt This value should be near 0. If this value increments consistently,
prompt processes have had to wait for space in the redo buffer. If this
prompt condition exists over time, increase the size of LOG_BUFFER in the
prompt init.ora file in increments of 5% until the value nears 0.
prompt ** NOTE: increasing the LOG_BUFFER value will increase total SGA size.
prompt
prompt -----------------------------------------------------------------------
col name format a15
col gets format 9999999
col misses format 9999999
col immediate_gets heading 'IMMED GETS' format 9999999
col immediate_misses heading 'IMMED MISS' format 9999999
col sleeps format 999999
prompt LATCH CONTENTION:
prompt
prompt GETS - # of successful willing-to-wait requests for a latch
prompt MISSES - # of times an initial willing-to-wait request was unsuccessful
prompt IMMEDIATE_GETS - # of successful immediate requests for each latch
prompt IMMEDIATE_MISSES = # of unsuccessful immediate requests for each latch
prompt SLEEPS - # of times a process waited and requests a latch after an
prompt initial willing-to-wait request
prompt
prompt If the latch requested with a willing-to-wait request is not
prompt available, the requesting process waits a short time and requests
prompt again.
prompt If the latch requested with an immediate request is not available,
prompt the requesting process does not wait, but continues processing
prompt
set head on
select name, gets, misses,
immediate_gets, immediate_misses, sleeps
from v$latch
where name in ('redo allocation', 'redo copy')
set head off
select 'Ratio of MISSES to GETS: '||
round((sum(misses)/(sum(gets)+0.00000000001) * 100),2)||'%'
from v$latch
where name in ('redo allocation', 'redo copy')
select 'Ratio of IMMEDIATE_MISSES to IMMEDIATE_GETS: '||
round((sum(immediate_misses)/
(sum(immediate_misses+immediate_gets)+0.00000000001) * 100),2)||'%'
from v$latch
where name in ('redo allocation', 'redo copy')
prompt
prompt If either ratio exceeds 1%, performance will be affected.
prompt
prompt Decreasing the size of LOG_SMALL_ENTRY_MAX_SIZE reduces the number of
prompt processes copying information on the redo allocation latch.
prompt
prompt Increasing the size of LOG_SIMULTANEOUS_COPIES will reduce contention
prompt for redo copy latches.
rem
rem This shows the library cache reloads
rem
set head on
prompt
prompt------------------------------------------------------------------------
prompt
prompt Look at gethitratio and pinhit ratio
prompt
prompt GETHITRATIO is number of GETHTS/GETS
prompt PINHIT RATIO is number of PINHITS/PINS - number close to 1 indicates
prompt that most objects requested for pinning have been cached. Pay close
prompt attention to PINHIT RATIO.
prompt
column namespace format a20 heading 'NAME'
column gets format 99999999 heading 'GETS'
column gethits format 99999999 heading 'GETHITS'
column gethitratio format 999.99 heading 'GET HIT|RATIO'
column pins format 9999999 heading 'PINHITS'
column pinhitratio format 999.99 heading 'PIN HIT|RATIO'
select namespace, gets, gethits,
gethitratio, pins, pinhitratio
from v$librarycache
rem
rem
rem This looks at the dictionary cache miss rate
rem
prompt
prompt------------------------------------------------------------------------
prompt THE DATA DICTIONARY CACHE:
prompt
prompt
prompt Consider keeping this below 5% to keep the data dictionary cache in
prompt the SGA. Up the SHARED_POOL_SIZE to improve this statistic. **NOTE:
prompt increasing the SHARED_POOL_SIZE will increase the SGA.
prompt
column dictcache format 999.99 heading 'Dictionary Cache | Ratio %'
select sum(getmisses) / (sum(gets)+0.00000000001) * 100 dictcache
from v$rowcache
prompt
prompt------------------------------------------------------------------------
prompt
prompt SYSTEM EVENTS:
prompt
prompt Not sure of the value of this section yet but it looks interesting.
prompt
col event format a37 heading 'Event'
col total_waits format 99999999 heading 'Total|Waits'
col time_waited format 9999999999 heading 'Time Wait|In Hndrds'
col total_timeouts format 999999 heading 'Timeout'
col average_wait heading 'Average|Time' format 999999.999
set pages 999
select *
from v$system_event
prompt
prompt------------------------------------------------------------------------
rem
rem
rem This looks at the sga area breakdown
rem
prompt THE SGA AREA ALLOCATION:
prompt
prompt
prompt This shows the allocation of SGA storage. Examine this before and
prompt after making changes in the INIT.ORA file which will impact the SGA.
prompt
col name format a40
select name, bytes
from v$sgastat
set head off
select 'total of SGA '||sum(bytes)
from v$sgastat
prompt
prompt------------------------------------------------------------------------
rem
rem Displays all the base session statistics
rem
set head on
set pagesize 110
column name format a55 heading 'Statistic Name'
column value format 9,999,999,999 heading 'Result'
column statistic# format 9999 heading 'Stat#'
ttitle center 'Instance Statistics' skip 2
prompt
prompt Below is a dump of the core Instance Statistics that are greater than0.
prompt Although there are a great many statistics listed, the ones of greatest
prompt value are displayed in other formats throughout this report. Of
prompt interest here are the values for:
prompt
prompt cumulative logons
prompt(# of actual connections to the DB since last startup - good
prompt volume-of-use statistic)
prompt
prompt #93 table fetch continued row
prompt (# of chained rows - will be higher if there are a lot of long fields
prompt if the value goes up over time, it is a good signaller of general
prompt database fragmentation)
prompt
select statistic#, name, value
from v$sysstat
where value > 0
prompt
prompt -----------------------------------------------------------------------
set pages 66;
set space 3;
set heading on;
prompt
prompt Parse Ratio usually falls between 1.15 and 1.45. If it is higher, then
prompt it is usually a sign of poorly written Pro* programs or unoptimized
prompt SQL*Forms applications.
prompt
prompt Recursive Call Ratio will usually be between
prompt
prompt 7.0 - 10.0 for tuned production systems
prompt 10.0 - 14.5 for tuned development systems
prompt
prompt Buffer Hit Ratio is dependent upon RDBMS size, SGA size and
prompt the types of applications being processed. This shows the %-age
prompt of logical reads from the SGA as opposed to total reads - the
prompt figure should be as high as possible. The hit ratio can be raised
prompt by increasing DB_BUFFERS, which increases SGA size. By turning on
prompt the "Virtual Buffer Manager" (db_block_lru_statistics = TRUE and
prompt db_block_lru_extended_statistics = TRUE in the init.ora parameters),
prompt you can determine how many extra hits you would get from memory as
prompt opposed to physical I/O from disk. **NOTE: Turning these on will
prompt impact performance. One shift of statistics gathering should be enough
prompt to get the required information.
prompt
ttitle left 'Ratios for this Instance' skip 2
column pcc heading 'Parse|Ratio' format 99.99
column rcc heading 'Recsv|Cursr' format 99.99
column hr heading 'Buffer|Ratio' format 999,999,999.999
column rwr heading 'Rd/Wr|Ratio' format 999,999.9
column bpfts heading 'Blks per|Full TS' format 999,999
REM Modified for O7.1 to reverse 'cumulative opened cursors' to
REM 'opened cursors cumulative'
REM was:sum(decode(a.name,'cumulative opened cursors',value, .00000000001))
REM pcc,
REM and:sum(decode(a.name,'cumulative opened cursors',value,.00000000001))
REM rcc,
select sum(decode(a.name,'parse count',value,0)) /
sum(decode(a.name,'opened cursors cumulative',value,.00000000001)) pcc,
sum(decode(a.name,'recursive calls',value,0)) /
sum(decode(a.name,'opened cursors cumulative',value,.00000000001)) rcc,
(1-(sum(decode(a.name,'physical reads',value,0)) /
sum(decode(a.name,'db block gets',value,.00000000001)) +
sum(decode(a.name,'consistent gets',value,0))) * (-1)) hr,
sum(decode(a.name,'physical reads',value,0)) /
sum(decode(a.name,'physical writes',value,.00000000001)) rwr,
(sum(decode(a.name,'table scan blocks gotten',value,0)) -
sum(decode(a.name,'table scans (short tables)',value,0)) * 4) /
sum(decode(a.name,'table scans (long tables)',value,.00000000001))
bpfts
from v$sysstat a
prompt
prompt -----------------------------------------------------------------
prompt This looks at overall i/o activity against individual
prompt files within a tablespace
prompt
prompt Look for a mismatch across disk drives in terms of I/O
prompt
prompt Also, examine the Blocks per Read Ratio for heavily accessed
prompt TSs - if this value is significantly above 1 then you may have
prompt full tablescans occurring (with multi-block I/O)
prompt
prompt If activity on the files is unbalanced, move files around to balance
prompt the load. Should see an approximately even set of numbers across files
prompt
set pagesize 100;
set space 1
column pbr format 99999999 heading 'Physical|Blk Read'
column pbw format 999999 heading 'Physical|Blks Wrtn'
column pyr format 999999 heading 'Physical|Reads'
column readtim format 99999999 heading 'Read|Time'
column name format a40 heading 'DataFile Name'
column writetim format 99999999 heading 'Write|Time'
ttitle center 'Tablespace Report' skip 2
compute sum of f.phyblkrd, f.phyblkwrt on report
select fs.name name, f.phyblkrd pbr, f.phyblkwrt pbw,
f.readtim, f.writetim
from v$filestat f, v$datafile fs
where f.file# = fs.file#
order by fs.name
prompt
prompt -----------------------------------------------------------------
prompt GENERATING WAIT STATISTICS:
prompt
prompt This will show wait stats for certain kernel instances. This
prompt may show the need for additional rbs, wait lists, db_buffers
prompt
ttitle center 'Wait Statistics for the Instance' skip 2
column class heading 'Class Type'
column count heading 'Times Waited' format 99,999,999
column time heading 'Total Times' format 99,999,999
select class, count, time
from v$waitstat
where count > 0
order by class
prompt
prompt Look at the wait statistics generated above (if any). They will
prompt tell you where there is contention in the system. There will
prompt usually be some contention in any system - but if the ratio of
prompt waits for a particular operation starts to rise, you may need to
prompt add additional resource, such as more database buffers, log buffers,
prompt or rollback segments
prompt
prompt -----------------------------------------------------------------
prompt ROLLBACK STATISTICS:
prompt
ttitle off;
set linesize 80
column extents format 999 heading 'Extents'
column rssize format 999,999,999 heading 'Size in|Bytes'
column optsize format 999,999,999 heading 'Optimal|Size'
column hwmsize format 99,999,999 heading 'High Water|Mark'
column shrinks format 9,999 heading 'Num of|Shrinks'
column wraps format 9,999 heading 'Num of|Wraps'
column extends format 999,999 heading 'Num of|Extends'
column aveactive format 999,999,999 heading 'Average size|Active Extents'
column rownum noprint
select rssize, optsize, hwmsize,
shrinks, wraps, extends, aveactive
from v$rollstat
order by rownum
prompt
prompt -----------------------------------------------------------------
set linesize 80
break on report
compute sum of gets waits writes on report
ttitle center 'Rollback Statistics' skip 2
select rownum, extents, rssize,
xacts, gets, waits, writes
from v$rollstat
order by rownum
ttitle off
set heading off
prompt
prompt -----------------------------------------------------------------
prompt
prompt SORT AREA SIZE VALUES:
prompt
prompt To make best use of sort memory, the initial extent of your Users
prompt sort-work Tablespace should be sufficient to hold at least one sort
prompt run from memory to reduce dynamic space allocation. If you are getting
prompt a high ratio of disk sorts as opposed to memory sorts, setting
prompt sort_area_retained_size = 0 in init.ora will force the sort area to be
prompt released immediately after a sort finishes.
prompt
column value format 999,999,999
select 'INIT.ORA sort_area_size: '||value
from v$parameter
where name like 'sort_area_size'
select a.name, value
from v$statname a, v$sysstat
where a.statistic# = v$sysstat.statistic#
and a.name in ('sorts (disk)', 'sorts (memory)', 'sorts (rows)')
prompt
prompt -----------------------------------------------------------------
set heading on
set space 2
prompt
prompt This looks at Tablespace Sizing - Total bytes and free bytes
prompt
ttitle center 'Tablespace Sizing Information' Skip 2
column tablespace_name format a30 heading 'TS Name'
column sbytes format 9,999,999,999 heading 'Total Bytes'
column fbytes format 9,999,999,999 heading 'Free Bytes'
column kount format 999 heading 'Ext'
compute sum of fbytes on tablespace_name
compute sum of sbytes on tablespace_name
compute sum of sbytes on report
compute sum of fbytes on report
break on report
select a.tablespace_name, a.bytes sbytes,
sum(b.bytes) fbytes, count(*) kount
from dba_data_files a, dba_free_space b
where a.file_id = b.file_id
group by a.tablespace_name, a.bytes
order by a.tablespace_name
set linesize 80
prompt
prompt A large number of Free Chunks indicates that the tablespace may need
prompt to be defragmented and compressed.
prompt
prompt -----------------------------------------------------------------
set heading off
ttitle off
column value format 99,999,999,999
select 'Total Physical Reads', value
from v$sysstat
where statistic# = 39
prompt
prompt If you can significantly reduce physical reads by adding incremental
prompt data buffers...do it. To determine whether adding data buffers will
prompt help, set db_block_lru_statistics = TRUE and
prompt db_block_lru_extended_statistics = TRUE in the init.ora parameters.
prompt You can determine how many extra hits you would get from memory as
prompt opposed to physical I/O from disk. **NOTE: Turning these on will
prompt impact performance. One shift of statistics gathering should be enough
prompt to get the required information.
prompt
set heading on
clear computes
ttitle off
prompt
prompt -----------------------------------------------------------------
prompt CHECKING FOR FRAGMENTED DATABASE OBJECTS:
prompt
prompt Fragmentation report - If number of extents is approaching Maxextents,
prompt it is time to defragment the table.
prompt
column owner noprint new_value owner_var
column segment_name format a30 heading 'Object Name'
column segment_type format a9 heading 'Table/Indx'
column sum(bytes) format 999,999,999 heading 'Bytes Used'
column count(*) format 999 heading 'No.'
break on owner skip page 2
ttitle center 'Table Fragmentation Report' skip 2 -
left 'creator: ' owner_var skip 2
select a.owner, segment_name, segment_type,
sum(bytes), max_extents, count(*)
from dba_extents a, dba_tables b
where segment_name = b.table_name
having count(*) > 3
group by a.owner, segment_name, segment_type, max_extents
order by a.owner, segment_name, segment_type, max_extents
ttitle center 'Index Fragmentation Report' skip 2 -
left 'creator: ' owner_var skip 2
select a.owner, segment_name, segment_type,
sum(bytes), max_extents, count(*)
from dba_extents a, dba_indexes b
where segment_name = index_name
having count(*) > 3
group by a.owner, segment_name, segment_type, max_extents
order by a.owner, segment_name, segment_type, max_extents
prompt
prompt -----------------------------------------------------------------
spool off
Adith

Performace tuning required in queries having where clause on = or =

Hi,
I ahve query which is taking hell lot of time because of having filter condition on with >=.
Say:
select * from <tableA> where <column1> >= sysdate;
By any chance can we do something to avoid full scan on above table?

Hi,
The oracle version is :
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
the query is :
with temp as(
select sysdate as valuedate from dual
union
select sysdate+1 as valuedate from dual
Union
select sysdate+2 as valuedate from dual
Union
select sysdate+3 as valuedate from dual
select valuedate from temp where valuedate >= sysdate
Taking the above scenerio, is it possible to build any index which can be used to improve the performance.
The above query is just a example. the original query is fetching data from huge table with filter condition >=
I want my index to be used there.

Performace Tuning for BSIS table

Hi All,
While selection of data from BSIS table , data is not comming in production server it is giving dump for time out.
So I have changed the code for peformance. I made a secondary idex ZCF and given field MANDT,BUKRS,HKONT,
GJAHR,BUDAT and MONAT.
And I wrote code like this.For HKONT I have the below criteria given by user.
SELECT bukrs hkont augdt augbl zuonr gjahr belnr
         buzei budat xblnr blart monat shkzg dmbtr prctr
    FROM bsis
    INTO TABLE lt_bsis
    WHERE bukrs IN s_bukrs
    AND ( HKONT LIKE '0051%1' OR HKONT LIKE '0051%2' OR HKONT = '0022300010' )
    AND gjahr = year
    AND budat IN s_budat
    AND monat = month
    %_HINTS ORACLE 'INDEX("BSIS" "BSIS~ZCF")'.
Even then data have not fetchedd within 15 mints and give time out dum.
Can any body suggest me how can I write the code to reduce time.
Thanks,
Rakesh

Hi,
We also received the same kiind of problem, i have used bsip table. and i did whatever i can do still iin production iit shows time out error. We tried everything. Then i made that program as Background Job using SM36. Then only we realised it tooks more than 12 hours to produce the output. After a long search we thought to make Index for that BSIP table, and we made that index using SE11. After we made the index properly , i tested again by scheduling backgroound job then we got that output in just 200 secs (3.4 Minutes). Note the difference.
It might be due to small problem only. You first check your index of BSIS table and create a one.. or else you schedule a job and see the output..

SQL Performace Tuning

Hi,
My Database has two tables, with
1) "table1" having more than 3,000,000 records
2) "table2" having 969 records
table2 has order_id as the primary key.
table1 has been partitioned on order_id.
SELECT *
FROM
(SELECT COUNT(*)
FROM table2 WHERE order_id IN
(SELECT t2.order_id
FROM table1 t1,
table2 t2
WHERE t2.order_id = t1.order_id
AND t1.status= ?
AND t2.status_cd IN (?, ?, ?, ?, ?, ?)
AND ROWNUM <= 10001
WHERE rownum <= 1;
This query has been taking about 8 min to process.
Is there any other way to optimize this???
table2 has a composite index on status_cd, while table1 also has a composite index on status.

Hi,
I would try:
SELECT
count(*)
FROM
table2 t2
WHERE
t2.status_cd IN (?, ?, ?, ?, ?, ?)
and exists
      (select
      from
        table1   t1
      where
        t1.order_id       = t2.order_id
        AND t1.status     = ?
      )But ofcourse without your tables etc this is just a guess.
Hi,
My Database has two tables, with
1) "table1" having more than 3,000,000 records
2) "table2" having 969 records
table2 has order_id as the primary key.
table1 has been partitioned on order_id.Do I understand you correctly that you have potentionaly 969 partitions in table 1?
That sounds like too many for that number of rows.
Regards,
Peter

Performance tuning in ODI

Hi,
Can any help how to do performance tuning in ODI. What are the procedure for performance tuning. What needs to checked for performace tuning. Is there any document for ODI performace tuning.
Thanks,
Gnanamanju

Hi Gnanamanju,
Let me try to contribute a little,
ODI performance strategy tells,
1. Its recommended to run the AGENT in the target host rather than source. In case if your target is a remote host.
2.Selecting appropriate KMs to load data, for example, if its a simple file to oracle transfer, its recommended to use native DB utilities like SQLLDR, External Table and so on.
3. In case, if your staging and target are on the same server then make sure in Physical architecture your selected the correct schema (Data Schema and Work Schema)
4. Right area of execution of joins and filters. If your source has more records then use the filter condition to be executed on SOURCE rather staging.
5. Increase the Array Fetch Size and Batch Fectch Size of your Data server ( so that agent can accordingly fetch/insert the data)
And more....
Thanks,
Guru

Oracle Application Performance Tuning

Hello all,
Please forgive me if I am asking this in the wrong section.
I am a s/w engineer with 2 years of exp. I have been working as a performance tuning resource for Oracle EBS in my company. The work mostly involved SQL tuning and dealing with indexes etc. In this time I took up interest in DBA stuff and I completed my OCA in Oracle 10g. Now my comany is giving me an oppurtunity to move into an Application DBA team and I am totally confused about it.
Becoming an Apps DBA will mean that the effort I put into the certification in 10g will be of no use. There are other papers for Apps DBA certification. Should I stay put in performance tuning & wait for a Core DBA chance or shall I accept the Apps DBA oppurtunity.
Also, does my exp. in SQL performace tuning hold any value as such with out an exposure to DBA activities?
Kindly guide me in this regards as I am very confused at this juncture.
Regards,
Jithin

Jithin wrote:
Hello bigdelboy , Thank you for your reply.
Yes, By oracle Apps DBA I meant Oracle EBS.
Clearing 1Z0-046 is an option. However, my doubt is will clearing both the exams Admin I and Admin II be of any help without having practical expericnce? The EBS DBA work involves support and patching, cloning, and new node setup etc.
Also, is my performance tuning experience going to help me in any way in the journey forward as a DBA/ EBS DBA?
Thank you for your valuable time.
Regards,
Jithin SarathThe way I read it is this.
People notice you are capable of understanding and performance tuning SQL. And you must have some knowledge of Oracle EBS. And in fact you also have a DBA OCA.
So there is a 98% + chance you can be made into a good Oracle Apps DBA (and core DBA). If I was in their position I'd want you on my team too; this is the way we used to bring on DBA's in the old days before certification and it has a lot of merit still. Okay you can only do limited tasks at first ... but the number of taks you can do will increase dramatically over a number of months.
I would imagine the Oracle Apps DBA will be delighted to have someone on board who can performance tune SQL which sometimes can sometimes seem more like an art than a science. The patching etc can be taught in small doses. If they are a good team they wont try to give you everything at once, they'll get you to learn one procedure at a time.
And remember, if in doubt ask; and if you dont understand ask again. And be safe rather than sorry on actions that could be critial.
If your worried about liinux: Linux Recipes For Oracle Dbas (Apress) might be a good book to read but could be expensive in India
Likewise: (Oracle Applications Dba Field Guide) may suit and even (Rman Recipes For Oracle Database 11 G: A Problem-solution Approach) may have some value if you need to get up to speed quickly in those areas.
These are not perfect but they sometimes consolidate the information neatly; however only buy if you feel they are cheap enough. You may well buy them and feel disappointed (These all happen to be by Apress who seem to have produced a number of good books ... they've also published some rubbish as well)
And go over the 2-day dba examples as well and linux install examples n OTN as well ... they are free compared to the books I mentioned.
Rgds -bigdelboy.

StatsPack report check

What are the imporant things to check the performance degradation in StatsPack report?

Check the performace tuning guide from Oracle.
Most common things to look at are
Top wait events,
Hit ratios
Top SQLs
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/toc.htm

How can I architect my data layer to yield query result pages to the application as SQL Server prepares them?

I tried to make the question as explicit as possible.
Refer to Sql Server Management Studio's Results view. Depending upon the structure of the execution plan, the Results pane may begin displaying results while the query is still executing. Can someone point me in a direction for architecting a
data layer (I am tech and framework agnostic for this task. Any solution will suffice) that will begin receiving pages of the set before SQL Server has completed the entire query?
The call from the data layer to SQL Server will obviously have to be asynchronous, but is there any additional ceremony that I need to be aware of when issuing OPTION (FAST x) to the query optimizer?

Thanks for the reply. (I actually meant to put this in the SQL Data Access forum, not the T-SQL forum)
"Generally the last step is ORDER BY in a
query, so nothing can start before that executes."
I would imagine you cannot ORDER BY and yield results as they are fetched because of the execution plan that would be generated. For the purposes of this post, please assume that sorting will be done purely client side
"Can you post your query?"
For purposes of discussion, let's assume that the query is
select *
from information_schema.columns
and also assume that you have "lots" of columns to display.
This was an exploratory question to see what would be necessary to replicate the behavior of Management Studio's Query Result view in a custom application.
I would imagine that there's going to be a lot of analysis of the execution plans that get generated in order for the OPTION (FAST x) optimizer hint to do any good, but apart from general tuning concerns that would allow SQL SERVER to yield a page of data
"fast", I was wondering if there was anything else required of the calling client to force it to yield return its first page.
After thinking about this (and phrasing it the way I did in the last sentence) perhaps this is the incorrect forum for this question. I imagine that my concerns are better addressed in forums dedicated to the technology of the calling client (which
would be a .NET assembly)
Be that as it may, if there is any ceremony that SQL Server imposes on clients in order to yield return, I would expect that my question would be in the scope of SQL Server discussions (even though I intended this to be in a different SQL Server forum)

Portal Performance documents

Hi All,
I am looking for portal performace related documents like performace tuning/performace monitoring overall documents.
Please get back to me on the same
Thanks in advance
Best Regards,
PortalUser100

Hi,
Have a look at the below links
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f0f1358d-0812-2c10-b58c-c7bdd7a0cdce
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d164c5ee-0901-0010-4fbf-d0856b5c8a84
Regards
Karthiheyan M

Is it possible to tune this query.....

This query takes 10 minutes to run on Windows 2003,raid10,Oracle 10.2.0.4.Is there any portion i can look into optimize the query..
Removing the query..
Edited by: Maran Viswarayar on Nov 13, 2009 1:51 PM
Edited by: Maran Viswarayar on Nov 16, 2009 2:58 PM

This is the plan for the view query called inside the function...I did create new indexes to force index scans and plans are here for the same query with index and without index
Without Index
PROD REPORT
Execution Plan
Plan hash value: 3032672189
| Id | Operation                       | Name              | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |                   |   136K|    26M|       | 6443   (1)| 00:01:18 |
|   1 | HASH UNIQUE                    |                   |   136K|    26M|    56M| 6443   (1)| 00:01:18 |
|* 2 |   HASH JOIN RIGHT ANTI          |                   |   136K|    26M|       |   449   (3)| 00:00:06 |
|   3 |    VIEW                         | VW_SQ_1           |     1 |    12 |       |     4   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                |                   |     1 |    33 |       |     4   (0)| 00:00:01 |
|* 5 |      INDEX RANGE SCAN           | PR_RECORD_DTL_IDX |     1 |    19 |       |     3   (0)| 00:00:01 |
|   6 |      TABLE ACCESS BY INDEX ROWID| PR_CALENDAR       |     1 |    14 |       |     1   (0)| 00:00:01 |
|* 7 |       INDEX UNIQUE SCAN         | PK_PR_CALENDAR    |     1 |       |       |     0   (0)| 00:00:01 |
|* 8 |    HASH JOIN                    |                   |   136K|    24M|       |   444   (3)| 00:00:06 |
|   9 |     TABLE ACCESS FULL           | HRM_EMPLOYEE      | 3468 |   128K|       |    69   (0)| 00:00:01 |
|* 10 |     HASH JOIN                   |                   |   151K|    21M|       |   373   (2)| 00:00:05 |
| 11 |      INDEX FAST FULL SCAN       | PK_PR_CALENDAR    |    74 |   814 |       |     2   (0)| 00:00:01 |
|* 12 |      HASH JOIN                  |                   |   298K|    39M|       |   370   (2)| 00:00:05 |
|* 13 |       HASH JOIN                 |                   | 1720 |   169K|       |    22 (10)| 00:00:01 |
| 14 |        TABLE ACCESS FULL        | PR_MAPPING        |   422 | 5064 |       |     5   (0)| 00:00:01 |
|* 15 |        HASH JOIN                |                   | 1726 |   150K|       |    16   (7)| 00:00:01 |
| 16 |         TABLE ACCESS FULL       | PR_MAPPING_DTL    | 1466 | 45446 |       |     5   (0)| 00:00:01 |
|* 17 |         HASH JOIN               |                   | 1178 | 68324 |       |    11 (10)| 00:00:01 |
| 18 |          NESTED LOOPS           |                   |    77 | 1001 |       |     5   (0)| 00:00:01 |
| 19 |           TABLE ACCESS FULL     | PR_REPORT_SECTION |    77 |   770 |       |     5   (0)| 00:00:01 |
|* 20 |           INDEX UNIQUE SCAN     | PR_REPORT_PK      |     1 |     3 |       |     0   (0)| 00:00:01 |
| 21 |          TABLE ACCESS FULL      | PR_REPORT_DATA    | 1178 | 53010 |       |     5   (0)| 00:00:01 |
|* 22 |       TABLE ACCESS FULL         | PR_RECORD_DTL     | 74734 | 2846K|       |   347   (1)| 00:00:05 |
Predicate Information (identified by operation id):
   2 - access("EMPLOYEE_ID"="PRD"."EMPLOYEE_ID" AND "REF_CALENDAR_ID"="PRD"."PAY_CALENDAR_ID")
   5 - access("IPRD"."PAY_CALENDAR_ID" LIKE 'SUP_%')
       filter("IPRD"."PAY_CALENDAR_ID" LIKE 'SUP_%')
   7 - access("IPRD"."PAY_CALENDAR_ID"="IPC"."PAY_CALENDAR_ID")
       filter("IPC"."PAY_CALENDAR_ID" LIKE 'SUP_%')
   8 - access("HE"."EMPLOYEE_ID"="PRD"."EMPLOYEE_ID")
10 - access("PRD"."PAY_CALENDAR_ID"="PC"."PAY_CALENDAR_ID")
12 - access("PM"."ITEM_ID"="PRD"."ITEM_ID")
13 - access("PMD"."PR_ID"="PM"."PR_ID")
15 - access("PRD"."DATA_NAME"="PMD"."NAME")
17 - access("PRS"."SECTION_ID"="PRD"."REF_SECTION")
20 - access("PR"."REPORT_ID"="PRS"."REPORT_ID")
22 - filter("PRD"."PAY_CALENDAR_ID" NOT LIKE 'RET_%')
Statistics
         88 recursive calls
          0 db block gets
       2026 consistent gets
      11080 physical reads
          0 redo size
   45539910 bytes sent via SQL*Net to client
     435394 bytes received via SQL*Net from client
      39547 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
     593178 rows processed
After index creation
After Index creation--------
xecution Plan
lan hash value: 1520293404
Id | Operation                           | Name              | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
   0 | SELECT STATEMENT                    |                   | 1366 |   268K|       |   508   (2)| 00:00:07 |
   1 | HASH UNIQUE                        |                   | 1366 |   268K|   584K|   508   (2)| 00:00:07 |
   2 |   NESTED LOOPS                      |                   | 1366 |   268K|       |   446   (2)| 00:00:06 |
* 3 |    HASH JOIN                        |                   | 1366 |   264K|       |   446   (2)| 00:00:06 |
   4 |     TABLE ACCESS FULL               | PR_REPORT_SECTION |    77 |   770 |       |     5   (0)| 00:00:01 |
* 5 |     HASH JOIN                       |                   | 1366 |   250K|       |   440   (2)| 00:00:06 |
   6 |      TABLE ACCESS FULL              | PR_REPORT_DATA    | 1178 | 53010 |       |     5   (0)| 00:00:01 |
* 7 |      HASH JOIN                      |                   | 1160 |   161K|       |   435   (2)| 00:00:06 |
* 8 |       HASH JOIN RIGHT ANTI          |                   |   335 | 37520 |       |   429   (2)| 00:00:06 |
   9 |        VIEW                         | VW_SQ_1           |     1 |    12 |       |     4   (0)| 00:00:01 |
10 |         NESTED LOOPS                |                   |     1 |    33 |       |     4   (0)| 00:00:01 |
* 11 |          INDEX RANGE SCAN           | PR_RECORD_DTL_IDX |     1 |    19 |       |     3   (0)| 00:00:01 |
12 |          TABLE ACCESS BY INDEX ROWID| PR_CALENDAR       |     1 |    14 |       |     1   (0)| 00:00:01 |
* 13 |           INDEX UNIQUE SCAN         | PK_PR_CALENDAR    |     1 |       |       |     0   (0)| 00:00:01 |
* 14 |        HASH JOIN                    |                   |   335 | 33500 |       |   425   (2)| 00:00:06 |
15 |         TABLE ACCESS FULL           | PR_MAPPING        |   422 | 5064 |       |     5   (0)| 00:00:01 |
* 16 |         HASH JOIN                   |                   |   343 | 30184 |       |   419   (1)| 00:00:06 |
* 17 |          HASH JOIN                  |                   |   379 | 18950 |       |   349   (1)| 00:00:05 |
18 |           INDEX FAST FULL SCAN      | PK_PR_CALENDAR    |    74 |   814 |       |     2   (0)| 00:00:01 |
* 19 |           TABLE ACCESS FULL         | PR_RECORD_DTL     | 74734 | 2846K|       |   347   (1)| 00:00:05 |
20 |          TABLE ACCESS FULL          | HRM_EMPLOYEE      | 3468 |   128K|       |    69   (0)| 00:00:01 |
21 |       TABLE ACCESS FULL             | PR_MAPPING_DTL    | 1466 | 45446 |       |     5   (0)| 00:00:01 |
* 22 |    INDEX UNIQUE SCAN                | PR_REPORT_PK      |     1 |     3 |       |     0   (0)| 00:00:01 |
redicate Information (identified by operation id):
Predicate Information (identified by operation id):
   3 - access("PRS"."SECTION_ID"="PRD"."REF_SECTION")
   5 - access("PRD"."DATA_NAME"="PMD"."NAME")
   7 - access("PMD"."PR_ID"="PM"."PR_ID")
   8 - access("EMPLOYEE_ID"="PRD"."EMPLOYEE_ID" AND SUBSTR("VW_SQ_1"."REF_CALENDAR_ID",1,4)=SUBSTR("
              "PAY_CALENDAR_ID",1,4) AND "REF_CALENDAR_ID"="PRD"."PAY_CALENDAR_ID")
11 - access("IPRD"."PAY_CALENDAR_ID" LIKE 'SUP_%')
       filter("IPRD"."PAY_CALENDAR_ID" LIKE 'SUP_%')
13 - access("IPRD"."PAY_CALENDAR_ID"="IPC"."PAY_CALENDAR_ID")
       filter("IPC"."PAY_CALENDAR_ID" LIKE 'SUP_%' AND
              SUBSTR("IPRD"."PAY_CALENDAR_ID",1,4)=SUBSTR("IPC"."PAY_CALENDAR_ID",1,4))
14 - access("PM"."ITEM_ID"="PRD"."ITEM_ID")
16 - access("HE"."EMPLOYEE_ID"="PRD"."EMPLOYEE_ID")
17 - access(SUBSTR("PRD"."PAY_CALENDAR_ID",1,4)=SUBSTR("PC"."PAY_CALENDAR_ID",1,4) AND
              "PRD"."PAY_CALENDAR_ID"="PC"."PAY_CALENDAR_ID")
19 - filter("PRD"."PAY_CALENDAR_ID" NOT LIKE 'RET_%')
22 - access("PR"."REPORT_ID"="PRS"."REPORT_ID")
Statistics
        111 recursive calls
          0 db block gets
       2028 consistent gets
       9540 physical reads
          0 redo size
   33396834 bytes sent via SQL*Net to client
     435394 bytes received via SQL*Net from client
      39547 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
     593178 rows processedThe cost has changed dramatically....i am not sure this can help in bringing down the response time....
any clues can be helpfuel..and i did go through CBO articles/discussions byt jonathan ,richardfoote...
Can this help ?
Performace tuning looks to be the Toughest job for a DBA :)

Please comment on these steps

Hi experts,
i have little idea on performace tuning, please help..is this a correct way? please correct
is this steps correct for tuning (sql)
1. I used to tune the query by explain plan/tkprof/cardinality feed back
In that i check the elapsing time and cardinality and also cost.
2. if the cardinality is not correct, then i gather the statistics of the tables.
So i can get accurate statstics
3. i try to use indexes and partioned tables
4. I try to use anaylytical functions in code if it is applicable. As analytics are good by performance wise
5. I also use GTT when complex queries that process the same subquery multiple times
Many Thanks
changed title of post Edited by: newbie on May 18, 2012 7:15 AM

newbie wrote:
Hi experts,
i have little idea on performace tuning, please help..is this a correct way? please correct
is this steps correct for tuning (sql)
1. I used to tune the query by explain plan/tkprof/cardinality feed back
In that i check the elapsing time and cardinality and also cost.
2. if the cardinality is not correct, then i gather the statistics of the tables.
So i can get accurate statstics
3. i try to use indexes and partioned tables
4. I try to use anaylytical functions in code if it is applicable. As analytics are good by performance wise
5. I also use GTT when complex queries that process the same subquery multiple times
Many Thanks
changed title of post Edited by: newbie on May 18, 2012 7:15 AM If performance tuning is a five step process then oracle would have build a system that will automatically tune it for you. There is no system in place for that. And i am most certain that there is not going to be a system like that ever.
Performance is not just related to a single SQL Statement. Its something related to the Overall Application Design.
Lot of factors are involved when it comes to performance. Factors like hardware configuration, software configuration, database design etc.
My first step in performance would be "Know what you want". Knowing what is required is a very crucial thing. It may look simple but most of the performance problem starts at this point.
A classic example that i could pick from your steps is this
5. I also use GTT when complex queries that process the same subquery multiple times The first question you need to ask is why am i using same subquery multiple times. If you see you are trying to address a problem without knowing what exactly the problem is. You are trying to improve the performance of a query that uses same sub-query multiple times by using GTT. But the question you should ask is why am i using multiple times the same sub-query.
Whenever a query comes to you performance tuning don't try to tune the query. Try to understand the requirement for which the query is being written. Finding this is the hardest part. In most of the legacy system no one knows why something is done that way. They just accept it and move forward.
Once you have a grip on the requirement you can start building the query from scratch. Believe me rewriting a query is much more simpler than fixing an existing query.
Once i have my new query, this is the point where my performance tuning (Technically) begins :)

Weblogic 8.1 SP4 poor performance

Hi,
I just got started with weblogic 8.1 SP4 platform.
Installed weblogic 8.1 SP4 complete suite on win 2k adv server with 1 Gig RAM.
Well, I have not been able to do much as I initially thought to use it as a DEV platform. I have been trying to run examples via weblogic workshop. The system just crawls whenever I start weblogic server.
Isnt 1 gig of RAM sufficient for the DEV setup ?
Please suggest performace tuning options. I went thru the documentation about performace tuning of weblogic server. I even bumped up the initial heap size for JVM from 256 to 512M, but did not see any improvement from the performance perspective.
please advise.
Thanks

No WLS 8.1 sp4 does not support EJB 2.1
- Ramkumar

Performace Tuning concern

Similar Messages

Maybe you are looking for