Query taling 01:40:38 to execute

Dear All,
I am facing a lot of issue with this query. There are multiple session waits are present with this query. Here I am attaching the Explain plan of my query.
[code]
PLAN_TABLE_OUTPUT
Plan hash value: 967177145
| Id | Operation                                         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                                  |                | 23062 |    34M| 3759K (1)| 01:40:38 |
|   1 | NESTED LOOPS OUTER                               |                | 23062 |    34M| 3759K (1)| 01:40:38 |
|   2 |   NESTED LOOPS OUTER                              |                | 23062 |    32M| 3685K (1)| 01:38:39 |
|   3 |    NESTED LOOPS OUTER                             |                | 23062 |    32M| 3640K (1)| 01:37:26 |
|   4 |     NESTED LOOPS OUTER                            |                | 23062 |    32M| 3621K (1)| 01:36:57 |
|   5 |      NESTED LOOPS OUTER                           |                | 23062 |    31M| 3565K (1)| 01:35:27 |
|   6 |       NESTED LOOPS OUTER                          |                | 23062 |    30M| 3547K (1)| 01:34:57 |
|   7 |        NESTED LOOPS OUTER                         |                | 23062 |    30M| 3473K (1)| 01:32:58 |
|   8 |         NESTED LOOPS OUTER                        |                | 23062 |    29M| 3467K (1)| 01:32:49 |
|   9 |          NESTED LOOPS OUTER                       |                | 23062 |    29M| 3411K (1)| 01:31:20 |
| 10 |           NESTED LOOPS OUTER                      |                | 23062 |    26M| 3367K (1)| 01:30:08 |
| 11 |            NESTED LOOPS OUTER                     |                | 23062 |    25M| 3322K (1)| 01:28:56 |
| 12 |             NESTED LOOPS OUTER                    |                | 23062 |    25M| 3322K (1)| 01:28:56 |
| 13 |              NESTED LOOPS OUTER                   |                | 23062 |    24M| 3322K (1)| 01:28:56 |
| 14 |               NESTED LOOPS OUTER                  |                | 23062 |    23M| 3322K (1)| 01:28:56 |
| 15 |                NESTED LOOPS OUTER                 |                | 23062 |    23M| 3285K (1)| 01:27:57 |
| 16 |                 NESTED LOOPS OUTER                |                | 23062 |    22M| 3248K (1)| 01:26:58 |
| 17 |                  NESTED LOOPS                     |                | 23062 |    20M| 3192K (1)| 01:25:28 |
| 18 |                   NESTED LOOPS OUTER              |                |    72 | 28944 |   385   (2)| 00:00:01 |
| 19 |                    NESTED LOOPS OUTER             |                |    72 | 27576 |   327   (2)| 00:00:01 |
| 20 |                     NESTED LOOPS OUTER            |                |    72 | 26568 |   326   (2)| 00:00:01 |
| 21 |                      NESTED LOOPS                 |                |    72 | 25200 |   268   (3)| 00:00:01 |
| 22 |                       NESTED LOOPS                |                |    78 | 2808 |   143   (4)| 00:00:01 |
|* 23 |                        TABLE ACCESS FULL          | S_VOD_VER      |    77 | 1386 |    72   (7)| 00:00:01 |
| 24 |                        TABLE ACCESS BY INDEX ROWID| S_VOD          |     1 |    18 |     1   (0)| 00:00:01 |
|* 25 |                         INDEX UNIQUE SCAN         | S_VOD_P1       |     1 |       |     1   (0)| 00:00:01 |
| 26 |                       TABLE ACCESS BY INDEX ROWID | S_PROD_INT     |     1 |   314 |     2   (0)| 00:00:01 |
|* 27 |                        INDEX RANGE SCAN           | S_PROD_INT_F9 |     1 |       |     1   (0)| 00:00:01 |
| 28 |                      TABLE ACCESS BY INDEX ROWID | S_PROD_LN      |     1 |    19 |     1   (0)| 00:00:01 |
|* 29 |                       INDEX UNIQUE SCAN           | S_PROD_LN_P1   |     1 |       |     1   (0)| 00:00:01 |
| 30 |                     TABLE ACCESS BY INDEX ROWID   | S_CTLG_CAT     |     1 |    14 |     1   (0)| 00:00:01 |
|* 31 |                      INDEX UNIQUE SCAN            | S_CTLG_CAT_P1 |     1 |       |     1   (0)| 00:00:01 |
| 32 |                    TABLE ACCESS BY INDEX ROWID    | S_CTLG_CAT     |     1 |    19 |     1   (0)| 00:00:01 |
|* 33 |                     INDEX UNIQUE SCAN             | S_CTLG_CAT_P1 |     1 |       |     1   (0)| 00:00:01 |
|* 34 |                   TABLE ACCESS BY INDEX ROWID     | S_ASSET        |   322 |   160K| 44341   (1)| 00:01:12 |
|* 35 |                    INDEX RANGE SCAN               | S_ASSET_U2     | 56567 |       |   297   (3)| 00:00:01 |
| 36 |                  TABLE ACCESS BY INDEX ROWID      | S_ASSET_OM     |     1 |    94 |     2   (0)| 00:00:01 |
|* 37 |                   INDEX RANGE SCAN                | S_ASSET_OM_U1 |     1 |       |     2   (0)| 00:00:01 |
| 38 |                 TABLE ACCESS BY INDEX ROWID       | S_CONTACT      |     1 |    40 |     2   (0)| 00:00:01 |
|* 39 |                  INDEX UNIQUE SCAN                | S_CONTACT_P1   |     1 |       |     1   (0)| 00:00:01 |
| 40 |                TABLE ACCESS BY INDEX ROWID        | S_ADDR_PER     |     1 |    29 |     2   (0)| 00:00:01 |
|* 41 |                 INDEX UNIQUE SCAN                 | S_ADDR_PER_P1 |     1 |       |     1   (0)| 00:00:01 |
| 42 |               TABLE ACCESS BY INDEX ROWID         | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 43 |                INDEX UNIQUE SCAN                  | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 44 |              TABLE ACCESS BY INDEX ROWID          | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 45 |               INDEX UNIQUE SCAN                   | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 46 |             TABLE ACCESS BY INDEX ROWID           | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 47 |              INDEX UNIQUE SCAN                    | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 48 |            TABLE ACCESS BY INDEX ROWID            | S_ORG_EXT      |     1 |    36 |     2   (0)| 00:00:01 |
|* 49 |             INDEX UNIQUE SCAN                     | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 50 |           TABLE ACCESS BY INDEX ROWID             | S_ORG_EXT      |     1 |   139 |     2   (0)| 00:00:01 |
|* 51 |            INDEX UNIQUE SCAN                      | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 52 |          TABLE ACCESS BY INDEX ROWID              | S_ORG_EXT_X    |     1 |    16 |     2   (0)| 00:00:01 |
|* 53 |           INDEX RANGE SCAN                        | S_ORG_EXT_X_U1 |     1 |       |     2   (0)| 00:00:01 |
|* 54 |         INDEX UNIQUE SCAN                         | S_PARTY_P1     |     1 |    12 |     1   (0)| 00:00:01 |
| 55 |        TABLE ACCESS BY INDEX ROWID                | S_ASSET_BU     |     1 |    34 |     3   (0)| 00:00:01 |
|* 56 |         INDEX RANGE SCAN                          | S_ASSET_BU_U1 |     1 |       |     2   (0)| 00:00:01 |
|* 57 |       INDEX UNIQUE SCAN                           | S_PARTY_P1     |     1 |    12 |     1   (0)| 00:00:01 |
| 58 |      TABLE ACCESS BY INDEX ROWID                  | S_ASSET        |     1 |    37 |     2   (0)| 00:00:01 |
|* 59 |       INDEX UNIQUE SCAN                           | S_ASSET_P1     |     1 |       |     2   (0)| 00:00:01 |
| 60 |     TABLE ACCESS BY INDEX ROWID                   | S_PROD_INT     |     1 |    16 |     1   (0)| 00:00:01 |
|* 61 |      INDEX UNIQUE SCAN                            | S_PROD_INT_P1 |     1 |       |     1   (0)| 00:00:01 |
| 62 |    TABLE ACCESS BY INDEX ROWID                    | S_ORG_EXT      |     1 |    14 |     2   (0)| 00:00:01 |
|* 63 |     INDEX UNIQUE SCAN                             | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 64 |   TABLE ACCESS BY INDEX ROWID                     | S_ASSET_X      |     1 |    93 |     3   (0)| 00:00:01 |
|* 65 |    INDEX RANGE SCAN                               | S_ASSET_X_U1   |     1 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=TO_NUMBER(:1))
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID"(+))
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID"(+))
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID"(+))
34 - filter("T23"."SERIAL_NUM" LIKE :2)
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID"(+))
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID"(+))
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID"(+))
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID"(+))
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID"(+))
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID"(+))
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID"(+))
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID"(+))
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID"(+))
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID"(+))
56 - access("T23"."ROW_ID"="T15"."ASSET_ID"(+) AND "T23"."BU_ID"="T15"."BU_ID"(+))
57 - access("T15"."BU_ID"="T13"."ROW_ID"(+))
59 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID"(+))
61 - access("T19"."PROD_ID"="T2"."ROW_ID"(+))
63 - access("T15"."BU_ID"="T5"."PAR_ROW_ID"(+))
65 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID"(+))
100 rows selected.
[/code]

