Statistics, Rebuilding Indexes, Performance Issues

I have a query which use to run 2-3 sec
After taking stats and rebuliding indexes
This Query is taking 25 sec
Is there anyway that I can get mt performance back?
Collected Stats
First Using Analyze table Compute stats
Second DBMS_STATS.GATHER_ TABLE_STATS
Level 12 Tracing
TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 13:23:11 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
ped.eft_payee_seq_no, ped.partition_desgntr,
ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
WHERE ped.curr_row_ind = 'A'
AND cp.curr_row_ind = 'A'
AND cp.clm_payee_no = el.clm_payee_no
AND cp.mail_zip = 'XXXXXX'
AND ped.paye_bnk_rtng_no = 'XXXXXX'
AND ped.paye_bnk_acct_no = 'XXXXXXX'
AND ped.payee_bnk_acct_typ = 'XXXX'
AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call count cpu elapsed disk query current rows
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.46 22.91 0 1292083 0 0
total 3 23.48 22.93 0 1292083 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 117
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.46 22.91 0 1292083 0 0
total 3 23.48 22.93 0 1292083 0 0
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
41 lines in trace file.
****************-----==========================================*****
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 73 | 5 | | |
| 1 | NESTED LOOPS | | 1 | 73 | 5 | | |
| 2 | NESTED LOOPS | | 12 | 708 | 4 | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T | 12 | 540 | 1 | ROWID | ROW L |
|* 4 | INDEX RANGE SCAN | TEST_PAYEE_EFT_DETAIL_T_IE21 | 12 | | 3 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T | 1 | 14 | 1 | ROWID | ROW L |
|* 6 | INDEX RANGE SCAN | EFT_PAYEE_LNK_PK | 1 | | 1 | | |
|* 7 | INDEX RANGE SCAN | CLM_PAYEE_T_IE10 | 1 | 14 | | | |
Predicate Information (identified by operation id):
4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
"PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
==++++++++++++++*************************=+++++++++++++----------------=========
TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 19:28:39 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
ped.eft_payee_seq_no, ped.partition_desgntr,
ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
WHERE ped.curr_row_ind = 'A'
AND cp.curr_row_ind = 'A'
AND cp.clm_payee_no = el.clm_payee_no
AND cp.mail_zip = 'XXXXXX'
AND ped.paye_bnk_rtng_no = 'XXXXXXXXXX'
AND ped.paye_bnk_acct_no = 'XXXXXXXX'
AND ped.payee_bnk_acct_typ = 'CHK'
AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.30 22.75 0 1292083 0 0
total 3 23.30 22.75 0 1292083 0 0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 117
Rows Row Source Operation
0 NESTED LOOPS
214395 NESTED LOOPS
214395 TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
214395 INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
214395 TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
214395 INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
0 INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)
alter session set sql_trace=false
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 117
ALTER SESSION SET SQL_TRACE = TRUE
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 117
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 1 23.30 22.75 0 1292083 0 0
total 6 23.30 22.75 0 1292083 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
57 lines in trace file.
Message was edited by:
user644525

I have a query which use to run 2-3 sec
After taking stats and rebuliding indexes
This Query is taking 25 sec
Is there anyway that I can get mt performance back?
PLAN_TABLE_OUTPUT
| Id | Operation                            | Name                         | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT                     |                               |     1 |    73 |     5 |       |       |
|   1 | NESTED LOOPS                        |                               |     1 |    73 |     5 |       |       |
|   2 |   NESTED LOOPS                       |                               |    12 |   708 |     4 |       |       |
|   3 |    TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T            |    12 |   540 |     1 | ROWID | ROW L |
|* 4 |     INDEX RANGE SCAN                 | TEST_PAYEE_EFT_DETAIL_T_IE21 |    12 |       |     3 |       |       |
|   5 |    TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T               |     1 |    14 |     1 | ROWID | ROW L |
|* 6 |     INDEX RANGE SCAN                 | EFT_PAYEE_LNK_PK              |     1 |       |     1 |       |       |
|* 7 |   INDEX RANGE SCAN                   | CLM_PAYEE_T_IE10              |     1 |    14 |       |       |       |
Predicate Information (identified by operation id):
   4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
              "PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
   6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
   7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
==++++++++++++++*************************=+++++++++++++----------------=========
SELECT    ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
                ped.eft_payee_seq_no, ped.partition_desgntr,
                ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
                ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
                ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
           FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
          WHERE ped.curr_row_ind = 'A'
            AND cp.curr_row_ind = 'A'
            AND cp.clm_payee_no = el.clm_payee_no
            AND cp.mail_zip = '16803'
            AND ped.paye_bnk_rtng_no = '111000614'
            AND ped.paye_bnk_acct_no = '1586266775'
            AND ped.payee_bnk_acct_typ = 'CHK'
            AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     23.30      22.75          0    1292083          0           0
total        3     23.30      22.75          0    1292083          0           0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 117
Rows     Row Source Operation
      0 NESTED LOOPS
214395   NESTED LOOPS
214395    TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
214395     INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
214395    TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
214395     INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
      0   INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)Trying to recreate my response to this thread that was posted yesterday...
The query is performing 1.3 million logical reads, per the "query" column in the TKPROF output. 1.3 million 8KB (or 16KB) logical reads takes a fair amount of time, and is consuming 23.30 CPU seconds of time (execution time is 22.75 seconds). The explain plan and the row source execution plan are identical, although the predicted cardinality numbers are much lower than the actual number of rows returned, per the TKPROF output (12 rows versus 214,395 rows). The CLM_PAYEE table seems to have the greatest number of restrictions placed on it, yet Oracle is joining that table last.
You found, per my recommendation, that adding the hint /*+ LEADING(CP) */ significantly decreased the execution time to less than one second. You may not have collected statistics on the indexes, even though you collected statistics on the tables. This may also be a sign that one or more histograms are required for the cardinality estimates to be close to accurate.
Did your GATHER_TABLE_STATS commands look similar to the following:
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'PAYEE_EFT_DETAIL',CASCADE=>TRUE);
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'EFT_PAYEE_LNK',CASCADE=>TRUE);
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'CLM_PAYEE',CASCADE=>TRUE);Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Similar Messages

