Query is taking too long to execute - contd

I am unable to post the entire explain plan in one post as it exceeds maximum length.
Please advise on how to post this.
Previous post Link : Link: Query is taking too long to execute
Regards,
Sreekanth Munagala.
Edited by: Sreekanth Munagala on Oct 27, 2009 8:31 AM
Edited by: Sreekanth Munagala on Oct 27, 2009 8:34 AM

Hi Tubby,
Today i executed only the first query in the view and it took almost 2.5 hrs.
Here is the explain plan for this query
SQL> SET SERVEROUTPUT ON
SQL> set linesize 200
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation                                        | Name                         | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                                 |                               |     1 |   766 | 2448 |
|   1 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    13 |     3 |
|* 2 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   3 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    29 |     3 |
|* 4 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   5 | VIEW                                            | POC_ASN_PICKUP_LOCATIONS_V    |     2 | 2426 |    17 |
|   6 |   UNION-ALL                                      |                               |       |       |       |
|   7 |    NESTED LOOPS                                  |                               |     1 |    85 |     4 |
|   8 |     NESTED LOOPS                                 |                               |     1 |    78 |     4 |
|* 9 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDOR_SITES_ALL           |     1 |    73 |     3 |
|* 10 |       INDEX UNIQUE SCAN                          | PO_VENDOR_SITES_U2            |     1 |       |     2 |
|* 11 |      INDEX UNIQUE SCAN                           | PO_VENDORS_U1                 |     1 |     5 |     1 |
|* 12 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
| 13 |    NESTED LOOPS                                  |                               |     1 |    91 |    13 |
| 14 |     NESTED LOOPS                                 |                               |     1 |    84 |    13 |
| 15 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDORS                    |     1 |    13 |     3 |
|* 16 |       INDEX UNIQUE SCAN                          | PO_VENDORS_U1                 |     1 |       |     2 |
PLAN_TABLE_OUTPUT
|* 17 |      TABLE ACCESS BY INDEX ROWID                 | FND_LOOKUP_VALUES             |     1 |    71 |    10 |
|* 18 |       INDEX RANGE SCAN                           | FND_LOOKUP_VALUES_U2          |    13 |       |     2 |
|* 19 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
|* 20 | COUNT STOPKEY                                   |                               |       |       |       |
| 21 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   136 |    12 |
|* 22 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
|* 23 | COUNT STOPKEY                                   |                               |       |       |       |
| 24 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   288 |    12 |
|* 25 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
| 26 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 27 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 28 | NESTED LOOPS                                    |                               |     1 |    40 |     5 |
| 29 |   TABLE ACCESS BY INDEX ROWID                    | HZ_CUST_ACCOUNTS              |     1 |    11 |     3 |
|* 30 |    INDEX UNIQUE SCAN                             | HZ_CUST_ACCOUNTS_U1           |     1 |       |     2 |
| 31 |   TABLE ACCESS BY INDEX ROWID                    | HZ_PARTIES                    |     1 |    29 |     2 |
|* 32 |    INDEX UNIQUE SCAN                             | HZ_PARTIES_U1                 |     1 |       |     1 |
| 33 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 34 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 35 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 36 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 37 | COUNT STOPKEY                                   |                               |       |       |       |
PLAN_TABLE_OUTPUT
|* 38 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 39 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 40 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 41 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 42 | COUNT STOPKEY                                   |                               |       |       |       |
|* 43 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 44 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 45 | SORT AGGREGATE                                  |                               |     1 |    39 |       |
| 46 |   NESTED LOOPS OUTER                             |                               |     2 |    78 | 1828 |
|* 47 |    TABLE ACCESS FULL                             | ONTC_MTC_PROFORMA_HEADERS     |     1 |    24 | 1825 |
| 48 |    TABLE ACCESS BY INDEX ROWID                   | ONTC_MTC_PROFORMA_LINES       |     5 |    75 |     3 |
|* 49 |     INDEX RANGE SCAN                             | ONTC_MTC_PROFORMA_LINES_PK    |    11 |       |     2 |
| 50 | NESTED LOOPS                                    |                               |     1 |   766 | 2448 |
| 51 |   NESTED LOOPS                                   |                               |     1 |   761 | 2447 |
| 52 |    NESTED LOOPS                                  |                               |     1 |   746 | 2445 |
| 53 |     NESTED LOOPS                                 |                               |     1 |   694 | 2443 |
| 54 |      NESTED LOOPS                                |                               |     1 |   682 | 2441 |
| 55 |       NESTED LOOPS                               |                               |     1 |   671 | 2439 |
| 56 |        NESTED LOOPS                              |                               |     1 |   612 | 2437 |
| 57 |         NESTED LOOPS                             |                               |     1 |   600 | 2435 |
| 58 |          NESTED LOOPS                            |                               |     1 |   575 | 2433 |
PLAN_TABLE_OUTPUT
| 59 |           NESTED LOOPS                           |                               |     1 |   552 | 2431 |
| 60 |            NESTED LOOPS                          |                               |     1 |   533 | 2429 |
| 61 |             NESTED LOOPS                         |                               |     1 |   524 | 2428 |
| 62 |              NESTED LOOPS                        |                               |     1 |   455 | 2427 |
| 63 |               NESTED LOOPS                       |                               |     1 |   429 | 2426 |
| 64 |                NESTED LOOPS                      |                               |     1 |   389 | 2424 |
| 65 |                 NESTED LOOPS                     |                               |     1 |   368 | 2422 |
| 66 |                  NESTED LOOPS                    |                               |     1 |   308 | 2421 |
| 67 |                   NESTED LOOPS                   |                               |     1 |   281 | 2419 |
| 68 |                    NESTED LOOPS                  |                               |     1 |   253 | 2418 |
| 69 |                     NESTED LOOPS                 |                               |     1 |   214 | 2416 |
| 70 |                      NESTED LOOPS                |                               |    39 | 7371 | 2338 |
|* 71 |                       TABLE ACCESS FULL          | RCV_SHIPMENT_HEADERS          |    39 | 5070 | 2221 |
|* 72 |                       TABLE ACCESS BY INDEX ROWID| RCV_SHIPMENT_LINES            |     1 |    59 |     3 |
|* 73 |                        INDEX RANGE SCAN          | RCV_SHIPMENT_LINES_U2         |     1 |       |     2 |
|* 74 |                      TABLE ACCESS BY INDEX ROWID | PO_LINES_ALL                  |     1 |    25 |     2 |
|* 75 |                       INDEX UNIQUE SCAN          | PO_LINES_U1                   |     1 |       |     1 |
|* 76 |                     TABLE ACCESS BY INDEX ROWID | PO_LINE_LOCATIONS_ALL         |     1 |    39 |     2 |
|* 77 |                      INDEX UNIQUE SCAN           | PO_LINE_LOCATIONS_U1          |     1 |       |     1 |
|* 78 |                    TABLE ACCESS BY INDEX ROWID   | PO_HEADERS_ALL                |     1 |    28 |     1 |
|* 79 |                     INDEX UNIQUE SCAN            | PO_HEADERS_U1                 |     1 |       |       |
PLAN_TABLE_OUTPUT
|* 80 |                   TABLE ACCESS BY INDEX ROWID    | OE_ORDER_LINES_ALL            |     1 |    27 |     2 |
|* 81 |                    INDEX UNIQUE SCAN             | OE_ORDER_LINES_U1             |     1 |       |     1 |
| 82 |                  TABLE ACCESS BY INDEX ROWID     | OE_ORDER_HEADERS_ALL          |     1 |    60 |     1 |
|* 83 |                   INDEX UNIQUE SCAN              | OE_ORDER_HEADERS_U1           |     1 |       |       |
|* 84 |                 TABLE ACCESS BY INDEX ROWID      | HZ_CUST_SITE_USES_ALL         |     1 |    21 |     2 |
|* 85 |                  INDEX UNIQUE SCAN               | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
|* 86 |                TABLE ACCESS BY INDEX ROWID       | HZ_CUST_SITE_USES_ALL         |     1 |    40 |     2 |
|* 87 |                 INDEX UNIQUE SCAN                | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
| 88 |               TABLE ACCESS BY INDEX ROWID        | WSH_CARRIERS                  |     1 |    26 |     1 |
|* 89 |                INDEX UNIQUE SCAN                 | WSH_CARRIERS_U2               |     1 |       |       |
|* 90 |              TABLE ACCESS BY INDEX ROWID         | WSH_CARRIER_SERVICES          |     1 |    69 |     1 |
|* 91 |               INDEX RANGE SCAN                   | WSH_CARRIER_SERVICES_N1       |     2 |       |       |
|* 92 |             TABLE ACCESS BY INDEX ROWID          | WSH_ORG_CARRIER_SERVICES      |     1 |     9 |     1 |
|* 93 |              INDEX RANGE SCAN                    | WSH_ORG_CARRIER_SERVICES_N1   |     1 |       |       |
| 94 |            TABLE ACCESS BY INDEX ROWID           | HZ_CUST_ACCOUNTS              |     1 |    19 |     2 |
|* 95 |             INDEX UNIQUE SCAN                    | HZ_CUST_ACCOUNTS_U1           |     1 |       |     1 |
|* 96 |           TABLE ACCESS BY INDEX ROWID            | HZ_CUST_ACCT_SITES_ALL        |     1 |    23 |     2 |
|* 97 |            INDEX UNIQUE SCAN                     | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
|* 98 |          TABLE ACCESS BY INDEX ROWID             | HZ_CUST_ACCT_SITES_ALL        |     1 |    25 |     2 |
|* 99 |           INDEX UNIQUE SCAN                      | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
| 100 |         TABLE ACCESS BY INDEX ROWID              | HZ_PARTY_SITES                |     1 |    12 |     2 |
PLAN_TABLE_OUTPUT
|*101 |          INDEX UNIQUE SCAN                       | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 102 |        TABLE ACCESS BY INDEX ROWID               | HZ_LOCATIONS                  |     1 |    59 |     2 |
|*103 |         INDEX UNIQUE SCAN                        | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*104 |       INDEX RANGE SCAN                           | HZ_LOC_ASSIGNMENTS_N1         |     1 |    11 |     2 |
| 105 |      TABLE ACCESS BY INDEX ROWID                 | HZ_PARTY_SITES                |     1 |    12 |     2 |
|*106 |       INDEX UNIQUE SCAN                          | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 107 |     TABLE ACCESS BY INDEX ROWID                  | HZ_LOCATIONS                  |     1 |    52 |     2 |
|*108 |      INDEX UNIQUE SCAN                           | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*109 |    INDEX RANGE SCAN                              | HZ_LOC_ASSIGNMENTS_N1         |     1 |    15 |     2 |
|*110 |   INDEX UNIQUE SCAN                              | HZ_PARTIES_U1                 |     1 |     5 |     1 |
I will put the predicate information in another post.
193 rows selected.
SQL> spool offPlease suggest on how can we improve the performance.
Regards,
Sreekanth Munagala.