Hi,
it's hard to get the new crappy editor to properly format plans and code snippets -- the only way I've managed to do this so far is by switching to HTML mode and using <pre>...</pre> tags, e.g.:
| Id | Operation                                         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                                  |                | 23062 |    34M| 3759K (1)| 01:40:38 |
|   1 | NESTED LOOPS OUTER                               |                | 23062 |    34M| 3759K (1)| 01:40:38 |
|   2 |   NESTED LOOPS OUTER                              |                | 23062 |    32M| 3685K (1)| 01:38:39 |
|   3 |    NESTED LOOPS OUTER                             |                | 23062 |    32M| 3640K (1)| 01:37:26 |
|   4 |     NESTED LOOPS OUTER                            |                | 23062 |    32M| 3621K (1)| 01:36:57 |
|   5 |      NESTED LOOPS OUTER                           |                | 23062 |    31M| 3565K (1)| 01:35:27 |
|   6 |       NESTED LOOPS OUTER                          |                | 23062 |    30M| 3547K (1)| 01:34:57 |
|   7 |        NESTED LOOPS OUTER                         |                | 23062 |    30M| 3473K (1)| 01:32:58 |
|   8 |         NESTED LOOPS OUTER                        |                | 23062 |    29M| 3467K (1)| 01:32:49 |
|   9 |          NESTED LOOPS OUTER                       |                | 23062 |    29M| 3411K (1)| 01:31:20 |
| 10 |           NESTED LOOPS OUTER                      |                | 23062 |    26M| 3367K (1)| 01:30:08 |
| 11 |            NESTED LOOPS OUTER                     |                | 23062 |    25M| 3322K (1)| 01:28:56 |
| 12 |             NESTED LOOPS OUTER                    |                | 23062 |    25M| 3322K (1)| 01:28:56 |
| 13 |              NESTED LOOPS OUTER                   |                | 23062 |    24M| 3322K (1)| 01:28:56 |
| 14 |               NESTED LOOPS OUTER                  |                | 23062 |    23M| 3322K (1)| 01:28:56 |
| 15 |                NESTED LOOPS OUTER                 |                | 23062 |    23M| 3285K (1)| 01:27:57 |
| 16 |                 NESTED LOOPS OUTER                |                | 23062 |    22M| 3248K (1)| 01:26:58 |
| 17 |                  NESTED LOOPS                     |                | 23062 |    20M| 3192K (1)| 01:25:28 |
| 18 |                   NESTED LOOPS OUTER              |                |    72 | 28944 |   385   (2)| 00:00:01 |
| 19 |                    NESTED LOOPS OUTER             |                |    72 | 27576 |   327   (2)| 00:00:01 |
| 20 |                     NESTED LOOPS OUTER            |                |    72 | 26568 |   326   (2)| 00:00:01 |
| 21 |                      NESTED LOOPS                 |                |    72 | 25200 |   268   (3)| 00:00:01 |
| 22 |                       NESTED LOOPS                |                |    78 | 2808 |   143   (4)| 00:00:01 |
|* 23 |                        TABLE ACCESS FULL          | S_VOD_VER      |    77 | 1386 |    72   (7)| 00:00:01 |
| 24 |                        TABLE ACCESS BY INDEX ROWID| S_VOD          |     1 |    18 |     1   (0)| 00:00:01 |
|* 25 |                         INDEX UNIQUE SCAN         | S_VOD_P1       |     1 |       |     1   (0)| 00:00:01 |
| 26 |                       TABLE ACCESS BY INDEX ROWID | S_PROD_INT     |     1 |   314 |     2   (0)| 00:00:01 |
|* 27 |                        INDEX RANGE SCAN           | S_PROD_INT_F9 |     1 |       |     1   (0)| 00:00:01 |
| 28 |                      TABLE ACCESS BY INDEX ROWID | S_PROD_LN      |     1 |    19 |     1   (0)| 00:00:01 |
|* 29 |                       INDEX UNIQUE SCAN           | S_PROD_LN_P1   |     1 |       |     1   (0)| 00:00:01 |
| 30 |                     TABLE ACCESS BY INDEX ROWID   | S_CTLG_CAT     |     1 |    14 |     1   (0)| 00:00:01 |
|* 31 |                      INDEX UNIQUE SCAN            | S_CTLG_CAT_P1 |     1 |       |     1   (0)| 00:00:01 |
| 32 |                    TABLE ACCESS BY INDEX ROWID    | S_CTLG_CAT     |     1 |    19 |     1   (0)| 00:00:01 |
|* 33 |                     INDEX UNIQUE SCAN             | S_CTLG_CAT_P1 |     1 |       |     1   (0)| 00:00:01 |
|* 34 |                   TABLE ACCESS BY INDEX ROWID     | S_ASSET        |   322 |   160K| 44341   (1)| 00:01:12 |
|* 35 |                    INDEX RANGE SCAN               | S_ASSET_U2     | 56567 |       |   297   (3)| 00:00:01 |
| 36 |                  TABLE ACCESS BY INDEX ROWID      | S_ASSET_OM     |     1 |    94 |     2   (0)| 00:00:01 |
|* 37 |                   INDEX RANGE SCAN                | S_ASSET_OM_U1 |     1 |       |     2   (0)| 00:00:01 |
| 38 |                 TABLE ACCESS BY INDEX ROWID       | S_CONTACT      |     1 |    40 |     2   (0)| 00:00:01 |
|* 39 |                  INDEX UNIQUE SCAN                | S_CONTACT_P1   |     1 |       |     1   (0)| 00:00:01 |
| 40 |                TABLE ACCESS BY INDEX ROWID        | S_ADDR_PER     |     1 |    29 |     2   (0)| 00:00:01 |
|* 41 |                 INDEX UNIQUE SCAN                 | S_ADDR_PER_P1 |     1 |       |     1   (0)| 00:00:01 |
| 42 |               TABLE ACCESS BY INDEX ROWID         | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 43 |                INDEX UNIQUE SCAN                  | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 44 |              TABLE ACCESS BY INDEX ROWID          | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 45 |               INDEX UNIQUE SCAN                   | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 46 |             TABLE ACCESS BY INDEX ROWID           | S_ORG_EXT      |     1 |    32 |     1   (0)| 00:00:01 |
|* 47 |              INDEX UNIQUE SCAN                    | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 48 |            TABLE ACCESS BY INDEX ROWID            | S_ORG_EXT      |     1 |    36 |     2   (0)| 00:00:01 |
|* 49 |             INDEX UNIQUE SCAN                     | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 50 |           TABLE ACCESS BY INDEX ROWID             | S_ORG_EXT      |     1 |   139 |     2   (0)| 00:00:01 |
|* 51 |            INDEX UNIQUE SCAN                      | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 52 |          TABLE ACCESS BY INDEX ROWID              | S_ORG_EXT_X    |     1 |    16 |     2   (0)| 00:00:01 |
|* 53 |           INDEX RANGE SCAN                        | S_ORG_EXT_X_U1 |     1 |       |     2   (0)| 00:00:01 |
|* 54 |         INDEX UNIQUE SCAN                         | S_PARTY_P1     |     1 |    12 |     1   (0)| 00:00:01 |
| 55 |        TABLE ACCESS BY INDEX ROWID                | S_ASSET_BU     |     1 |    34 |     3   (0)| 00:00:01 |
|* 56 |         INDEX RANGE SCAN                          | S_ASSET_BU_U1 |     1 |       |     2   (0)| 00:00:01 |
|* 57 |       INDEX UNIQUE SCAN                           | S_PARTY_P1     |     1 |    12 |     1   (0)| 00:00:01 |
| 58 |      TABLE ACCESS BY INDEX ROWID                  | S_ASSET        |     1 |    37 |     2   (0)| 00:00:01 |
|* 59 |       INDEX UNIQUE SCAN                           | S_ASSET_P1     |     1 |       |     2   (0)| 00:00:01 |
| 60 |     TABLE ACCESS BY INDEX ROWID                   | S_PROD_INT     |     1 |    16 |     1   (0)| 00:00:01 |
|* 61 |      INDEX UNIQUE SCAN                            | S_PROD_INT_P1 |     1 |       |     1   (0)| 00:00:01 |
| 62 |    TABLE ACCESS BY INDEX ROWID                    | S_ORG_EXT      |     1 |    14 |     2   (0)| 00:00:01 |
|* 63 |     INDEX UNIQUE SCAN                             | S_ORG_EXT_U3   |     1 |       |     1   (0)| 00:00:01 |
| 64 |   TABLE ACCESS BY INDEX ROWID                     | S_ASSET_X      |     1 |    93 |     3   (0)| 00:00:01 |
|* 65 |    INDEX RANGE SCAN                               | S_ASSET_X_U1   |     1 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=TO_NUMBER(:1))
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID"(+))
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID"(+))
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID"(+))
34 - filter("T23"."SERIAL_NUM" LIKE :2)
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID"(+))
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID"(+))
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID"(+))
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID"(+))
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID"(+))
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID"(+))
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID"(+))
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID"(+))
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID"(+))
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID"(+))
56 - access("T23"."ROW_ID"="T15"."ASSET_ID"(+) AND "T23"."BU_ID"="T15"."BU_ID"(+))
57 - access("T15"."BU_ID"="T13"."ROW_ID"(+))
59 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID"(+))
61 - access("T19"."PROD_ID"="T2"."ROW_ID"(+))
63 - access("T15"."BU_ID"="T5"."PAR_ROW_ID"(+))
65 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID"(+))
Best regards,
Nikolay