Using Composite Index Performance Issue

Hi,
Need help:
I have a table 'TABLEA' which has composite index on CODE and DEPT_CODE
While fetching the data from the table 'TABLEA' in the WHERE condition I am using only CODE and not DEPT_CODE.
Is the usage of the WHERE condition by using only the CODE column and not DEPT_CODE column affects the performance?
Any help will be needful for me

See the test case below
SQL> create table test_emp
2 (
3 emp_ssn number,
4 emp_name varchar2(50),
5 emp_state varchar2(15),
6 emp_city varchar2(20)
7 );
Table created
SQL> create index test_emp_idx on test_emp(emp_ssn,emp_name);
Index created
SQL> insert into test_emp values (123456789,'Robben','New York','Buffalo');
1 row inserted
SQL> insert into test_emp values (223456789,'Jack','Florida','Miami');
1 row inserted
SQL> insert into test_emp values (323456789,'Peter','Texas','Dallas');
1 row inserted
SQL> insert into test_emp values (423456789,'Johny','Georgia','Atlanta');
1 row inserted
SQL> insert into test_emp values (523456789,'Carmella','California','San Diego');
1 row inserted
SQL> commit;
Commit complete
SQL> explain plan for select /*+ index(test_emp test_emp_idx) */ * from test_emp where emp_ssn = 323456789;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2345760695
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |   163   (1)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |   163   (1)
|* 2 |   INDEX RANGE SCAN          | TEST_EMP_IDX |     1 |       |     2   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_SSN"=323456789)
Note
   - dynamic sampling used for this statement
18 rows selected
SQL> explain plan for select /*+ INDEX_SS(test_emp test_emp_idx) */ * from test_emp where emp_name = 'Robben';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 85087452
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |    15   (0)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |    15   (0)
|* 2 |   INDEX SKIP SCAN           | TEST_EMP_IDX |     1 |       |    11   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_NAME"='Robben')
       filter("EMP_NAME"='Robben')
Note
   - dynamic sampling used for this statement
19 rows selectedThanks,
Andy

Non-Batch Index Performance Issue

I have two tables that have identical data, one is receiving the data via a batch import, the other is receiving data real time at about 10 rows per second, every second, every day. Both tables also have the same index applied and both tables have a similar number of rows.
The batch import table seems to make use of the index and responds to queries (using 'where') very quickly while the table with real time data flow takes considerably longer to respond to the query.
What is the best way to optimize the index on tables that do not receive batch imports?

Thanks for the replies,
Stats are gathered in the DB Maintenance Window every night - using the Oracle recommended 'auto' sample size. The stats on the table and indexes are no more than 24 hours old at any given time.
Also, the tkprof ouput is below:
select to_date(MSGDATETIME, 'YYYY-MM-DD HH24:MI:SS') DTG, MGHOSTNAME, PIXIDN, PIXTXT
from dmblue.fw16master
where msghostname = '10.104'
and to_char(to_date(msgdatetime, 'YYYY-MM-DD HH24:MI:SS'), 'Mon DD YYYY / HH24') like 'Sep 29 2006 / 09'
and msglevel = 'Info'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 90 26.85 237.42 750925 757238 0 1335
total 92 26.85 237.43 750925 757238 0 1335
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
1335 TABLE ACCESS FULL FW16MASTER (cr=757238 pr=750925 pw=0 time=242940908 us)
Any ideas?

WILL BIG INDEX WILL CAUSE PERFORMANCE ISSUE?

In an index table, if there are a lot of insert then data will grow and/or if the index is
huge then can it really cause performance issue?
Is there a document in metalink that says if index is 50% of data then we have to rebuild it? What are the basis and threshold of rebuilding index?

A big index by itself won't cause a performance issue. There are other circumstances you should consider for the index.
First of all, which kind of index are you talking about, there are several kind of indexes in Oracle. On the other hand, assuming you are talking about a regular B*Tree index, you should consider factors such as selectivity and cardinality. If the indexed column has evenly distributed values, then the index will be highly selective, and if the indexed column is highly skewed, in order for the index not to become a real bottleneck you should gather histograms, so selectivity can be calculated at execution time and in case the query retrieves a highly selective data range the index won't slow performance, otherwise a full table scan will be considered a best data access path.
Rebuilding indexes is an operation performed when the index becomes invalid, or when migrating the index to a new tablespace, but not when you suspect the index has become 'fragmented' in this case you should use the Coalesce command. Oracle provides efficient algorithms to maintain the index balanced.
~ Madrid
http://hrivera99.blogspot.com/

Performance issues with the Vouchers index build in SES

Hi All,
We are currently performing an upgrade for: PS FSCM 9.1 to PS FSCM 9.2.
As a part of the upgrade, Client wants Oracle SES to be deployed for some modules including, Purchasing, Payables (Vouchers)
We are facing severe performance issues with the Vouchers index build. (Volume of data = approx. 8.5 million rows of data)
The index creation process runs for over 5 days.
Can you please share any information or issues that you may have faced on your project and how they were addressed?

Check the following logs for errors:
1. The message log from the process scheduler
2. search_server1-diagnostic.log in /search_server1/logs directory
If the build is getting stuck while crawling then we typically have to increase the Java Heap size for the Weblogic instance for SES>

Performance Issue - Index is not used when a zero padded string is queried