Similar Messages

When query is taking too long time

When query is taking too long time,Where and how to start tuning it?
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)
2.Parameter modification need to be done at system/session level
3.The query has to be tuned (using hints )
4.Gathering/deleting statistics
List out any other things that need to be taken into account?
Which approach must be followed and on what basis that approach must be considered?

When query is taking too long time,Where and how to start tuning it?explain plan will be good start . trace also
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for a specific event to happen befor it can proceed.
Read
http://www.adp-gmbh.ch/ora/tuning/event.html
2.Parameter modification need to be done at system/session levelDepend on parameter , define parameter , trace done on session level for example
3.The query has to be tuned (using hints )Could be help you but you must know how to use .
4.Gathering/deleting statisticsDo it in non working hours , it will impact on database performance , but its good
List out any other things that need to be taken into account?Which account ?
Which approach must be followed and on what basis that approach must be considered?you could use lot of tools , Trace , AWR

Update statement taking too long to execute

Hi All,
I'm trying to run this update statement. But its taking too long to execute.
    UPDATE ops_forecast_extract b SET position_id = (SELECT a.row_id
        FROM s_postn a
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME)))
        WHERE position_level = 7
        AND b.am_id IS NULL;
        SELECT COUNT(*) FROM S_POSTN;
        214665
        SELECT COUNT(*) FROM ops_forecast_extract;
        49366