Similar Messages

Query is taking more time to execute

Hi,
Query is taking more time to execute.
But when i execute same query in other server then it is giving immediate output.
What is the reason of it.
thanks in advance.

'My car doesn't start, please help me to start my car'
Do you think we are clairvoyant?
Or is your salary subtracted for every letter you type here?
Please be aware this is not a chatroom, and we can not see your webcam.
Sybrand Bakker
Senior Oracle DBA

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.

Query on view - IS the querry executed each time view is referred?

I want to know whether query inside a view is executed each time when the view is being referred?
Also which on of below will be faster?
select
     a1.x,
     a1.y,
     b1.z
from
     TableA a1,
     TableB b1
where
     a1.keyName = 'F' || b1.someKey
OR
cretae view myView as
select
     'F' || someKey as anotherKey
from
     TableB
select
     a1.x,
     a1.y,
     b1.z
from
     TableA a1,
     myView b1
where
     a1.keyName = b1.anotherKey

A view is just a stored query, so it has to be executed each time it is referenced in a query.
The two queries should have identical performance. It might be vanishingly faster to parse the first query than the second, but I doubt you would be able to detect the difference.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

FOR UPDATE causing query to take very long to execute.. What can we do ??

SELECT cell_data
FROM csv_workfile
WHERE cell_row = p_r
AND cell_column = p_c
FOR UPDATE;
this is our query. it take very long to execute.
wat can we do to get it working properly.
this is real real urgent .
Ragards