Hi All,
I have a table T1 which has many columns. One such column say C1 is a varchar2(20). T1 has 10 million rows and there is an index called I1 on C1. Stats are current for both tables and indexes. These are the scenarios:
Scenario 1
select *   from T1 where C1 = '0013206263' --Uses index I1
187 ms
Scenario 2
select *   from T1 where C1 = '8177341863' --Uses index I1
203 ms
*Scenario 3*
*select *   from T1 where C1 = '0000000945' --Uses Fulll Table Scan --Very Slow*
*45 seconds*
When I force the sql to use the index through a hint, it is working fine:
Scenario 4
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0013206263' --Uses index I1
123 ms
Scenario 5
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '8177341863' --Uses index I1
201 ms
*Scenario 6*
*select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0000000945' --Uses index I1*
*172ms*Is there any reason for this performance issue? Why does the optimizer goes for FTS in Scenario 3?
Edited by: user539954 on May 14, 2009 12:22 PM
Edited by: user539954 on May 14, 2009 12:32 PM

user539954 wrote:
Please see the replies below:
- How many distinct values for C1 out of that 10 million rows? I'm guessing that histograms were created for C1, correct?
=>7 million distinct c1 values. I have not gathered a histogram yet. Should I try that?
SQL> explain plan for select * from T1 where C1 = '0000000954';
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT |                |   244K|    19M| 26228   (5)|
|   1 | TABLE ACCESS FULL| T1 |   244K|    19M| 26228   (5)|
SQL> explain plan for select * from T1 where C1 = '0033454555';
| Id | Operation                   | Name               | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT            |                    |   532 | 43624 |   261   (0)|
|   1 | TABLE ACCESS BY INDEX ROWID| T1     |   532 | 43624 |   261   (0)|
|   2 |   INDEX RANGE SCAN          | I1 |   532 |       |     2   (0)|
It's possible you do have a histogram, even though you didn't plan on creating it, if you're running 10g.
In the absence of a histogram and with 7M distinct keys in 10M rows, Oracle should have predicted 2 rows for both queries, not 244,000 and 532.
If you do have a histogram, you probably need to get rid of it.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

Performance issue with Oracle Text index

Hi Experts,
We are on Oracle 11.2..0.3 on Solaris 10. I have implemented Oracle Text in our environment and I am facing a strange performance issue that is happening in our environment.
One sql having CONTAINS clause is taking forever - more than 20 minutes and still does not complete. This sql has a contains clause and an exists clause and a not exists clause.
Now if I remove the exists clause and a not exists clause , it completes fast. but with those two clauses it is just taking forever. It is late night so i am not able to post the table and sql query details and will do so tomorrow but based on this general description, are there any pointers for me to review?
sql query doing fine:
SELECT
    U.CLNT_OID, U.USR_OID, S.MAILADDR
FROM
    access_usr U
    INNER JOIN access_sia S
        ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
    WHERE U.CLNT_OID = 'ABCX32S'
    AND CONTAINS(LAST_NAME , 'TO%' ) >0
--sql query that hangs forever:
SELECT
    U.CLNT_OID, U.USR_OID, S.MAILADDR
FROM
    access_usr U
    INNER JOIN access_sia S
        ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
    WHERE U.CLNT_OID = 'ABCX32S'
    AND CONTAINS(LAST_NAME , 'TO%' ) >0
and exists (--one clause here wiht a few table joins)
and not exists (--one clause here wiht a few table joins);
--Now another strange thing I found is if instead of 'TO%' in this sql, if I were to use 'ZZ%' or 'L1%' it works fast but for 'TO%' it goes slow with those two exists not exists clauses!
I will be most thankful for the inputs.
OrauserN

Hi Barbara,
First of all, thanks a lot for reviewing the issue.
Unluckily making the change to empty_stoplist did not work out. I am today copying the entire sql here that has this issue and will be most thankful for more insights/pointers on what can be done.
Here is the entire sql:
SELECT U.CLNT_OID,
       U.USR_OID,
       S.EMAILADDRESS,
       U.FIRST_NAME,
       U.LAST_NAME,
       S.JOBCODE,
       S.LOCATION,
       S.DEPARTMENT,
       S.ASSOCIATEID,
       S.ENTERPRISECOMPANYCODE,
       S.EMPLOYEEID,
       S.PAYGROUP,
       S.PRODUCTLOCALE
FROM    ACCESS_USR U
       INNER JOIN
          ACCESS_SIA S
       ON S.USR_OID = U.USR_OID AND S.CLNT_OID = U.CLNT_OID
WHERE     U.CLNT_OID = 'G39NY3D25942TXDA'
       AND EXISTS
              (SELECT 1
                 FROM ACCESS_USR_GROUP_XREF UGX
                      INNER JOIN ACCESS_GROUP RELG
                         ON     RELG.CLNT_OID = UGX.CLNT_OID
                            AND RELG.GROUP_OID = UGX.GROUP_OID
                      INNER JOIN ACCESS_GROUP G
                         ON     G.CLNT_OID = RELG.CLNT_OID
                            AND G.GROUP_TYPE_OID = RELG.GROUP_TYPE_OID
                WHERE     UGX.CLNT_OID = U.CLNT_OID
                      AND UGX.USR_OID = U.USR_OID
                      AND G.GROUP_OID = 920512943
                      AND UGX.INCLUDED = 1)
       AND NOT EXISTS
                  (SELECT 1
                     FROM    ACCESS_USR_GROUP_XREF UGX
                          INNER JOIN
                             ACCESS_GROUP G
                          ON     G.CLNT_OID = UGX.CLNT_OID
                             AND G.GROUP_OID = UGX.GROUP_OID
                    WHERE     UGX.CLNT_OID = U.CLNT_OID
                          AND UGX.USR_OID = U.USR_OID
                          AND G.GROUP_OID = 920512943
                          AND UGX.INCLUDED = 1)
       AND CONTAINS (U.LAST_NAME, 'Bon%') > 0;