SELECT count(*)
        FROM s_postn a, ops_forecast_extract b
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME));
575What could be the reason for update statement to execute so long?
Thanks

polasa wrote:
Hi All,
I'm trying to run this update statement. But its taking too long to execute.
What could be the reason for update statement to execute so long?You haven't said what "too long" means, but a simple reason could be that the scalar subquery on "s_postn" is using a full table scan for each execution. Potentially this subquery gets executed for each row of the "ops_forecast_extract" table that satisfies your filter predicates. "Potentially" because of the cunning "filter/subquery optimization" of the Oracle runtime engine that attempts to cache the results of already executed instances of the subquery. Since the in-memory hash table that holds these cached results is of limited size, the optimization algorithm depends on the sort order of the data and could suffer from hash collisions it's unpredictable how well this optimization works in your particular case.
You might want to check the execution plan, it should tell you at least how Oracle is going to execute the scalar subquery (it doesn't tell you anything about this "filter/subquery optimization" feature).
Generic instructions how to generate a useful explain plan output and how to post it here follow:
Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the {noformat}[{noformat}code{noformat}]{noformat} tag before and {noformat}[{noformat}/code{noformat}]{noformat} tag after or the {noformat}{{noformat}code{noformat}}{noformat} tag before and after to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In 9i and above, if the "Predicate Information" section is missing from the DBMS_XPLAN.DISPLAY output but you get instead the message "Plan table is old version" then you need to re-create your plan table using the server side script "$ORACLE_HOME/rdbms/admin/utlxplan.sql".
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
When your query takes too long ...
and post the "tkprof" output here, too.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Query taking too long to execute after clone

Hi All,
We have a query which is working fine in our development environment and taking around 15 secs to execute the query. When we run the same query with same parameters in a recently cloned instance, the query is taking 1200 secs to execute.
Please help us on this issue.
Thanks,
Raghava

Hi All,
I have 4 unions in my query. individual sqls are running in very less time. But when i use all of them in UNION then im getting performance issue. Below is my query:
SELECT /*+ parallel(xla_l) parallel(xla_h) leading(xla_h) */
XLA_L.code_combination_id,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description ,
xla_h.accounting_date,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
xla_h.entity_id,
xla_h.event_type_code,
et.event_class_code,
bud.budget_name,
xla_h.ledger_id,
xla_l.entered_dr,
xla_l.entered_cr,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,
null fleet_number,
null Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
XLA_L.AE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5 ,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et ,
xla.xla_event_classes_tl ec ,
xla.xla_transaction_entities te,
gl_budget_versions bud ,
--gl_import_references ir,
xla.xla_subledgers xs
--gl_je_lines gl_l
where
--ir.gl_sl_link_id=XLA_L.gl_sl_link_id
--and ir.gl_sl_link_table=XLA_L.gl_sl_link_table
--and gl.ledger_id = xla_h.ledger_id
--AND
xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
and xs.je_source_name != 'Cost Management'
and (xla_l.gl_sl_link_id,xla_l.gl_sl_link_table) in (select ir.gl_sl_link_id, ir.gl_sl_link_table from
gl_import_references ir,
gl_je_lines gl_l
where ir.je_header_id = gl_l.je_header_id
and gl_l.je_line_num=ir.je_line_num
and gl_l.period_name =NVL(:1,gl_l.period_name)
and gl_l.code_combination_id =:2)
UNION
SELECT
lines.code_combination_id LINE_CODE_COMBINATION_ID,
lr.target_ledger_name LEDGER_NAME,
fnd_flex_ext.get_segs('SQLGL', 'GL#', b.chart_of_accounts_id, lines.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (b.chart_of_accounts_id, lines.code_combination_id) account_description,
h.date_created,
null,
null,
null,
null,
null,
null,
h.ledger_id LEDGER_ID,
lines.entered_dr LINE_ENTERED_DR,
lines.entered_cr LINE_ENTERED_CR,
lines.ledger_id LINE_LEDGER_ID,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
lines.description LINE_DESCRIPTION,
null FLEET_NUMBER,
null Vendor_Name,
h.je_source JournalSource,
h.je_category JournalCategory,
lines.JE_LINE_NUM Line
FROM gl_period_statuses ps,
gl_je_lines lines,
gl_je_headers h,
gl_je_batches b,
gl_ledger_relationships lr
WHERE lr.source_ledger_id = lr.target_ledger_id
--AND lr.target_currency_code = DECODE ( GLR03300_pkg.get_ledger_currency, 'ALL123456789012345', lr.target_currency_code, GLR03300_pkg.get_ledger_currency )
AND lr.application_id = 101
AND b.average_journal_flag = 'N'
AND b.je_batch_id = h.je_batch_id
AND b.actual_flag = 'A'
AND h.je_header_id = lines.je_header_id
AND h.currency_code = DECODE ( GLR03300_PKG.get_entered_currency_code, 'ALL123456789012345', h.currency_code, NULL, h.currency_code, GLR03300_pkg.get_entered_currency_code )
AND h.ledger_id = lr.source_ledger_id
AND lines.period_name = ps.period_name
and lines.period_name = NVL(:3,lines.period_name)
AND ps.ledger_id = lines.ledger_id
AND ps.application_id = 101
AND lines.code_combination_id=:4
AND h.je_source != 'Cost Management'
UNION
SELECT /*+ parallel(xla_l) parallel(xla_h) leading(xla_h) */ gl_l.code_combination_id LINE_CODE_COMBINATION_ID,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description,
xla_h.accounting_date,--gjh.date_created,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
null,
null,
null,
null,
xla_h.ledger_id LEDGER_ID,
NVL(xla_l.entered_dr,0) LINE_ENTERED_DR,
NVL(xla_l.entered_cr,0) LINE_ENTERED_CR,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,-- gl_l.description LINE_DESCRIPTION,
cii.instance_number FLEET_NUMBER,
(select a.vendor_name
from RCV_VRC_TXS_VENDINT_V a
where a.wip_entity_id = mmt.TRANSACTION_SOURCE_ID
AND a.organization_id = mmt.organization_id
and a.item_id = mmt.inventory_item_id) Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
gl_l.JE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et,
xla.xla_event_classes_tl ec,
xla.xla_transaction_entities te,
gl_budget_versions bud,
gl_import_references ir,
xla.xla_subledgers xs,
gl_je_lines gl_l,
mtl_transaction_accounts mta,
XLA_TRANSACTION_ENTITIES_upg xte,
xla_distribution_links xdl,
mtl_material_transactions mmt,
WIP_ENTITIES WIE,
WIP_DISCRETE_JOBS WDJ,
csi_item_instances CII
where
ir.gl_sl_link_id=XLA_L.gl_sl_link_id
and ir.je_header_id = gl_l.je_header_id
and gl_l.je_line_num=ir.je_line_num
and ir.gl_sl_link_table=XLA_L.gl_sl_link_table
and gl_l.period_name =NVL(:5,gl_l.period_name)
and gl_l.code_combination_id = :6
and xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
AND mta.reference_account = gl_l.code_combination_id
AND mmt.transaction_id = mta.transaction_id
and mta.transaction_id = xte.source_id_int_1
AND mta.inventory_item_id =mmt.inventory_item_id
AND mta.organization_id = mmt.organization_id
AND mmt.transaction_type_id = 35
and xte.entity_id = xla_e.entity_id
and xdl.source_distribution_type = 'MTL_TRANSACTION_ACCOUNTS'
and xdl.source_distribution_id_num_1 = mta.inv_sub_ledger_id
and xdl.APPLICATION_ID=707
and xla_h.ae_header_id = xdl.ae_header_id
and xdl.ae_header_id = XLA_L.ae_header_id
and ir.gl_sl_link_table = 'XLAJEL'
and ir.gl_sl_link_id = XLA_L.gl_sl_link_id
and gl_l.je_header_id = ir.je_header_id
and gl_l.je_line_num = ir.je_line_num
and mmt.TRANSACTION_SOURCE_ID = wie.wip_entity_id
AND mmt.organization_id = wdj.organization_id
and wie.wip_entity_id = wdj.wip_entity_id
and wdj.asset_group_id = cii.inventory_item_id
and wdj.maintenance_object_id=cii.instance_id
and xs.je_source_name = 'Cost Management'
UNION
SELECT /*+ parallel(XLA_L) parallel(xla_h) leading(xla_h) */ gl_l.code_combination_id LINE_CODE_COMBINATION_ID,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description,
xla_h.accounting_date,--gjh.date_created,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
null,
null,
null,
null,
xla_h.ledger_id LEDGER_ID,
NVL(xla_l.entered_dr,0) LINE_ENTERED_DR,
NVL(xla_l.entered_cr,0) LINE_ENTERED_CR,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,-- gl_l.description LINE_DESCRIPTION,
cii.instance_number FLEET_NUMBER,
(select a.vendor_name
from RCV_VRC_TXS_VENDINT_V a
where a.wip_entity_id = wta.wip_entity_id
AND a.organization_id = wta.organization_id
and a.item_id = cii.inventory_item_id) Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
gl_l.JE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et,
xla.xla_event_classes_tl ec,
xla.xla_transaction_entities te,
gl_budget_versions bud,
gl_import_references ir,
xla.xla_subledgers xs,
gl_je_lines gl_l,
wip_transaction_accounts wta,
XLA_TRANSACTION_ENTITIES_upg xte,
xla_distribution_links xdl,
-- mtl_material_transactions mmt,
WIP_ENTITIES WIE,
WIP_DISCRETE_JOBS WDJ,
csi_item_instances CII
where
ir.gl_sl_link_table=XLA_L.gl_sl_link_table
and gl_l.period_name =NVL(:7,gl_l.period_name)
and gl_l.code_combination_id = :8
and xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
AND wta.reference_account = gl_l.code_combination_id
and wta.transaction_id = xte.source_id_int_1(+)
and xte.entity_id = xla_e.entity_id
and xdl.source_distribution_type = 'WIP_TRANSACTION_ACCOUNTS'
and xdl.source_distribution_id_num_1 = wta.wip_sub_ledger_id(+)
and xdl.APPLICATION_ID=707
and xla_h.ae_header_id = xdl.ae_header_id
and xdl.ae_header_id = XLA_L.ae_header_id
and ir.gl_sl_link_table = 'XLAJEL'
and ir.gl_sl_link_id = XLA_L.gl_sl_link_id
and gl_l.je_header_id = ir.je_header_id
and gl_l.je_line_num = ir.je_line_num
and wie.wip_entity_id = wta.wip_entity_id
AND wta.organization_id = wdj.organization_id
and wie.wip_entity_id = wdj.wip_entity_id
and wdj.asset_group_id = cii.inventory_item_id
and wdj.maintenance_object_id=cii.instance_id
and xs.je_source_name = 'Cost Management'
Please help me in tuning the above query.
Thanks
Raghava

UIMsg_RefreshWindows is taking too long to execute

Hi all,
I have a Process Model sequence file that calls the PostUIMessageEx method with the UIMsg_RefreshWindows parameter on the SequenceFielPostStepRuntimeError and the SequenceFilePostStepFailure callbacks. This has been taking really long to execute (>3 minutes) since I moved to TS3.5 about a month ago. Do you guys know of any issue of this method with these particular parameters on TS3.5? What could be causing this problem?
Attachments:
UIMsg.jpg ‏92 KB

Hi, <<...
There is nothing out of normal among your parameters. The synchronize option you selected is going to make the method wait until the operator interface process the message. So it depends on what you put in your UI message event handler. I'm not aware of anything related to this method itself that could cause this slow execution behavior. If you could send us a simplified version of the project, maybe we can further investigate the issue.
Song D
Regards,
Song Du
Systems Software
National Instruments R&D

Streamline query ? Taking too long

First I wanted to say thanks to all in this forum, its been a huge help learning sql.
Hoping someone can take a look at this query. It works but it takes a very long time to run.
maybe there is a way to streamline it. right now its using one project number, but typically I would put in 60 or 70 project numbers here..
select proj_id from project_master where status='A' and project_number IN(
'502998'
)))c,
if someone knows a better way to run this please let me know , I will try anything. currently it takes about an hour to run it for 1 project number.
select * from(
select
b.doc_folder_id,c.project_number,b.name,a.doc_file_name,a.rec_update_date,a.rec_create_date,d.rnk
from
select doc_id,proj_id, doc_file_name,rec_create_date,rec_update_date from document_master where doc_status ='A'
and doc_file_extension like 'pdf' or doc_file_extension like 'jpg'
or doc_file_extension like 'xls' or doc_file_extension like 'doc'
or doc_file_extension like 'txt' or doc_file_extension like 'png'
or doc_file_extension like 'tif' or doc_file_extension like 'ppt'
or doc_file_extension like 'pps' or doc_file_extension like 'msg'
) a,
(select * from doc_folder_master
where upper(name) LIKE '%DAILY REPORTS%'
OR upper(name) LIKE '%MANPOWER REPORTS%'
OR upper(name) LIKE '%SITE PURCHASES%'
OR upper(name) LIKE '%SETE EHS ISSUES%'
OR upper(name) LIKE '%TURNOVER PACKAGES%'
OR upper(name) LIKE '11.04.01 PAD%'
OR upper(name) LIKE '%EDSR%'
OR upper(name) LIKE '%COQ WORKFLOW%'
and status='A'
) b,
(select proj_id,project_number from project_master where proj_id IN (
select proj_id from project_master where status='A' and project_number IN(
'502998'
)))c,
(select child_doc_type,
parent_doc_id,child_doc_id,to_char(rec_create_date,'mm/dd/yyyy hh24:mi:ss'),
row_number() over (partition by parent_doc_id,child_doc_type order by rec_create_date desc) rnk
from document_relations)d
where a.proj_id=b.proj_id
and c.proj_id=a.proj_id
and c.proj_id=b.proj_id
and d.parent_doc_id=b.doc_folder_id
and a.doc_id=d.child_doc_id)
where rnk <3
thanks for any assistance.
Edited by: Jay on Dec 29, 2010 12:08 PM