Hi,
first ask yourself if a SELECT FOR UPDATE is really necessary. If so, try to use an FOR UPDATE OF <attribute>. If there are many users accessing and updateing this table try NOWAIT Option. Your process will not be blocked on case of another lock. You will get error ORA-00054 and can do other things while waiting.
Keep in mind that locks will only released after COMMIT.
But remember to ask yourself. Row locking can be very time consuming. If you can avoid it.
Bye,
Holger

Query takes lots of time to execute

I have written a query which is computed from two separate views when i run the query it take 3 mins to execute
how to reduce the time and excecute fast this is the query
SELECT
X."PRO_ID",
X."POBJ_ID",
X."Major",
X."Minor",
X."Normalized",
X."IDR_PRO_ID",
X."IDR_POBJ_ID",
X."IDR"
FROM
PROJECTS PRO,
PROJECT_OBJECTS POBJ,
(SELECT
MN."PRO_ID",
MN."POBJ_ID",
MN."Major",
MN."Minor",
MN."Normalized",
DR."IDR_PRO_ID",
DR."IDR_POBJ_ID",
DR."IDR"
FROM
MAJOR_MINOR_NORMALIZED MN FULL OUTER JOIN IDR DR
ON
MN."PRO_ID" = DR."IDR_PRO_ID" AND
MN."POBJ_ID" = DR."IDR_POBJ_ID" ) X
WHERE
PRO.ID = POBJ.PRO_ID AND
PRO.ID = DECODE(X."PRO_ID",NULL,PRO.ID,X."PRO_ID") AND
PRO.ID = DECODE(X."IDR_PRO_ID",NULL,PRO.ID,X."IDR_PRO_ID") AND
POBJ.ID = DECODE(X."POBJ_ID",NULL,POBJ.ID,X."POBJ_ID") AND
POBJ.ID = DECODE(X."IDR_POBJ_ID",NULL,POBJ.ID,X."IDR_POBJ_ID") AND
PRO.ID = 2673
any suggestion
Thanks
Sudhir
Message was edited by:
Sudhir_N