Like I said before if the EXISTS and NOT EXISTS clause are removed it works in sub-second. But with those EXISTS and NOT EXISTS CLAUSE IT TAKES ANY WHERE FROM 25 minutes to more than one hour.
NOte also that it was not TO% but Bon% in the CONTAINS clause that is giving the issue - sorry that was wrong on my part.
Also please see below the ORACLE TEXT index defined on the table ACCESS_USER:
--definition of preferences used in the index:
SET SERVEROUTPUT ON size unlimited
WHENEVER SQLERROR EXIT SQL.SQLCODE
DECLARE
   v_err       VARCHAR2 (1000);
   v_sqlcode   NUMBER;
   v_count     NUMBER;
BEGIN
   ctxsys.ctx_ddl.create_preference ('cust_lexer', 'BASIC_LEXER');
   ctxsys.ctx_ddl.set_attribute ('cust_lexer', 'base_letter', 'YES'); -- removes diacritics
EXCEPTION
   WHEN OTHERS
   THEN
      v_err := SQLERRM;
      v_sqlcode := SQLCODE;
      v_count := INSTR (v_err, 'DRG-10701');
      IF v_count > 0
      THEN
         DBMS_OUTPUT.put_line (
            'The required preference named CUST_LEXER with BASIC LEXER is already set up');
      ELSE
         RAISE;
      END IF;
END;
DECLARE
   v_err       VARCHAR2 (1000);
   v_sqlcode   NUMBER;
   v_count     NUMBER;
BEGIN
   ctxsys.ctx_ddl.create_preference ('cust_wl', 'BASIC_WORDLIST');
   ctxsys.ctx_ddl.set_attribute ('cust_wl', 'SUBSTRING_INDEX', 'true'); -- to improve performance
EXCEPTION
   WHEN OTHERS
   THEN
      v_err := SQLERRM;
      v_sqlcode := SQLCODE;
      v_count := INSTR (v_err, 'DRG-10701');
      IF v_count > 0
      THEN
         DBMS_OUTPUT.put_line (
            'The required preference named CUST_WL with BASIC WORDLIST is already set up');
      ELSE
         RAISE;
      END IF;
END;
--now below is the code of the index:
CREATE INDEX ACCESS_USR_IDX3 ON ACCESS_USR
(FIRST_NAME)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
CREATE INDEX ACCESS_USR_IDX4 ON ACCESS_USR
(LAST_NAME)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS('LEXER cust_lexer WORDLIST cust_wl SYNC (ON COMMIT)');
The strange thing is that, like I said, If I remove the exists clause the query returns very fast. Also if I modify the query to use only one NOT EXISTS clause and remove the other EXISTS clause it returns in less than one second. Also if I remove the EXISTS clause and use only the NOT EXISTS clause it returns in less than 4 seconds. But with both clauses it runs forever!
When I tried to get dbms_xplan.display_cursor to get the query plan (for the case of both exists and not exists clause in the query), it said that previous statement's sql id was 0 or something like that so that I was not able to see the query plan. I will keep trying to get this plan (it takes 25 minutes to one hour each time but will get this info soon). Again any pointers are most helpful.
Regards
OrauserN

Issue in rebuilding index after restoring database from sql server 2005 to 2012

Hi All,
We have recently restored a database named DBA_admin from our sql server 2005 instance to sql server 2012 and we have added the database to out weekly maintenance plan. After adding the database to maintenance plan the job is failing every weekend due to
below error message.
Error message from maintenance plan history:
Executing the query "ALTER INDEX [PK_lsttype] ON [dbo].[lstAssign..." failed with the following error: "Invalid object name 'admin.dbo.databaselog'.
ALTER_INDEX - dbo.PK_lsttype". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Below is the code within the maintenance plan which the rebuild index task is using for database dba_admin:
USE [dba_admin]
GO
ALTER INDEX [PK_lstType] ON [dbo].[lstType] REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 98, DATA_COMPRESSION = PAGE)
Please let me know if any one knows how to fix this issue.
Thanks in Advance.

Sorry for the confusion.
Here is what is happening.
The query is failing while trying to rebuild index [Pk_lsttype] on table [lstAssign], both these objects belong to database
admin.
I have verified the old instance there is table databaselog within the database
dba_admin, but in new SQL instance within the database dba_admin the table is not present.
Even I'm not sure of what this table databaselog has to do with rebuilding indexes on table
lstAssign within the admin database.
I have manually tried to execute the alter index command within the database
admin and it is failing with the below error.
ALTER_TABLE - dbo.Query_pnb_sms
Msg 208, Level 16, State 1, Procedure ddlDatabaseTriggerLog, Line 39
Invalid object name 'dba_admin.dbo.databaselog'.

Gathering schema Statistics and Index rebuilding

I want to know after how much time we must gather the schema Statistics and Index rebuilding.
In our system approximately 7 logfile generates in one day
Please suggest me

Index rebuilding sounds so much Oracle 7! Indexes today generally take care of themselves quite well, throughout inserts, deletes and updates. It rebalances itself automatically when necessary, without requiring any rebuild. As for the stats, run it for sure after large data movements (i.e. deletes and inserts). Besides that, implement table monitoring for your tables, and run once in a while dbms_stats with the options parameter as GATHER STALE. That way, Oracle will automatically know which objects need their stats refreshed.
Daniel

Rebuild Index VS Drop and Rebuild?

Hey all,
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation) for specific indexes that get massive updates. The old process has proved to be able to fix and maintain reports performance.
In this process we rebuild specific indexes using the below command:
Alter index index_name rebuild online;
This command takes around 10 min for selected indexes.
Testing the below took 2 min for 6 or 7 indexes.
Drop Index Index_Name;
Create Index Index_Name on Table_name (Col1, col, ..);
I know that indexes might not be used, and the application performance would be degraded with stale or non-existent stats. But our production and all our test DBs have procedures that daily gather stats on them.
I tested the below script to make sure that execution plan does not change:
SELECT ProductID, ProductName, MfrID FROM PRODUCT WHERE MFRID = 'Mfr1';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 37 | 3737 | 13 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| PRODUCT | 37 | 3737 | 13 (0)|
| 2 | INDEX RANGE SCAN | PRODUCT_X1 | 37 | | 3 (0)|
dropping PRODUCT_X1 and recreating it only changed the cost to 12.
Gathering the stats again took the cost to 14.
No performance issues were faced and index was still used.
My question is: Is there any oracle recommendation that requires rebuilding the index instead of dropping and recreating it?
Is there any side effect to my approach that I did not consider?
Thank you