Hi,
Please, you might want to read this post:
When your query takes too long ...
Providing further information is key to obtaining quality answers.
Now on to the actual subject:
It seems you want some sort of top-n query. Depending on the cardinality and the data that you have, you probably would want to prune the rows from the DOCUMENT_RELATIONS table early, before joining to the other tables. This way you can avoid the database wasting effort of looking up matches on the other tables to only then discard those joined rows. You can do that by pushing the WHERE rnk < 3 predicate into the inline view.
SELECT *
FROM (SELECT b.doc_folder_id, c.project_number, b.name, a.doc_file_name, a.rec_update_date, a.rec_create_date, d.rnk
          FROM (SELECT doc_id, proj_id, doc_file_name, rec_create_date, rec_update_date
                  FROM document_master
                 WHERE doc_status = 'A'
                       AND doc_file_extension IN ('pdf', 'jpg', 'xls', 'doc', 'txt', 'png', 'tif', 'ppt', 'pps', 'msg')) a,
               (SELECT *
                  FROM doc_folder_master
                 WHERE upper(NAME) LIKE '%DAILY REPORTS%'
                       OR upper(NAME) LIKE '%MANPOWER REPORTS%'
                       OR upper(NAME) LIKE '%SITE PURCHASES%'
                       OR upper(NAME) LIKE '%SETE EHS ISSUES%'
                       OR upper(NAME) LIKE '%TURNOVER PACKAGES%'
                       OR upper(NAME) LIKE '11.04.01 PAD%'
                       OR upper(NAME) LIKE '%EDSR%'
                       OR upper(NAME) LIKE '%COQ WORKFLOW%'
                       AND status = 'A') b,
               (SELECT proj_id, project_number
                  FROM project_master
                 WHERE proj_id IN (SELECT proj_id
                                     FROM project_master
                                    WHERE status = 'A'
                                          AND project_number IN ('502998'))) c,
               (SELECT *
                  FROM (SELECT child_doc_type,
                               parent_doc_id,
                               child_doc_id,
                               to_char(rec_create_date, 'mm/dd/yyyy hh24:mi:ss'),
                               row_number() over(PARTITION BY parent_doc_id, child_doc_type ORDER BY rec_create_date DESC) rnk
                          FROM document_relations)
                 WHERE rnk < 3) d
         WHERE a.proj_id = b.proj_id
               AND c.proj_id = a.proj_id
               AND c.proj_id = b.proj_id
               AND d.parent_doc_id = b.doc_folder_id
               AND a.doc_id = d.child_doc_id)Like Toon said, if not needed you should avoid the 2nd scan in the PROJECT_MASTER table.