If Pro.id = 2673, you don´t need the table PRODUCTS. You can simplify the query to
SELECT
X."PRO_ID",
X."POBJ_ID",
X."Major",
X."Minor",
X."Normalized",
X."IDR_PRO_ID",
X."IDR_POBJ_ID",
X."IDR"
FROM
PROJECT_OBJECTS POBJ,
(SELECT
MN."PRO_ID",
MN."POBJ_ID",
MN."Major",
MN."Minor",
MN."Normalized",
DR."IDR_PRO_ID",
DR."IDR_POBJ_ID",
DR."IDR"
FROM
MAJOR_MINOR_NORMALIZED MN FULL OUTER JOIN IDR DR
ON
MN."PRO_ID" = DR."IDR_PRO_ID" AND
MN."POBJ_ID" = DR."IDR_POBJ_ID" ) X
WHERE
2673 = POBJ.PRO_ID AND
2673 = DECODE(X."PRO_ID",NULL,2673,X."PRO_ID") AND
2673 = DECODE(X."IDR_PRO_ID",NULL,2673,X."IDR_PRO_ID") AND
POBJ.ID = DECODE(X."POBJ_ID",NULL,POBJ.ID,X."POBJ_ID") AND
POBJ.ID = DECODE(X."IDR_POBJ_ID",NULL,POBJ.ID,X."IDR_POBJ_ID") Regards,
Miguel

Query is taking long time to execute after migrating to 10g r2

Hi
We recently migrated the database from 9i to 10gr2 ((10.2.0.2.0).. This query was running in acceptable time before the upgrade in 9i.. Now it is taking a long long time to execute this... Can you please let me know what should i do to improve the performance now.. We are running stats everyday..
Thanks for your help,
Shree
======================================================================================
SELECT cr.cash_receipt_id
,cr.pay_from_customer
,cr.receipt_number
,cr.receipt_date
,cr.amount
,cust.account_number
,crh.gl_date
,cr.set_of_books_id
,sum(ra.amount_applied) amount_applied
FROM AR_CASH_RECEIPTS_ALL cr
,AR_RECEIVABLE_APPLICATIONS_ALL ra
,hz_cust_accounts cust
,AR_CASH_RECEIPT_HISTORY_ALL crh
,GL_PERIOD_STATUSES gps
,FND_APPLICATION app
WHERE cr.cash_receipt_id = ra.cash_receipt_id
AND ra.status = 'UNAPP'
AND cr.status <> 'REV'
AND cust.cust_account_id = cr.pay_from_customer
AND substr(cust.account_number,1,2) <> 'SI' -- Don't allocate Unapplied receipts FOR SI customers
AND crh.cash_receipt_id = cr.cash_receipt_id
AND app.application_id = gps.application_id
AND app.application_short_name = 'AR'
AND gps.period_name = 'May-07'
AND crh.gl_date <= gps.end_date
AND cr.receipt_number not like 'WH%'
-- AND cust.customer_number = '0000079260001'
GROUP BY cr.cash_receipt_id
,cr.pay_from_customer
,cr.receipt_number
,cr.receipt_date
,cr.amount
,cust.account_number
,crh.gl_date
,cr.set_of_books_id
HAVING sum(ra.amount_applied) > 0;
=========================================================================================
Here is the explain plan in 10g r2 (10.2.0.2.0)
PLAN_TABLE_OUTPUT
Plan hash value: 2617075047
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 92340 | 10M| | 513K (1)|
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 92340 | 10M| 35M| 513K (1)|
| 3 | TABLE ACCESS BY INDEX ROWID | AR_RECEIVABLE_APPLICATIONS_ALL | 2 | 34 |
| 4 | NESTED LOOPS | | 184K| 21M| | 510K (1)|
|* 5 | HASH JOIN | | 99281 | 9M| 3296K| 176K (1)|
|* 6 | TABLE ACCESS FULL | HZ_CUST_ACCOUNTS | 112K| 1976K| | 22563 (1)|
|* 7 | HASH JOIN | | 412K| 33M| 25M| 151K (1)|
| 8 | TABLE ACCESS BY INDEX ROWID | AR_CASH_RECEIPT_HISTORY_ALL | 332K| 4546K|
| 9 | NESTED LOOPS | | 498K| 19M| | 26891 (1)|
| 10 | NESTED LOOPS | | 2 | 54 | | 4 (0)|
| 11 | TABLE ACCESS BY INDEX ROWID| FND_APPLICATION | 1 | 8 | | 1 (0)|
|* 12 | INDEX UNIQUE SCAN | FND_APPLICATION_U3 | 1 | | | 0 (0)|
| 13 | TABLE ACCESS BY INDEX ROWID| GL_PERIOD_STATUSES | 2 | 38 | | 3 (0)
|* 14 | INDEX RANGE SCAN | GL_PERIOD_STATUSES_U1 | 1 | | | 2 (0)|
|* 15 | INDEX RANGE SCAN | AR_CASH_RECEIPT_HISTORY_N2 | 332K| | | 1011 (1)
PLAN_TABLE_OUTPUT
|* 16 | TABLE ACCESS FULL | AR_CASH_RECEIPTS_ALL | 5492K| 235M| | 108K
|* 17 | INDEX RANGE SCAN | AR_RECEIVABLE_APPLICATIONS_N1 | 4 | | | 2
Predicate Information (identified by operation id):
1 - filter(SUM("RA"."AMOUNT_APPLIED")>0)
5 - access("CUST"."CUST_ACCOUNT_ID"="CR"."PAY_FROM_CUSTOMER")
6 - filter(SUBSTR("CUST"."ACCOUNT_NUMBER",1,2)<>'SI')
7 - access("CRH"."CASH_RECEIPT_ID"="CR"."CASH_RECEIPT_ID")
12 - access("APP"."APPLICATION_SHORT_NAME"='AR')
14 - access("APP"."APPLICATION_ID"="GPS"."APPLICATION_ID" AND "GPS"."PERIOD_NAME"='May-07')
filter("GPS"."PERIOD_NAME"='May-07')
15 - access("CRH"."GL_DATE"<="GPS"."END_DATE")
16 - filter("CR"."STATUS"<>'REV' AND "CR"."RECEIPT_NUMBER" NOT LIKE 'WH%')
17 - access("CR"."CASH_RECEIPT_ID"="RA"."CASH_RECEIPT_ID" AND "RA"."STATUS"='UNAPP')
filter("RA"."CASH_RECEIPT_ID" IS NOT NULL)
Here is the explain plan in 9i
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=445977 Card=78530 By
tes=9423600)
1 0 FILTER
2 1 SORT (GROUP BY) (Cost=445977 Card=78530 Bytes=9423600)
3 2 HASH JOIN (Cost=443717 Card=157060 Bytes=18847200)
4 3 HASH JOIN (Cost=99563 Card=94747 Bytes=9758941)
5 4 TABLE ACCESS (FULL) OF 'HZ_CUST_ACCOUNTS' (Cost=12
286 Card=110061 Bytes=1981098)
6 4 HASH JOIN (Cost=86232 Card=674761 Bytes=57354685)
7 6 TABLE ACCESS (BY INDEX ROWID) OF 'AR_CASH_RECEIP
T_HISTORY_ALL' (Cost=17532 Card=542304 Bytes=7592256)
8 7 NESTED LOOPS (Cost=17536 Card=809791 Bytes=332
01431)
9 8 NESTED LOOPS (Cost=4 Card=1 Bytes=27)
10 9 TABLE ACCESS (BY INDEX ROWID) OF 'FND_APPL
ICATION' (Cost=1 Card=1 Bytes=8)
11 10 INDEX (UNIQUE SCAN) OF 'FND_APPLICATION_
U3' (UNIQUE)
12 9 TABLE ACCESS (BY INDEX ROWID) OF 'GL_PERIO
D_STATUSES' (Cost=3 Card=1 Bytes=19)
13 12 INDEX (RANGE SCAN) OF 'GL_PERIOD_STATUSE
S_U1' (UNIQUE) (Cost=2 Card=1)
14 8 INDEX (RANGE SCAN) OF 'AR_CASH_RECEIPT_HISTO
RY_N2' (NON-UNIQUE) (Cost=1740 Card=542304)
15 6 TABLE ACCESS (FULL) OF 'AR_CASH_RECEIPTS_ALL' (C
ost=60412 Card=8969141 Bytes=394642204)
16 3 TABLE ACCESS (FULL) OF 'AR_RECEIVABLE_APPLICATIONS_A
LL' (Cost=337109 Card=15613237 Bytes=265425029)