Charlov wrote:
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation)Nice. Not only have you defined and located index fragmentation but have also measured the rate at which it occurs.
Could you please share your definition of index fragmentation, how you detect it, and how you measure the rate of change of this fragmentation.
I am curious about all this since it can be repeatedly shown that Oracle btree indexes are never fragmented.
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth-ii.pdf
The old process has proved to be able to fix and maintain reports performance.Great so you have traces and run time statistics from before and after the rebuild that highlight this mysterious fragmentation and show how the fragmentation caused the report to be slow, details what effects the rebuild had that caused the reports to perform better.
Please share them as these would be an interesting discussion point since no one has been able to show previously how an index rebuild caused a report to run faster or even show the fragmentation that caused it to be slow in the first place.
I mean it would be a pity if the report was just slow because of an inefficient plan and compressing an index or two that probably shouldn't be used in teh first place appears to temporarily speed it up. Could you imagine rebuilding indexes every week, because some developer put the wrong hint in a query? That would be pretty funny.

How to rebuild index in E-Business

Hi
As on core DB side we can check index status for rebuild with command
select owner,index_name,blevel,last_analyzed from dba_indexes where blevel>3 order by last_analyzed
and after that
alter index <index_name> rebuild compute statistics;
my question is can we do the same with my e-business R12.1.2 and 10.2.0.4 database or there is some other recommendation. I want to do this for performance increase.
Thanks
Krishna

Hi krishna,
Also please see
note 163208.1 bde_last_analyzed.sql - Verifies CBO Statistics
note 174605.1 bde_chk_cbo.sql - Reports Database Initialization Parameters related to an Apps 12 or 11i instance
note 396009.1 Database Initialization Parameters for Oracle Applications Release 12
note 216205.1 Database Initialization Parameters for Oracle Applications 11i
note 744143.1 Tuning performance on eBusiness suite
note 169935.1 Troubleshooting Oracle Applications Performance Issues
note 244040.1 Oracle E-Business Suite Recommended Performance Patches

Oracle 10g performance issues

Hi,
We were using Oracle 9i in Solaris 5.8 and it was working fine with some minor performance issues. We formatted the Solaris server with new Solaris 5.10 and installed Oracle 10g.
Now we are experiencing some performance issues in Oracle 10g. This issue is arising when using through Websphere 5.1.
We have analyzed the schema, index is rebuild, SGA is 4.5 GB, PGA is 2.0 GB, Solaris RAM is 16 GB. Also we are having some Mat Views (possibly this may cause performance issues - not sure) due to refresh.
Also I have changed some parameters in init.ora file like query_rewrite = STALE_TOLERATED, open_cursors = 1500 etc.
Is is something due to driver from which the data is accessed. I guess it is not utilizing the indexes on the table.
Can anyone please suggest, what could be the issue ?

There are a lot of changes to the optimizer in the upgrade from 9i to 10g, and you need to be aware of them. There are also a number of changes to the default stats collection mechanism, so after your upgrade your statistics (hence execution paths) could change dramatically.


Greg Rahn has a useful entry on his blog about stats collection, and the blog al,so points to an Oracle white paper which will give you a lot of ideas about where the optimizer changes - which may help you spot your critical issues.

Otherwise, follow triggb's advice about using Statspack to find the SQL that is the most expensive - it's reasonably likely to be this SQL that has changed execution plans in the upgrade.

Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Performance issue with transaction MC50

I am not sure where to post this question. If I need to post it in another forum, please let me know.
We are having performance issues with transaction MC50. After reviewing SAP Note 457615 we created an index on mseg with the following fields: MANDT, MJAHR, MATNR, WERKS and SOBKZ.
When running an explain on the sql statement, the database is using a different index. This index has the following fields MANDT, MATNR, WERKS, LGORT, BWART and SOBKZ.
The sql statement is ( sql trace from ST05):
SELECT * from mseg WHERE "MANDT" = '400' AND "MJAHR" BETWEEN 2009 AND 2009 AND "MATNR" = '000000000054001121' AND "WERKS" = 'SAT' AND "SOBKZ" IN ( 'K' , 'V' , 'W' , 'O' , ' ' )
Is there any way to force the database to use the newly created index.
Thanks....Tommy
Edited by: Tommy Knight on Dec 8, 2009 2:24 PM
Edited by: Tommy Knight on Dec 8, 2009 3:07 PM
Edited by: Tommy Knight on Dec 8, 2009 3:08 PM

Hello Tommy,
at first your database release and patchset is missing.
If you are using Oracle 10g, the advice of Peter is useless, because of statistics are automatically collected by a CREATE INDEX.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_5010.htm#i2075657
COMPUTE STATISTICS
In earlier releases, you could use this clause to start or stop the collection of statistics on an index. This clause has been deprecated. Oracle Database now automatically collects statistics during index creation and rebuild. This clause is supported for backward compatibility and will not cause errors.
The other thing is - are you really sure that this SQL statements was executed with literals?
I know that on MSEG (with histograms) it is recommended sometimes, but i just want to be sure.
If you want us to help you - we need much more information .. please check sapnote #1257075 and upload the information to a webhosting platform, so that we can take a look at it.
Regards
Stefan

Rebuild index vs Analyze index

Hi All,
I am realy confused about rebuilding index versus Analyzing index.
Could anyone plz help me out what is the diffrence between them.
How to Perform analyze of indexes and Rebuld of Indexes for both Oracle 9i and 10g databases.
Thanks a lot