Perhaps you should check the possibility of creating a function-based index on the doc_folder_master table, with the upper(NAME) expression, to improve those Like conditions.
Docs on Function-based Indexes:
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/data_acc.htm#PFGRF94785

Connect by level query is taking too long time to run

Hello,
I have a query that returns quarters (YYYYQ) of a begin- and enddate within a specific id, that is built with a connect by level clause, but the query is running to long. I have used explain plan to see what the query is doing, but no silly things to see, just a full table scan, with low costs.
This is the query:
select to_char(add_months( cpj.crpj_start_date,3*(level - 1)),'YYYYQ') as sales_quarter
, cpj.crpj_id as crpj_id
from mv_gen_cra_projects cpj
where cpj.crpj_start_date >= to_date('01/01/2009','mm/dd/yyyy')
and cpj.crpj_start_date <= cpj.crpj_end_date
and cpj.crpj_routing_type = 'A'
and ( cpj.crpj_multi_artist_ind = 'N'
or cpj.crpj_multi_artist_ind is null)
connect by level <= 1 + ceil(months_between(cpj.crpj_end_date,cpj.crpj_start_date)/3);
The result have to be like this:
SALES_QUARTER CRPJ_ID
20091 100
20092 100
20093 100
20094 100
20101 100
20102 100
Can anyone help me out with this?