Hi,
The plan between 9i and 10g is pretty the same but the amount of data fetched has considerably increased. I guess the query was performing slow even in 9i.
The AR_CASH_RECEIPT_HISTORY_ALL is presently having 332000 rows in 10g where as it was 17532 in 9i.
AR_CASH_RECEIPT_HISTORY_N2 is now having 332,000 rows in 10g where as in 9i it had 1,740
Try creating some indexes on
AR_CASH_RECEIPTS_ALL
hz_cust_accounts

Query taking lot of time to execute..

Hi,
I have a very complecated query which I am executing using JDBC. The query has an insert statement. This query takes 15 mins to complete. I'm running the query as stand alone java program. Can some one have some suggestions what is the best way to debug. I need to find out why the query is taking that long. I'm using oracle 10g with sql developer.
ps = con.prepareStatement(query);
ps.setString(1,date);
ps.setString(2,code);
timeStart = System.currentTimeMillis();
ps.executeUpdate();
timeEnd = System.currentTimeMillis();
System.out.println("Time Taken::"+(timeStart -timeEnd)+" ms");
Thanks in advance
Ajoo

Perhaps you should post the query so we can see what you are doing.
In the mean time, try writing a simple update query and run it. If it runs quickly, your original query has problems. If it runs slow, its caused by something other than your original query.
P.S.:
should be:
System.out.println("Time Taken::"(timeEnd -timeStart)" ms");
and not this:
System.out.println("Time Taken::"(timeStart -timeEnd)" ms");
Edited by: njbt7y on Jan 19, 2011 12:07 PM

Error while query execution - Query getting locked by another user execute

Hi All,
I am facing an issue ..
When I execute a query I am getting an error message ie popping as blocked by some other user. And I able to see the lock when I go to SM12. If the other user logged off or if we unlock his entry, then both the workbook and query is getting executed as expected. What can be the reason for this phenomena?
In my understanding, in the same time multiple users can execute the query /workbook. But in our case its not allowing.
Can someone suggest a resolution at the earliest, as it is affecting the reports in live environment
Regards
Mathew

The Bex Analyser (Front end) Patch is 501 and the SAP BI is 15.
The error message that I am getting while executing the query is "The object requested is currently locked by user --".
When I go to SM12, I can see a lock in the user's name.

Query is taking more time to execute in PROD