CKPT wrote:
You can see the posts of experts by jonathan
I am realy confused about rebuilding index versus Analyzing index. tell us you are getting confused why we need to ananlyze before reubild index? if so
if index analyzed the whole statistics of index will be gathered.... then you can check what is the hieght of the index.. according to the height of the index you need to take step is index need to be really rebuild or not...
lets see furhter posts from experts if not clear..Thanks OK, so you determine the height of an index is (say) 4. What then ? If you decide to rebuild the index and the index remains at a height of 4, what now ? Was it really worth doing and do you rebuild it again as the index height is still 4 and still within your index rebuild criteria ? At what point do you decide that rebuilding the index just because it has a height of 4 is a total waste of time in this case ?
OK, so you determine the index only has a height of (say) 3, does that mean you don't rebuild the index ? But what if by rebuilding the index, the index now reduces to a height of just 1 ? Perhaps not rebuilding the index even though it has just a height of 3 and doesn't currently meet your index rebuild criteria is totally the wrong thing to do and a rebuild would result in a significantly leaner and more efficient index structure ?
So what if it's pointless rebuilding an index with a height of 4 but another index with a height of 3 is a perfect candidate to be rebuilt ?
Perhaps knowing just the height of an index leaves one totally clueless after all as to whether the index might benefit from an index rebuild ...
Cheers
Richard Foote
http://richardfoote.wordpress.com/

Performance issue in DB need help with analysing this ADDM report