but no silly things to see, just a full table scan, with low costs.Well, maybe an index scan would be faster?
However:
You will need to provide us some more details, like:
- database version (the result of: SQL> select * from v$version;)
- post the explain plan output (put the tag before and after it, so indentation and formatting are maintained, see the [FAQ|http://forums.oracle.com/forums/help.jspa] for more explanation regarding tags )
- what are your optimizer settings (the result of: SQL> show parameter optimizer)
- if applicable: are your table statistics up to date?
- mv_gen_cra_projects is a materialized view perhaps?
Edited by: hoek on Jan 26, 2010 10:50 AM

Query taking too long to execute

Hi All,
I have just moved a cube from DEV to Q and loaded the data(using INIT). I have created a query to test the data. When I execute the query, the initial result is showing up quickly but when I drill down using one char, say CHAR ABC, it is taking a lot time(I am waiting from last 25 min to see the result but it is still running). The same query is not taking any time when run in T. What could be the problem. This query is my first query in Q.
Any suggestions would be highly appreciated.
Best Rgds,
James.

GO to RSRV and you will see a an option " All combined tests.
IN that, you will see " Check data for master data". Double click that and enter your CHAR* and run the test.
Next under transaction data " run each of the tests" for the ODS / Cube that you run the report from.
These tests usually will point to inconsistency. You may also want to look the design of cube / ODS. In ODS, you may have to check the key fields.
Ravi Thothadri

Query taking too long to execute on Oracle 9i

Mark,
If you remember, I was working on a large xml document with deep nested complex elements.
I am trying to query the document and as such I am running a join query. The database is not able to run this query and I am wondering if there is any alternate way to rephrase this query.
PS: I have run this query for almost 24 hrs without any result.
Here is the query:
select extract(value(X),'//eNest[@aSixtyFour=2][@aUnique1=//eNest[@aSixtyFour=2]/@aUnique1]/@aUnique1')
from OracleBench_No_Schema X
any feedback would be extremely helpful
Thanks
JN

John
I'm not sure that I can be of much more help at the moment. We are working to improive the performance of //queries over recursive structures. These enhancements will appear in future release of the product.

Background Job RSPPFPROCESS Taking too long to execute.

Hi Gurus,
I'm working with SAP CRM 2007 - Interaction Centre
We have configured first response date and to do by date in item category.
If agent fails to response within the first response date or if agent fails to complete
to close the ticket within the to do by date,An action is configured to trigger and an
escalation email(Smart Form) is sent to agent`s manager inbox.
We have scheduled background job for the program RSPPFPROCESS with variant in background
to trigger this actions( It is scheduled 4 times in a day ).
Previously this job used to take 6 hours to complete execution.
But now its taking 12 hours to complete the execution and there is no change in the
variant.
Can anyone please advice me reason for this behavior.
Kind Regards,
Vinod

Hi Manfred,
We are experiencing similar performance issue when running the RSPPFPROCESS Job. We opened a OSS message for quite some time but didn't get any useful help from SAP.
Can you please provide more information regarding your ZRSPPFPROCESS program on identifying the crtical performance steps to resolve the performance issue? We are also thinking of archiving the record in table PPFTTRIGG , we have over 73+ millions records in the table but there is no archiving object for PPF actions. We would like to focus on reducing the number of entries in the table PPFTTRIGG hopefully to improve the performance. Any thoughts on it?
Thanks in advance for your kind help!
Best Regards,
Madeline

Query is taking too long fetch data

Hi,
Working on EBS Version 11.5.10.2
This below query takes 7 minutes reterive to job orders. I need some help to improve this query to retrieve faster.
select inventory_item_id
,job
,item_code
,item_description
,subinventory_code
,locators
,quantity_open
,sum(transaction_quantity) qoh
from
select wrv.inventory_item_id
,wdj.wip_entity_name Job
,rtrim(wrv.concatenated_segments) item_code
,wrv.item_description
,mil.subinventory_code
,mil.segment1||'.'||mil.segment2||'.'||mil.segment3 locators
,wrv.quantity_open
,transaction_quantity
from wip_discrete_jobs_v wdj
,wip_requirement_operations_v wrv
,mtl_onhand_quantities moh
,mtl_item_locations mil
where wdj.wip_entity_id = wrv.wip_entity_id
and moh.inventory_item_id = wrv.inventory_item_id
and mil.inventory_location_id = moh.locator_id
and wdj.job_type_meaning = 'Standard'
and wdj.status_type_disp = 'Released'
and wrv.quantity_open > 0
and wrv.organization_id = 0
and moh.organization_id = 0
and mil.organization_id = 0
--and rtrim(wrv.concatenated_segments) = '2124 2014-336'
and wdj.wip_entity_name in ('D477334') --,'D612664')
group by
inventory_item_id
,job
,item_code
,item_description
,subinventory_code
,locators
,quantity_open
Thanks and Regards

{message:id=9360003}

Query taking too long on Oracle9i

Hi All
I am running a query on our prod database (Oracle8i 8.1.7.4) and again running the same query on Test db (Oracle9i version 4). The query is taking too long(more then 10 min) in test db. Both the database are installed on the same machine IBM AIX V4 and table schema and data are same.
Any help would be appreciated.
Here are the results.
FASTER ONE
ORACLE 8i using Production
Statistics
864 recursive calls
68 db block gets
159855 consistent gets
20297 physical reads
0 redo size
1310148 bytes sent via SQL*Net to client
68552 bytes received via SQL*Net from client
1036 SQL*Net roundtrips to/from client
28 sorts (memory)
1 sorts (disk)
15525 rows processed
SLOWER ONE
ORACLE 9i using Test
Statistics
819 recursive calls
80 db block gets
22981568 consistent gets
1361 physical reads
0 redo size
1194902 bytes sent via SQL*Net to client
34193 bytes received via SQL*Net from client
945 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
14157 rows processed

319404-
To help us better understand the problem,
1) Could you post your execution plan on the two different databases?
2) Could you list indexes (if any, on these tables)?
3) Are any of the objects in the 'from list' a view?
If so, are you using a user defined function to create the view?
4) Why are you using the table 'cal_instance_relationship' twice in the 'from ' clause'?
5) Can't your query be the following?
SELECT f.person_id, f.course_cd, cv.responsible_org_unit_cd cowner, f.fee_cal_type Sem, f.fee_ci_sequence_number seq_no,
sua.unit_cd, uv.owner_org_unit_cd uowner, uv.supervised_contact_hours hours, 0 chg_rate, sum(f.transaction_amount) tot_fee,
' ' tally
FROM unit_version uv,
cal_instance_relationship cir1,
chg_method_apportion cma,
student_unit_attempt sua,
course_version cv,
fee_ass f
WHERE f.fee_type = 'VET-MATFEE'
AND f.logical_delete_dt IS NULL
AND f.s_transaction_type IN ('ASSESSMENT', 'MANUAL ADJ')
AND f.fee_ci_sequence_number > 400
AND f.course_cd = cv.course_cd
AND cv.version_number = (SELECT MAX(v.version_number) FROM course_version v
WHERE v.course_cd = cv.course_cd)
AND f.person_id = sua.person_id
and f.course_cd = sua.course_cd
AND f.fee_type = cma.fee_type
AND f.fee_ci_sequence_number = cma.fee_ci_sequence_number
AND cma.load_ci_sequence_number = cir1.sub_ci_sequence_number
AND cir1.sup_cal_type = 'ACAD-YR'
AND cir1.sub_cal_type = sua.cal_type
AND cir1.sub_ci_sequence_number = sua.ci_sequence_number
AND sua.unit_attempt_status NOT IN ('DUPLICATE','DISCONTIN')
AND sua.unit_cd = uv.unit_cd
AND sua.version_number = uv.version_number
GROUP BY f.person_id, f.course_cd, cv.responsible_org_unit_cd , f.fee_cal_type, f.fee_ci_sequence_number,
sua.unit_cd, uv.owner_org_unit_cd, uv.supervised_contact_hours;

Query running for too long

Hi All,
Can someone pls help me in finding how long will it take to execute the below query.
I have a query that is taking too long to execute.
SELECT   CPU_TIME/1000000/60 CPUTIME, ELAPSED_TIME/1000000/60 ELAPSEDTIME, PROGRAM_LINE#, OPTIMIZER_COST,
USER_IO_WAIT_TIME/1000000/60 IOWAITTIME, DISK_READS, DIRECT_WRITES, BUFFER_GETS, to_char(Q.SQL_FULLTEXT), OPTIMIZER_MODE, SHARABLE_MEM, PERSISTENT_MEM, RUNTIME_MEM, SORTS, FETCHES, EXECUTIONS, END_OF_FETCH_COUNT, USERS_EXECUTING, LOADS,
FIRST_LOAD_TIME, INVALIDATIONS, PARSE_CALLS, APPLICATION_WAIT_TIME, CONCURRENCY_WAIT_TIME, CLUSTER_WAIT_TIME,
PLSQL_EXEC_TIME, JAVA_EXEC_TIME, ROWS_PROCESSED, COMMAND_TYPE, PARSING_USER_ID, PARSING_SCHEMA_ID, PARSING_SCHEMA_NAME, OBJECT_STATUS
     FROM     v$session S, v$sqlarea Q
     WHERE    S.SQL_ADDRESS = Q.ADDRESS
     AND      s.username = 'SCHEMA_NAME'
     AND       s.osuser = 'OSUSER_NAME';I can see CPU_TIME increasing. Is there any way that I can find how lmuch more time will it take for the query to execute.
The query creates a table that has a sub query and inner query.
rgds
saaz

http://www.gplivna.eu/papers/v$session_longops.htm
There is a dynamic performance view v$session_longops that is populated for many long running operations in Oracle. The primary criterion for any operation to appear in v$session_longops is to run more than 6 seconds. Although this isn’t the only criterion as well as not all operations that take more than 6 seconds are shown in this view. For example one can find hash joins in v$session_longops, but you won’t find there nested loop joins even if they are longer than 6 seconds and are joining very big data sets.

R/3 Extraction taking too long to load data into BW

HI There,
I'm trying to extract SAP Standard extractor 0FI_AP_4 into BW, and its taking endless time.
Even the Extract checker RSA3 is taking too long to execute the data. Dont know why its taking so long to execute.
Since there in not much data to take such a long time.
Enhanced the datasource with three fields from BSEG using user exits.
Is that the reason why its taking too long? Does User Exit slows down the extraction process?
What measures i should take to quicken the process?
Thanks for your time
Vandana

Thanks for all you replies.
Please go through the steps I've gone through :
- Installed the Business Content and its in version 3.5
- Changed the update rules, Transfer rules and migrated the datasource to BI 7
- Enhanced the 0FI_AP_3 to include three fields BSEG table
- Ran RSA3 and the new fields are showing but the loading is quite slow.
- Commented the code and ran RSA3 and with little difference data is showing up
- Removed the comments and ran, its fine, though it takes little more time then previous step...but data is showing up
- Replicated the datasource into BW
- Created the info package and started the init process (before this deleted the previous stored init process)
- Data isn't loading and please see the error message below.
Diagnosis
The data request was a full update. In this case, the corresponding table in the source system does not
contain any data. System Response Info IDoc received with status 8. Procedure Check the data basis in the source system.
- Checked the transformation between datasource 0FI_AP_4 and Infosource ZFI_AP_4
and I DID NOT found the three fields which i enhanced from BSEG table in the 0FI_AP_4 datasource.
- Replicated the datasource 0FI_AP_4 again, but no change.
Now...I dont know whats happening here.
When i check the datasource 0FI_AP_4 in RSA6, i can see the three new fields from BSEG.
When i check RSA3, i can see the data getting populated with the three new fields from BSEG,
When i check the fields in the datasource 0FI_AP_4 in BW, I can see the three new fields. It shows
that the connection between BW and R/3 is fine, isn't it?
Now...Can anyone please suggest me how to go forward from here?
Thanks for your time
Vandana

RPM_FIN02 taking too long

Hi,
RPM_FIN02 is taking too long to execute it actually takes about 10 hours running on the background, How can we resolve this issue.
Regards,
Siyabonga

Hi Siya
Have you setup variants for all the projects?
In order to them run as 'batch jobs'?
Let me know if this helps, but it has to be done, thereafter we can look at a few SAP Notes that I can provide.
Regards,
Ihsaan Mayet

Query is taking too long to execute - contd

Similar Messages

Maybe you are looking for