Hi All,
Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
SELECT DISTINCT OOH.HEADER_ID
,OOH.ORG_ID
,ct.CUSTOMER_TRX_ID
,ool.ship_from_org_id
,ct.trx_number IDP_SHIPMENT_ID
,ctt.type STATUS_CODE
,SYSDATE STATUS_DATE
,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
,rac_bill.orig_system_reference
,rac_ship_party.party_name SHIP_TO_NAME
,raa_ship_loc.address1 SHIP_TO_ADDR1
,raa_ship_loc.address2 SHIP_TO_ADDR2
,raa_ship_loc.address3 SHIP_TO_ADDR3
,raa_ship_loc.address4 SHIP_TO_ADDR4
,raa_ship_loc.city SHIP_TO_CITY
,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
,raa_ship_loc.postal_code SHIP_TO_ZIP
,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
,ooh.creation_date CUSTOMER_ORDER_DATE
,ool.actual_shipment_date DATE_SHIPPED
,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
,'CSB', 'CHESAPEAKE'
,'DEP', 'CHESAPEAKE'
,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
,ooh.freight_carrier_code FREIGHT_CARRIER
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
+ NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
,ooh.freight_terms_code FREIGHT_TERMS
,'' IDP_BILL_OF_LADING
,(SELECT WAYBILL
FROM WSH_DELIVERY_DETAILS_OE_V
WHERE -1=-1
AND SOURCE_HEADER_ID = ooh.header_id
AND SOURCE_LINE_ID = ool.line_id
AND ROWNUM =1) WAYBILL_CARRIER
,'' CONTAINERS
,ct.trx_number INVOICE_NBR
,ct.trx_date INVOICE_DATE
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
,NULL IDP_TAX_IDENTIFICATION_NBR
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
,NULL TAX_DESC_1
,NULL TAX_AMOUNT_2
,NULL TAX_DESC_2
,rt.name PAYMENT_TERMS
,NULL RELATED_INVOICE_NBR
,'Y' INVOICE_PRINT_FLAG
FROM ra_customer_trx_all ct
,ra_cust_trx_types_all ctt
,hz_cust_accounts rac_ship
,hz_cust_accounts rac_bill
,hz_parties rac_ship_party
,hz_locations raa_ship_loc
,hz_party_sites raa_ship_ps
,hz_cust_acct_sites_all raa_ship
,hz_cust_site_uses_all su_ship
,ra_customer_trx_lines_all rctl
,oe_order_lines_all ool
,oe_order_headers_all ooh
,mtl_parameters mp
,ra_terms rt
,OE_ORDER_SOURCES oos
,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
AND ctt.TYPE <> 'BR'
AND ct.org_id = ctt.org_id
AND ct.ship_to_customer_id = rac_ship.cust_account_id
AND ct.bill_to_customer_id = rac_bill.cust_account_id
AND rac_ship.party_id = rac_ship_party.party_id
AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
AND raa_ship.party_site_id = raa_ship_ps.party_site_id
AND raa_ship_loc.location_id = raa_ship_ps.location_id
AND ct.ship_to_site_use_id = su_ship.site_use_id
AND su_ship.org_id = ct.org_id
AND raa_ship.org_id = ct.org_id
AND ct.customer_trx_id = rctl.customer_trx_id
AND ct.org_id = rctl.org_id
AND rctl.interface_line_attribute6 = to_char(ool.line_id)
AND rctl.org_id = ool.org_id
AND ool.header_id = ooh.header_id
AND ool.org_id = ooh.org_id
AND mp.organization_id = ool.ship_from_org_id
AND ooh.payment_term_id = rt.term_id
AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
AND ool.flow_status_code = 'CLOSED'
AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
AND trx_hdr_table = 'CT'
AND xla_ael_sl_v.gl_transfer_status = 'Y'
AND xla_ael_sl_v.accounted_dr IS NOT NULL
AND xla_ael_sl_v.org_id = ct.org_id;
-- AND ct.trx_number = '2000080';
}

Hello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM

Splitting and executing the query for each 1 lac and executing parallel.

Hi All,
We have a table with around 10 keys and each key is having more than millions of records for a given date.
And my requirement is to find the sum of the sale_price of each keys.
( example :
Select key, sum(sale_price) from table1 where date1=sysdate
group by key
Since, each set of key contains more than a millions of records, It's time consumption is too high.
Is thr any way to achieve as below,
For key 1 (assume 1 million records)
and we will spilt these into 100 parts and execute parallelly.
At the end get sum of all 100 parts.
Similarly for other keys....
Is it possible to divide the records into 1 lac each and give it for parallel execution ?

If the key column is also the partition key, I would expect that to work well with parallel query. What have you tried that isn't working? Also what is your Oracle version?

Query not fetching results and shows executing

All,
When I run a query from SQL Plus I am getting query results immediately table with more than 50,000 rows), but when I run from TOAD or PL/SQL Developer am not getting any result and all I see is query executing no error message also.
Surprising part is I am able to see results if the table is less than 100 rows in SQL Plus, TOAD and PL/SQL Developer.
Please tell me is there anything I have to do in the database configuration, I am facing this issue due to database move to a new server.
Thanks in advance

Anand,
I don't see this as an issue with TOAD or PL/SQL Developer, the reason is using my TOAD or PL/SQL Developer I am able to connect to the copy of this database (DEV) and able to fetch results. Only in the database I migrated to the new server I am not able to fetch results from connecting through any application, the only place I am able to run and get results is SQL PLUS.
So I believe this is something which I am missing in my database configuration or in my new server.
Please help me
Thanks in Advance

JDO Query does not seem to be executed at all