Hi,
My environment:
Os: RHEL5U3 / 11.1.0.7 64 bit / R12.1.1 64 bit
Issue:
Few days are am facing serious of performance problem in our Production instance. Normally the issue will occur 5 to 10 minutes occasionally per day. At the time of issue we not able to access the EBS application its taking time to load. But backend all the oracle, listener and apps services are up and running. No locks at table and session level. Cpu and memory usage is normal.
We have monitored using "Enterprise Manager" for this issue and we found the wait session present more in Active session tab. At this time EBS application is not able access its loading too time. After some time the in Active session tab the wait session came normal and when we try to access the EBS application its working fine.
We try to find the cause of the issue by running addm report. But am not able to understand what its says. Kindly suggests me
ADDM Report for Task 'TASK_42656'
Analysis Period
AWR snapshot range from 14754 to 14755.
Time period starts at 17-APR-12 11.00.22 AM
Time period ends at 17-APR-12 12.00.33 PM
Analysis Target
Database 'PRD' with DB ID 1789440879.
Database version 11.1.0.7.0.
ADDM performed an analysis of instance PRD, numbered 1 and hosted at
advgrpdb.advgroup.ae.
Activity During the Analysis Period
Total database time was 18674 seconds.
The average number of active sessions was 5.17.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Top SQL by DB Time 3.43 | 66.33 5
2 Buffer Busy 2.52 | 48.81 5
3 Buffer Busy 1.39 | 26.81 2
4 Log File Switches .91 | 17.56 1
5 Buffer Busy .56 | 10.87 2
6 Undersized SGA .38 | 7.37 1
7 Commits and Rollbacks .28 | 5.42 1
8 Undo I/O .18 | 3.53 0
9 CPU Usage .13 | 2.57 1
10 Top SQL By I/O .11 | 2.21 1
Findings and Recommendations
Finding 1: Top SQL by DB Time
Impact is 3.43 active sessions, 66.33% of total activity.
SQL statements consuming significant database time were found.
Recommendation 1: SQL Tuning
Estimated benefit is 1.59 active sessions, 30.8% of total activity.
Action
Investigate the SQL statement with SQL_ID "a49xsqhv0h31b" for possible
performance improvements.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
Rationale
SQL statement with SQL_ID "a49xsqhv0h31b" was executed 4686 times and
had an average elapsed time of 1.2 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 85% of the database time spent in processing the SQL
statement with SQL_ID "a49xsqhv0h31b".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 9% of the database time spent in
processing the SQL statement with SQL_ID "a49xsqhv0h31b".
Recommendation 3: SQL Tuning
Estimated benefit is .56 active sessions, 10.91% of total activity.
Action
Investigate the SQL statement with SQL_ID "5d7957yktf3nn" for possible
performance improvements.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
SQL statement with SQL_ID "5d7957yktf3nn" was executed 266 times and had
an average elapsed time of 7.6 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 86% of the database time spent in processing the SQL
statement with SQL_ID "5d7957yktf3nn".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 7% of the database time spent in
processing the SQL statement with SQL_ID "5d7957yktf3nn".
Finding 2: Buffer Busy
Impact is 2.52 active sessions, 48.81% of total activity.
Read and write contention on database blocks was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is 1.42 active sessions, 27.44% of total activity.
Action
Trace the cause of object contention due to SELECT statements in the
application using the information provided.
Related Object
Database object with ID 34562.
Rationale
The SELECT statement with SQL_ID "a49xsqhv0h31b" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 1: Schema Changes
Estimated benefit is .03 active sessions, .62% of total activity.
Action
Consider rebuilding the TABLE "APPLSYS.FND_LOGIN_RESP_FORMS" with object
ID 34651 using a higher value for PCTFREE.
Related Object
Database object with ID 34651.
Rationale
The UPDATE statement with SQL_ID "cqc5crhxxt36t" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID cqc5crhxxt36t.
UPDATE FND_LOGIN_RESP_FORMS FLRF SET END_TIME = SYSDATE WHERE
FLRF.LOGIN_ID = :B2 AND FLRF.LOGIN_RESP_ID = :B1 AND FLRF.END_TIME IS
NULL AND (FLRF.FORM_ID, FLRF.FORM_APPL_ID) = (SELECT F.FORM_ID,
F.APPLICATION_ID FROM FND_FORM F, FND_APPLICATION A WHERE F.FORM_NAME
= :B4 AND F.APPLICATION_ID = A.APPLICATION_ID AND
A.APPLICATION_SHORT_NAME = :B3 )
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 4: Log File Switches
Impact is .91 active sessions, 17.56% of total activity.
Log file switch operations were consuming significant database time while
waiting for checkpoint completion.
This problem can be caused by use of hot backup mode on tablespaces. DML to
tablespaces in hot backup mode causes generation of additional redo.
Recommendation 1: Database Configuration
Estimated benefit is .91 active sessions, 17.56% of total activity.
Action
Verify whether incremental shipping was used for standby databases.
Symptoms That Led to the Finding:
Wait class "Configuration" was consuming significant database time.
Impact is .91 active sessions, 17.63% of total activity.
Finding 5: Buffer Busy
Impact is .56 active sessions, 10.87% of total activity.
A hot data block with concurrent read and write activity was found. The block
belongs to segment "ICX.ICX_SESSIONS" and is block 243489 in file 36.
Recommendation 1: Application Analysis
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Investigate application logic to find the cause of high concurrent read
and write activity to the data present in this block.
Related Object
Database block with object number 37562, file number 36 and block
number 243489.
Rationale
The SQL statement with SQL_ID "5d7957yktf3nn" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
The SQL statement with SQL_ID "326up1aym56dd" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 326up1aym56dd.
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 2: Schema Changes
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Consider rebuilding the TABLE "ICX.ICX_SESSIONS" with object ID 37562
using a higher value for PCTFREE.
Related Object
Database object with ID 37562.
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 6: Undersized SGA
Impact is .38 active sessions, 7.37% of total activity.
The SGA was inadequately sized, causing additional I/O or hard parses.
The value of parameter "sga_target" was "4096 M" during the analysis period.
Recommendation 1: Database Configuration
Estimated benefit is .12 active sessions, 2.33% of total activity.
Action
Increase the size of the SGA by setting the parameter "sga_target" to
4608 M.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Hard parsing of SQL statements was consuming significant database time.
Impact is .13 active sessions, 2.51% of total activity.
Contention for latches related to the shared pool was consuming
significant database time.
Impact is 0 active sessions, .03% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 7: Commits and Rollbacks
Impact is .28 active sessions, 5.42% of total activity.
Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
were consuming significant database time.
Recommendation 1: Host Configuration
Estimated benefit is .28 active sessions, 5.42% of total activity.
Action
Investigate the possibility of improving the performance of I/O to the
online redo log files.
Rationale
The average size of writes to the online redo log files was 163 K and
the average time per write was 68 milliseconds.
Symptoms That Led to the Finding:
Wait class "Commit" was consuming significant database time.
Impact is .28 active sessions, 5.42% of total activity.
Finding 8: Undo I/O
Impact is .18 active sessions, 3.53% of total activity.
Undo I/O was a significant portion (26%) of the total database I/O.
No recommendations are available.
Symptoms That Led to the Finding:
The throughput of the I/O subsystem was significantly lower than
expected.
Impact is .08 active sessions, 1.46% of total activity.
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Finding 9: CPU Usage
Impact is .13 active sessions, 2.57% of total activity.
Time spent on the CPU by the instance was responsible for a substantial part
of database time.
Recommendation 1: SQL Tuning
Estimated benefit is .13 active sessions, 2.57% of total activity.
Finding 10: Top SQL By I/O
Impact is .11 active sessions, 2.21% of total activity.
Individual SQL statements responsible for significant user I/O wait were
found.
Recommendation 1: SQL Tuning
Estimated benefit is .11 active sessions, 2.22% of total activity.
Action
Run SQL Tuning Advisor on the SQL statement with SQL_ID "b3pnc5yctv2z5".
Related Object
SQL statement with SQL_ID b3pnc5yctv2z5.
INSERT INTO ZX_TRANSACTION_LINES_GT( APPLICATION_ID ,ENTITY_CODE
,EVENT_CLASS_CODE ,TRX_ID ,TRX_LEVEL_TYPE ,TRX_LINE_ID ,LINE_CLASS
,LINE_LEVEL_ACTION ,TRX_LINE_TYPE ,TRX_LINE_DATE
,LINE_AMT_INCLUDES_TAX_FLAG ,LINE_AMT ,TRX_LINE_QUANTITY ,UNIT_PRICE
,PRODUCT_ID ,PRODUCT_ORG_ID ,UOM_CODE ,PRODUCT_CODE ,SHIP_TO_PARTY_ID
,SHIP_FROM_PARTY_ID ,BILL_TO_PARTY_ID ,BILL_FROM_PARTY_ID
,SHIP_FROM_PARTY_SITE_ID ,BILL_FROM_PARTY_SITE_ID
,SHIP_TO_LOCATION_ID ,SHIP_FROM_LOCATION_ID ,BILL_TO_LOCATION_ID
,SHIP_THIRD_PTY_ACCT_ID ,SHIP_THIRD_PTY_ACCT_SITE_ID ,HISTORICAL_FLAG
,TRX_LINE_CURRENCY_CODE ,TRX_LINE_CURRENCY_CONV_DATE
,TRX_LINE_CURRENCY_CONV_RATE ,TRX_LINE_CURRENCY_CONV_TYPE
,TRX_LINE_MAU ,TRX_LINE_PRECISION ,HISTORICAL_TAX_CODE_ID
,TRX_BUSINESS_CATEGORY ,PRODUCT_CATEGORY ,PRODUCT_FISC_CLASSIFICATION
,LINE_INTENDED_USE ,PRODUCT_TYPE ,USER_DEFINED_FISC_CLASS
,ASSESSABLE_VALUE ,INPUT_TAX_CLASSIFICATION_CODE ,ACCOUNT_CCID
,BILL_THIRD_PTY_ACCT_ID ,BILL_THIRD_PTY_ACCT_SITE_ID ,TRX_LINE_NUMBER
,TRX_LINE_DESCRIPTION ,PRODUCT_DESCRIPTION ,USER_UPD_DET_FACTORS_FLAG
,DEFAULTING_ATTRIBUTE1 ) SELECT :B4 ,:B3 ,:B2
,PRL.REQUISITION_HEADER_ID ,:B1 ,PRL.REQUISITION_LINE_ID ,'INVOICE'
,NVL(PRL.TAX_ATTRIBUTE_UPDATE_CODE,'UPDATE') ,'ITEM'
,NVL(PRL.NEED_BY_DATE, SYSDATE) ,'N' ,NVL(PRL.AMOUNT,
PRL.UNIT_PRICE*PRL.QUANTITY) ,PRL.QUANTITY ,PRL.UNIT_PRICE
,PRL.ITEM_ID ,(SELECT FSP.INVENTORY_ORGANIZATION_ID FROM
FINANCIALS_SYSTEM_PARAMS_ALL FSP WHERE FSP.ORG_ID=PRL.ORG_ID)
,(SELECT MUM.UOM_CODE FROM MTL_UNITS_OF_MEASURE MUM WHERE
MUM.UNIT_OF_MEASURE=PRL.UNIT_MEAS_LOOKUP_CODE) ,MSIB.SEGMENT1
,PRL.DESTINATION_ORGANIZATION_ID ,PV.PARTY_ID ,PRH.ORG_ID
,PV.PARTY_ID ,PVS.PARTY_SITE_ID ,PVS.PARTY_SITE_ID
,PRL.DELIVER_TO_LOCATION_ID ,(SELECT HZPS.LOCATION_ID FROM
HZ_PARTY_SITES HZPS WHERE HZPS.PARTY_SITE_ID = PVS.PARTY_SITE_ID)
,(SELECT LOCATION_ID FROM HR_ALL_ORGANIZATION_UNITS WHERE
ORGANIZATION_ID=PRH.ORG_ID) ,PRL.VENDOR_ID ,PRL.VENDOR_SITE_ID ,NULL
,NVL(PRL.CURRENCY_CODE, :B9 ) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE_DATE,
SYSDATE) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE, :B8 )
,NVL2(PRL.CURRENCY_CODE, PRL.RATE_TYPE, :B7 )
,FC.MINIMUM_ACCOUNTABLE_UNIT ,NVL(FC.PRECISION, 2) ,NULL
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.TRX_BUSINESS_CATEGORY, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_CATEGORY, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_FISC_CLASSIFICATION,
NULL), NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.LINE_INTENDED_USE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_TYPE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.USER_DEFINED_FISC_CLASS, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.ASSESSABLE_VALUE, NULL), NULL )
,DECODE(:B6 , 'REQIMPORT', PRL.TAX_NAME,
DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.INPUT_TAX_CLASSIFICATION_CODE,
NULL), NULL ) ) ,NVL((SELECT PRD.CODE_COMBINATION_ID FROM
PO_REQ_DISTRIBUTIONS_ALL PRD WHERE PRD.REQUISITION_LINE_ID =
PRL.REQUISITION_LINE_ID AND ROWNUM = 1), MSIB.EXPENSE_ACCOUNT )
,PV.VENDOR_ID ,PVS.VENDOR_SITE_ID ,PRL.LINE_NUM ,PRL.ITEM_DESCRIPTION
,PRL.ITEM_DESCRIPTION ,(SELECT 'Y' FROM DUAL WHERE :B6 = 'REQIMPORT'
AND PRL.TAX_NAME IS NOT NULL) ,PRL.DESTINATION_ORGANIZATION_ID FROM
PO_REQUISITION_HEADERS_ALL PRH, PO_REQUISITION_LINES_ALL PRL,
ZX_LINES_DET_FACTORS ZXLDET, PO_VENDORS PV, PO_VENDOR_SITES_ALL PVS,
MTL_SYSTEM_ITEMS_B MSIB, FND_CURRENCIES FC WHERE
PRH.REQUISITION_HEADER_ID = :B5 AND PRH.REQUISITION_HEADER_ID =
PRL.REQUISITION_HEADER_ID AND ZXLDET.APPLICATION_ID(+) = :B4 AND
ZXLDET.ENTITY_CODE(+) = :B3 AND ZXLDET.EVENT_CLASS_CODE(+) = :B2 AND
ZXLDET.TRX_LEVEL_TYPE(+) = :B1 AND ZXLDET.TRX_LINE_ID(+) =
PRL.PARENT_REQ_LINE_ID AND PV.VENDOR_ID(+) = PRL.VENDOR_ID AND
PVS.VENDOR_SITE_ID(+) = PRL.VENDOR_SITE_ID AND
MSIB.INVENTORY_ITEM_ID(+) = PRL.ITEM_ID AND MSIB.ORGANIZATION_ID(+) =
PRL.ORG_ID AND FC.CURRENCY_CODE(+) = PRL.CURRENCY_CODE AND
NVL(PRL.MODIFIED_BY_AGENT_FLAG, 'N') = 'N' AND NVL(PRL.CANCEL_FLAG,
'N') = 'N' AND NVL(PRL.CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED' AND
PRL.LINE_LOCATION_ID IS NULL AND PRL.AT_SOURCING_FLAG IS NULL
Rationale
SQL statement with SQL_ID "b3pnc5yctv2z5" was executed 3 times and had
an average elapsed time of 138 seconds.
Rationale
Average time spent in User I/O wait events per execution was 137
seconds.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
Regards
Athish

Few days are am facing serious of performance problem in our Production instanceFor production issues, please log a SR.
Was this working before? If yes, any changes been done recently?
Do you have the statistics collected up to date?
Please see these docs.
AutoInvoice Performance Issue When Processing Tax [ID 1059275.1]
R12 : System Hangs When Attempting To Save Blanket Release After Applying Patch 11817843 [ID 1333336.1]
Thanks,
Hussein

Statistics, Rebuilding Indexes, Performance Issues

Similar Messages

Maybe you are looking for