I have the following JDO query and it returns empty collection but it
should return some records. I set "SQL=TRACE" in kodo.properties file and
traced the log file. This query does not seem to generate SQL statement
at all. Other JDO method generates SQL statements.
Kodo version: 3.1.2
J2SE: 1.4.1_05
Database: MS SQL Server 2000
// Get endorsement rule type
String ruleType = getEndorsementRuleType();
Query qry = pm.newQuery(EndorsementRule.class);
try {
qry.declareParameters("String ruleType");
qry.setFilter("this.ruleType == ruleType");
log.info("*** EXECUTE RULE QUERY ***");
Collection c = (Collection)qry.execute(ruleType);
log.info("*** qrysize=" + c.size());
finally {
qry.closeAll();
Log file: There is not SQL statement generated for the JDO query.
[junit] INFO: Get endorsement rule type
[junit] Jun 7, 2004 12:39:01 PM EndorsementRuleEngine
getEndorsementRuleType
[junit] INFO: *** JDO EXECUTE BEGIN ***
[junit] 16366 TRACE [main] kodo.jdbc.SQL - <t 3969559, conn 18096534> [0
m
s] executing prepstmnt 20731151 SELECT t0.EndtType, t0.EndtId FROM EndtHe
aderItem t0 WHERE t0.EndtId = ? [params=(int) 6137330] [reused=0]
[junit] Jun 7, 2004 12:39:01 PM EndorsementRuleEngine
getEndorsementRuleType
[junit] INFO: *** JDO EXECUTE END ***
[junit] Jun 7, 2004 12:39:02 PM EndorsementRuleEngine getRules
[junit] INFO: *** EXECUTE RULE QUERY ***
+++ WHERE IS SQL statement for JDO Query ? +++
[junit] Jun 7, 2004 12:39:02 PM EndorsementRuleEngine getRules
[junit] INFO: *** qrysize=0
[junit] Jun 7, 2004 12:39:02 PM mytest.EndtRuleTestCase setComplete
Thanks,
Andy

Please ignore this post. The error was caused by the file merge done by
StarTeam.

Query assigned to role. Doesnt execute when try to execute from under role

Hi Experts,
We have some queries assigned to a role in PFCG.
Now the anomaly is as follows:
some of the queries that are assigned, do not show any technical names in the Bex role window. When we click on these queries under this role, nothing happens. no execution, nothing.
The same queries if executed from under the Infoareas->infoprovider->query path, execute correctly.
This would point to incorrect assignments in PFCG, BUT thats not the case.
<bsp_protcl>://<bsp_server>/sap/bw/BEx?sap-language=<language>&bsplanguage=EN&cmd=ldoc&INFOCUBE=Z1&QUERY=ZQ1
<bsp_protcl>://<bsp_server>/sap/bw/BEx?sap-language=<language>&bsplanguage=EN&cmd=ldoc&INFOCUBE=Z2&QUERY=ZQ2
The details of the query assignments to the role are as above.
Query ZQ1 shows in Bex role with a technical name and executes properly.
Query ZQ2 doesn't show a technical name under that role in Bex and doesnt execute.
Also if I execute ZQ2 from the PFCG, it executes correctly.
What are we missing here?
All help appreciated!

The query name is correct. The assignment seems to be correct too.
But for this particular assignment, the bex role doesnt show a technical name for the query. neither does the query execute.
Why don't the assignment via PFCG work?
Edited by: CC on May 22, 2008 6:04 PM

Query takes lots of time to execute how to minizie

Hi ALL,
I have a query like this which takes atleat 3 mins to execute how to optimiized the code from the below query
how to minimize the time
SELECT
PRO.PROJECT_NAME "Project Name",
POBJ.NAME "Object Name",
X."Major" "Internal_Major",
X."Minor" "Internal_Minor",
X."Normalized" "Internal_Normalized",
TRUNC(X."IDR",2) "Internal Defect Rate",
Y."Major" "External_Major",
Y."Minor" "External_Minor",
Y."Normalized" "External_Normalized",
TRUNC(Y."EDR",2) "External_Defect_Rate",
PRO.ID "PRO_ID",
POBJ.ID "POBJ_ID"
FROM
PROJECTS PRO, PROJECT_OBJECTS POBJ,
(SELECT
MN."PRO_ID",
MN."POBJ_ID",
MN."Major",
MN."Minor",
MN."Normalized",
DR."IDR_PRO_ID",
DR."IDR_POBJ_ID",
DR."IDR"
FROM IDR_TEST DR FULL OUTER JOIN MAJOR_MINOR_NORMALIZED MN
ON
MN."PRO_ID" = DR."IDR_PRO_ID" AND
MN."POBJ_ID" = DR."IDR_POBJ_ID") X,
(SELECT
EE."PRO_ID" E_PRO_ID,
EN."PRO_ID" EN_PRO_ID,
EE."POBJ_ID" E_POBJ_ID,
EN."POBJ_ID" EN_POBJ_ID,
EN."Major",
EN."Minor",
EN."Normalized",
EN."Normalized" / DECODE(EE."External_Effort",0,NULL,EE."External_Effort") "EDR"
FROM
EXTR_MAJOR_MINOR_NORMALIZED EN FULL OUTER JOIN EXTERNAL_EFFORT EE
ON
EE."PRO_ID" = EN."PRO_ID" AND
EE."POBJ_ID" = EN."POBJ_ID") Y
WHERE
PRO.ID = :P1_PROJECTS AND
PRO.ID = POBJ.PRO_ID AND
:P1_PROJECTS = DECODE(X.PRO_ID,NULL,:P1_PROJECTS,X.PRO_ID) AND
:P1_PROJECTS = DECODE(X.IDR_PRO_ID,NULL,:P1_PROJECTS,X.IDR_PRO_ID) AND
POBJ.ID = DECODE(X.POBJ_ID,NULL,POBJ.ID,X.POBJ_ID) AND
POBJ.ID = DECODE(X.IDR_POBJ_ID,NULL,POBJ.ID,X.IDR_POBJ_ID)
AND
:P1_PROJECTS = DECODE(Y.E_PRO_ID(+),NULL,:P1_PROJECTS,Y.E_PRO_ID(+)) AND
:P1_PROJECTS = DECODE(Y.EN_PRO_ID(+),NULL,:P1_PROJECTS,Y.EN_PRO_ID(+)) AND
POBJ.ID = DECODE(Y.E_POBJ_ID(+),NULL,POBJ.ID,Y.E_POBJ_ID(+)) AND
POBJ.ID = DECODE(Y.EN_POBJ_ID(+),NULL,POBJ.ID,Y.EN_POBJ_ID(+))
Problem is with the two full outer joins wht i am using
there only i find the query taking too much time
Thanks
Sudhir
Message was edited by:
Sudhir_N
Message was edited by:
Sudhir_N

You'll have to get an exection plan and manually tune the query.
That aside, inline views can really slow queries down because once the data is stored in a temporary table you can't do fast indexed lookups on their result sets. They also make queries be more complicated. Also, outer joins tend to slow queries down a lot in general.

Query taling 01:40:38 to execute

Similar Messages

Maybe you are looking for