Index creation on a field in DSO for performance improvement of a select st

Hi All,
We have one DSO in Production which has around 48 million records.
In a transformation of a cube, we have a select statement on the DSO with comparing 5 fields. And 4 of them are data fields in the DSO.before some time we change a structure of the DSO. We moved one info object from key field to data field which is being used in the select query.
After this change, we do a full load to the DSO and then everything is running fine. Except the load to cube is getting stuck at the select statement. It is running for ever.
Now I have the below doubts,
1. Can this happen as one of the field which we are using in the select statement does not have indexes?
2. If we want to create index on that field, then what would be the required steps?
Thank you,
Jaimin

Hi Jaimin,
Sorry ,i misunderstood the question.Request you to please explain the issue step by step once again.
Rgds
SVU123
Edited by: svu123 on Feb 25, 2011 11:52 AM
Edited by: svu123 on Feb 25, 2011 1:30 PM

Similar Messages

Pls help me to modify the query for performance improvement

Hi,
I have the below initialization
DECLARE @Active bit =1 ;
Declare @id int
SELECT @Active=CASE WHEN id=@id and [Rank] ='Good' then 0 else 1 END FROM dbo.Students
I have to change this query in such a way that the conditions id=@id and [Rank] ='Good' should go to the where condition of the query. In that case, how can i use Case statement to retrieve 1 or 0? Can you please help me to modify this initialization?

I dont understand your query...May be below? or provide us sample data and your output...
SELECT * FROM dbo.students
where @Active=CASE
WHEN id=@id and rank ='Good' then 0 else 1 END
But, I doubt you will have performance improvement here?
Do you have index on id?
If you are looking for getting the data for @ID with rank ='Good' then use the below:Make sure, you have index on id,rank combination.
SELECT * FROM dbo.students
where id=@id
and rank ='Good'

Index not getting used in the query(Query performance improvement)

Hi,
I am using oracle 10g version and have this query:
select distinct bk.name             "Book Name",
                fs.feed_description "Feed Name",
                fbs.cob_date        "Cob",
                at.description      "Data Type",
                ah.user_name        " User",
                ah.comments         "Comments",
                ah.time_draft
from Action_type       at,
       action_history    ah,
       sensitivity_audit sa,
       logical_entity    le,
       feed_static       fs,
       feed_book_status fbs,
       feed_instance     fi,
       marsnode          bk
where at.description = 'Regress Positions'
   and fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
   and fi.most_recent = 'Y'
   and bk.close_date is null
   and ah.time_draft = 'after'
   and sa.close_action_id is null
   and le.close_action_id is null
   and at.action_type_id = ah.action_type_id
   and ah.action_id = sa.create_action_id
   and le.logical_entity_id = sa.type_id
   and sa.feed_id = fs.feed_id
   and sa.book_id = bk.node_id
   and sa.feed_instance_id = fi.feed_instance_id
   and fbs.feed_instance_id = fi.feed_instance_id
   and fi.feed_id = fs.feed_id
union
select distinct bk.name             "Book Name",
                fs.feed_description "Feed Name",
                fbs.cob_date        "Cob",
                at.description      "Data Type",
                ah.user_name        " User",
                ah.comments         "Comments",
                ah.time_draft
from feed_book_status         fbs,
       marsnode                 bk,
       feed_instance            fi,
       feed_static              fs,
       feed_book_status_history fbsh,
       Action_type              at,
       Action_history           ah
where fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
   and ah.action_type_id = 103
   and bk.close_date is null
   and ah.time_draft = 'after'
--   and ah.action_id = fbs.action_id
   and fbs.book_id = bk.node_id
   and fbs.book_id = fbsh.book_id
   and fbs.feed_instance_id = fi.feed_instance_id
   and fi.feed_id = fs.feed_id
   and fbsh.create_action_id = ah.action_id
   and at.action_type_id = ah.action_type_id
union
select distinct bk.name             "Book Name",
                fs.feed_description "Feed Name",
                fbs.cob_date        "Cob",
                at.description      "Data Type",
                ah.user_name        " User",
                ah.comments         "Comments",
                ah.time_draft
from feed_book_status         fbs,
       marsnode                 bk,
       feed_instance            fi,
       feed_static              fs,
       feed_book_status_history fbsh,
       Action_type              at,
       Action_history           ah
where fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
   and ah.action_type_id = 101
   and bk.close_date is null
   and ah.time_draft = 'after'
   and fbs.book_id = bk.node_id
   and fbs.book_id = fbsh.book_id
   and fbs.feed_instance_id = fi.feed_instance_id
   and fi.feed_id = fs.feed_id
   and fbsh.create_action_id = ah.action_id
   and at.action_type_id = ah.action_type_id;This is the execution plan
| Id | Operation                            | Name                     | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                     |                          |   231 | 43267 |   104K (85)|
|   1 | SORT UNIQUE                         |                          |   231 | 43267 |   104K (85)|
|   2 |   UNION-ALL                          |                          |       |       |            |
|   3 |    NESTED LOOPS                      |                          |     1 |   257 | 19540 (17)|
|   4 |     NESTED LOOPS                     |                          |     1 |   230 | 19539 (17)|
|   5 |      NESTED LOOPS                    |                          |     1 |   193 | 19537 (17)|
|   6 |       NESTED LOOPS                   |                          |     1 |   152 | 19534 (17)|
|* 7 |        HASH JOIN                     |                          |   213 | 26625 | 19530 (17)|
|* 8 |         TABLE ACCESS FULL            | LOGICAL_ENTITY           |    12 |   264 |     2   (0)|
|* 9 |         HASH JOIN                    |                          | 4267 |   429K| 19527 (17)|
|* 10 |          HASH JOIN                   |                          | 3602 | 90050 | 1268 (28)|
|* 11 |           INDEX RANGE SCAN           | IDX_FBS_CD_FII_BI        | 3602 | 46826 |    22   (5)|
|* 12 |           TABLE ACCESS FULL          | FEED_INSTANCE            |   335K| 3927K| 1217 (27)|
|* 13 |          TABLE ACCESS FULL           | SENSITIVITY_AUDIT        |   263K|    19M| 18236 (17)|
| 14 |        TABLE ACCESS BY INDEX ROWID   | FEED_STATIC              |     1 |    27 |     1   (0)|
|* 15 |         INDEX UNIQUE SCAN            | IDX_FEED_STATIC_FI       |     1 |       |     0   (0)|
|* 16 |       TABLE ACCESS BY INDEX ROWID    | MARSNODE                 |     1 |    41 |     3   (0)|
|* 17 |        INDEX RANGE SCAN              | PK_MARSNODE              |     3 |       |     2   (0)|
|* 18 |      TABLE ACCESS BY INDEX ROWID     | ACTION_HISTORY           |     1 |    37 |     2   (0)|
|* 19 |       INDEX UNIQUE SCAN              | PK_ACTION_HISTORY        |     1 |       |     1   (0)|
|* 20 |     TABLE ACCESS BY INDEX ROWID      | ACTION_TYPE              |     1 |    27 |     1   (0)|
|* 21 |      INDEX UNIQUE SCAN               | PK_ACTION_TYPE           |     1 |       |     0   (0)|
|* 22 |    TABLE ACCESS BY INDEX ROWID       | MARSNODE                 |     1 |    41 |     3   (0)|
| 23 |     NESTED LOOPS                     |                          |   115 | 21505 | 42367 (28)|
|* 24 |      HASH JOIN                       |                          |   114 | 16644 | 42023 (28)|
| 25 |       NESTED LOOPS                   |                          |   114 | 13566 | 42007 (28)|
|* 26 |        HASH JOIN                     |                          |   114 | 12426 | 41777 (28)|
|* 27 |         HASH JOIN                    |                          |   957 | 83259 | 41754 (28)|
|* 28 |          TABLE ACCESS FULL           | ACTION_HISTORY           | 2480 | 91760 | 30731 (28)|
| 29 |          NESTED LOOPS                |                          | 9570K|   456M| 10234 (21)|
| 30 |           TABLE ACCESS BY INDEX ROWID| ACTION_TYPE              |     1 |    27 |     1   (0)|
|* 31 |            INDEX UNIQUE SCAN         | PK_ACTION_TYPE           |     1 |       |     0   (0)|
| 32 |           TABLE ACCESS FULL          | FEED_BOOK_STATUS_HISTORY | 9570K|   209M| 10233 (21)|
|* 33 |         INDEX RANGE SCAN             | IDX_FBS_CD_FII_BI        | 3602 | 79244 |    22   (5)|
| 34 |        TABLE ACCESS BY INDEX ROWID   | FEED_INSTANCE            |     1 |    10 |     2   (0)|
|* 35 |         INDEX UNIQUE SCAN            | PK_FEED_INSTANCE         |     1 |       |     1   (0)|
| 36 |       TABLE ACCESS FULL              | FEED_STATIC              | 2899 | 78273 |    16   (7)|
|* 37 |      INDEX RANGE SCAN                | PK_MARSNODE              |     1 |       |     2   (0)|
|* 38 |    TABLE ACCESS BY INDEX ROWID       | MARSNODE                 |     1 |    41 |     3   (0)|
| 39 |     NESTED LOOPS                     |                          |   115 | 21505 | 42367 (28)|
|* 40 |      HASH JOIN                       |                          |   114 | 16644 | 42023 (28)|
| 41 |       NESTED LOOPS                   |                          |   114 | 13566 | 42007 (28)|
|* 42 |        HASH JOIN                     |                          |   114 | 12426 | 41777 (28)|
|* 43 |         HASH JOIN                    |                          |   957 | 83259 | 41754 (28)|
|* 44 |          TABLE ACCESS FULL           | ACTION_HISTORY           | 2480 | 91760 | 30731 (28)|
| 45 |          NESTED LOOPS                |                          | 9570K|   456M| 10234 (21)|
| 46 |           TABLE ACCESS BY INDEX ROWID| ACTION_TYPE              |     1 |    27 |     1   (0)|
|* 47 |            INDEX UNIQUE SCAN         | PK_ACTION_TYPE           |     1 |       |     0   (0)|
| 48 |           TABLE ACCESS FULL          | FEED_BOOK_STATUS_HISTORY | 9570K|   209M| 10233 (21)|
|* 49 |         INDEX RANGE SCAN             | IDX_FBS_CD_FII_BI        | 3602 | 79244 |    22   (5)|
| 50 |        TABLE ACCESS BY INDEX ROWID   | FEED_INSTANCE            |     1 |    10 |     2   (0)|
|* 51 |         INDEX UNIQUE SCAN            | PK_FEED_INSTANCE         |     1 |       |     1   (0)|
| 52 |       TABLE ACCESS FULL              | FEED_STATIC              | 2899 | 78273 |    16   (7)|
|* 53 |      INDEX RANGE SCAN                | PK_MARSNODE              |     1 |       |     2   (0)|
------------------------------------------------------------------------------------------------------and the predicate info
Predicate Information (identified by operation id):
   7 - access("LE"."LOGICAL_ENTITY_ID"="SA"."TYPE_ID")
   8 - filter("LE"."CLOSE_ACTION_ID" IS NULL)
   9 - access("SA"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
10 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
11 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
12 - filter("FI"."MOST_RECENT"='Y')
13 - filter("SA"."CLOSE_ACTION_ID" IS NULL)
15 - access("FI"."FEED_ID"="FS"."FEED_ID")
       filter("SA"."FEED_ID"="FS"."FEED_ID")
16 - filter("BK"."CLOSE_DATE" IS NULL)
17 - access("SA"."BOOK_ID"="BK"."NODE_ID")
18 - filter("AH"."TIME_DRAFT"='after')
19 - access("AH"."ACTION_ID"="SA"."CREATE_ACTION_ID")
20 - filter("AT"."DESCRIPTION"='Regress Positions')
21 - access("AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
22 - filter("BK"."CLOSE_DATE" IS NULL)
24 - access("FI"."FEED_ID"="FS"."FEED_ID")
26 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
27 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
              "AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
28 - filter("AH"."ACTION_TYPE_ID"=103 AND "AH"."TIME_DRAFT"='after')
31 - access("AT"."ACTION_TYPE_ID"=103)
33 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
35 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
37 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
38 - filter("BK"."CLOSE_DATE" IS NULL)
40 - access("FI"."FEED_ID"="FS"."FEED_ID")
42 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
43 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
              "AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
44 - filter("AH"."ACTION_TYPE_ID"=101 AND "AH"."TIME_DRAFT"='after')
47 - access("AT"."ACTION_TYPE_ID"=101)
49 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
51 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
53 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
Note
   - 'PLAN_TABLE' is old versionIn this query, mainly the ACTION_HISTORY and FEED_BOOK_STATUS_HISTORY tables are getting accessed fullly though there are indexes createdon them like this
ACTION_HISTORY
ACTION_ID column Unique index
FEED_BOOK_STATUS_HISTORY
(FEED_INSTANCE_ID, BOOK_ID, COB_DATE, VERSION) composite indexI tried all the best combinations however the indexes are not getting used anywhere.
Could you please suggest some way so the query will perform better way.
Thanks,
Aashish

Hi Mohammed,
This is what I got after your method of execution plan
SQL_ID 4vmc8rzgaqgka, child number 0
select distinct bk.name "Book Name" ,       fs.feed_description "Feed Name" ,       fbs.cob_date
"Cob" ,       at.description "Data Type" ,       ah.user_name " User" ,       ah.comments "Comments"
,       ah.time_draft from Action_type at, action_history ah, sensitivity_audit sa, logical_entity
le, feed_static fs, feed_book_status fbs, feed_instance fi, marsnode bk where at.description =
'Regress Positions' and    fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011' and
fi.most_recent = 'Y' and    bk.close_date is null and    ah.time_draft='after' and
sa.close_action_id is null and    le.close_action_id is null and    at.action_type_id =
ah.action_type_id and    ah.action_id=sa.create_action_id and    le.logical_entity_id = sa.type_id
and    sa.feed_id = fs.feed_id and    sa.book_id = bk.node_id and    sa.feed_instance_id =
fi.feed_instance_id and    fbs.feed_instance_id = fi.feed_instance_id and    fi.feed_id = fs.feed_id
union select distinct bk.name "Book Name" ,       fs.
Plan hash value: 1006571916
| Id | Operation                            | Name                     | E-Rows | OMem | 1Mem | Used-Mem |
|   1 | SORT UNIQUE                         |                          |    231 | 6144 | 6144 | 6144 (0)|
|   2 |   UNION-ALL                          |                          |        |       |       |          |
|   3 |    NESTED LOOPS                      |                          |      1 |       |       |          |
|   4 |     NESTED LOOPS                     |                          |      1 |       |       |          |
|   5 |      NESTED LOOPS                    |                          |      1 |       |       |          |
|   6 |       NESTED LOOPS                   |                          |      1 |       |       |          |
|* 7 |        HASH JOIN                     |                          |    213 | 1236K| 1236K| 1201K (0)|
|* 8 |         TABLE ACCESS FULL            | LOGICAL_ENTITY           |     12 |       |       |          |
|* 9 |         HASH JOIN                    |                          |   4267 | 1023K| 1023K| 1274K (0)|
|* 10 |          HASH JOIN                   |                          |   3602 | 1095K| 1095K| 1296K (0)|
|* 11 |           INDEX RANGE SCAN           | IDX_FBS_CD_FII_BI        |   3602 |       |       |          |
|* 12 |           TABLE ACCESS FULL          | FEED_INSTANCE            |    335K|       |       |          |
|* 13 |          TABLE ACCESS FULL           | SENSITIVITY_AUDIT        |    263K|       |       |          |
| 14 |        TABLE ACCESS BY INDEX ROWID   | FEED_STATIC              |      1 |       |       |          |
|* 15 |         INDEX UNIQUE SCAN            | IDX_FEED_STATIC_FI       |      1 |       |       |          |
|* 16 |       TABLE ACCESS BY INDEX ROWID    | MARSNODE                 |      1 |       |       |          |
|* 17 |        INDEX RANGE SCAN              | PK_MARSNODE              |      3 |       |       |          |
|* 18 |      TABLE ACCESS BY INDEX ROWID     | ACTION_HISTORY           |      1 |       |       |          |
|* 19 |       INDEX UNIQUE SCAN              | PK_ACTION_HISTORY        |      1 |       |       |          |
|* 20 |     TABLE ACCESS BY INDEX ROWID      | ACTION_TYPE              |      1 |       |       |          |
|* 21 |      INDEX UNIQUE SCAN               | PK_ACTION_TYPE           |      1 |       |       |          |
|* 22 |    TABLE ACCESS BY INDEX ROWID       | MARSNODE                 |      1 |       |       |          |
| 23 |     NESTED LOOPS                     |                          |    115 |       |       |          |
|* 24 |      HASH JOIN                       |                          |    114 |   809K|   809K| 817K (0)|
| 25 |       NESTED LOOPS                   |                          |    114 |       |       |          |
|* 26 |        HASH JOIN                     |                          |    114 |   868K|   868K| 1234K (0)|
|* 27 |         HASH JOIN                    |                          |    957 |   933K|   933K| 1232K (0)|
|* 28 |          TABLE ACCESS FULL           | ACTION_HISTORY           |   2480 |       |       |          |
| 29 |          NESTED LOOPS                |                          |   9570K|       |       |          |
| 30 |           TABLE ACCESS BY INDEX ROWID| ACTION_TYPE              |      1 |       |       |          |
|* 31 |            INDEX UNIQUE SCAN         | PK_ACTION_TYPE           |      1 |       |       |          |
| 32 |           TABLE ACCESS FULL          | FEED_BOOK_STATUS_HISTORY |   9570K|       |       |          |
|* 33 |         INDEX RANGE SCAN             | IDX_FBS_CD_FII_BI        |   3602 |       |       |          |
| 34 |        TABLE ACCESS BY INDEX ROWID   | FEED_INSTANCE            |      1 |       |       |          |
|* 35 |         INDEX UNIQUE SCAN            | PK_FEED_INSTANCE         |      1 |       |       |          |
| 36 |       TABLE ACCESS FULL              | FEED_STATIC              |   2899 |       |       |          |
|* 37 |      INDEX RANGE SCAN                | PK_MARSNODE              |      1 |       |       |          |
|* 38 |    TABLE ACCESS BY INDEX ROWID       | MARSNODE                 |      1 |       |       |          |
| 39 |     NESTED LOOPS                     |                          |    115 |       |       |          |
|* 40 |      HASH JOIN                       |                          |    114 |   743K|   743K| 149K (0)|
| 41 |       NESTED LOOPS                   |                          |    114 |       |       |          |
|* 42 |        HASH JOIN                     |                          |    114 |   766K|   766K| 208K (0)|
|* 43 |         HASH JOIN                    |                          |    957 |   842K|   842K| 204K (0)|
|* 44 |          TABLE ACCESS FULL           | ACTION_HISTORY           |   2480 |       |       |          |
| 45 |          NESTED LOOPS                |                          |   9570K|       |       |          |
| 46 |           TABLE ACCESS BY INDEX ROWID| ACTION_TYPE              |      1 |       |       |          |
|* 47 |            INDEX UNIQUE SCAN         | PK_ACTION_TYPE           |      1 |       |       |          |
| 48 |           TABLE ACCESS FULL          | FEED_BOOK_STATUS_HISTORY |   9570K|       |       |          |
|* 49 |         INDEX RANGE SCAN             | IDX_FBS_CD_FII_BI        |   3602 |       |       |          |
| 50 |        TABLE ACCESS BY INDEX ROWID   | FEED_INSTANCE            |      1 |       |       |          |
|* 51 |         INDEX UNIQUE SCAN            | PK_FEED_INSTANCE         |      1 |       |       |          |
| 52 |       TABLE ACCESS FULL              | FEED_STATIC              |   2899 |       |       |          |
|* 53 |      INDEX RANGE SCAN                | PK_MARSNODE              |      1 |       |       |          |
Predicate Information (identified by operation id):
   7 - access("LE"."LOGICAL_ENTITY_ID"="SA"."TYPE_ID")
   8 - filter("LE"."CLOSE_ACTION_ID" IS NULL)
   9 - access("SA"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
10 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
11 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
12 - filter("FI"."MOST_RECENT"='Y')
13 - filter("SA"."CLOSE_ACTION_ID" IS NULL)
15 - access("FI"."FEED_ID"="FS"."FEED_ID")
       filter("SA"."FEED_ID"="FS"."FEED_ID")
16 - filter("BK"."CLOSE_DATE" IS NULL)
17 - access("SA"."BOOK_ID"="BK"."NODE_ID")
18 - filter("AH"."TIME_DRAFT"='after')
19 - access("AH"."ACTION_ID"="SA"."CREATE_ACTION_ID")
20 - filter("AT"."DESCRIPTION"='Regress Positions')
21 - access("AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
22 - filter("BK"."CLOSE_DATE" IS NULL)
24 - access("FI"."FEED_ID"="FS"."FEED_ID")
26 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
27 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
              "AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
28 - filter(("AH"."ACTION_TYPE_ID"=103 AND "AH"."TIME_DRAFT"='after'))
31 - access("AT"."ACTION_TYPE_ID"=103)
33 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
35 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
37 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
38 - filter("BK"."CLOSE_DATE" IS NULL)
40 - access("FI"."FEED_ID"="FS"."FEED_ID")
42 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
43 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
              "AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
44 - filter(("AH"."ACTION_TYPE_ID"=101 AND "AH"."TIME_DRAFT"='after'))
47 - access("AT"."ACTION_TYPE_ID"=101)
49 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
51 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
53 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
Note
   - Warning: basic plan statistics not available. These are only collected when:
       * hint 'gather_plan_statistics' is used for the statement or
       * parameter 'statistics_level' is set to 'ALL', at session or system level
122 rows selected.
Elapsed: 00:00:02.18The action_type_id column is of NUMBER type.

How application module helps for performance improve

Hi Everyone,
I have a sample web-application in which I am connecting with single AM instance (AM for database view object), retrieving some information and then close the connection. I am doing this as,
// making AM instance
<application module instance> = Configuration.createRootApplicationModule(<AM name>, config);
// performing operations
<operation result> = <application module instance>.<access VO with any operation>();
System.out.println("Get result here");
// disconnecting AM instance
<application module instance>.getDBTransaction().disconnect();
Configuration.releaseRootApplicationModule(<application module instance>, true);
These are the activities which are performed by a single user. Now, I am doing stress test on same activities. I am testing the same code with 300 concurrent users (using JMeter with JSP URL). These are working fine. Also I checked multiple times, it always working fine.
Now, I need to do something through which I can improve the performance. I know, I can use AM pool configurations to make this more effective. I have gone through the Oracle documents and checked the same test case with default or recommended pool configurations and I found similar kind of results (there is not much difference).
On other hand, I tried with 'releaseRootApplicationModule' method with false parameter and found better results in default as well as recommended pool configurations.
My question is, is the change of pool configurations recommended by Oracle really work? or do I need to concentrate more on coding part with default pool configurations?
Here, I would like to know, what are the best practice (in code as well as pool configurations), I need to follow if I really want to improve the performance in real scenarios (when our application will access with large no. of concurrent users).
I really look forward some help from experts. I have given a lot of time on this to know how really we can make our application more effective in terms of performance.
I really appreciate for your reply.
Regards,
Dilip Gupta.

>
We added the createRootApplicationModule() API (in the oracle.jbo.client.Configuration class) to simplify acquiring an application module from the pool for brief programmatic manipulation before it is released back to the AM pool.
Steve Muench.
>
check [url http://radio-weblogs.com/0118231/2009/08/20.html#a959]Check Your App for Misuse of Configuration.createRootApplicationModule()
Edited by: Mohammad Jabr on May 10, 2012 7:14 AM

Caching XQuery Result in OSB for Performance Improvement

Hi,
I have written a custom XPath function in Java to pick the IP address of the machine and registered the same with Oracle Service Bus 11g.
In the Proxy Message Flow, the server IP is picked at run time by using XQuery that refers to the Custom Function.
Now, is there a way to cache this result some where in OSB so that in the subsequent execution, the XQuery will pick the cached value from Cache instead of making a call to Custom Function registered with OSB.
I'm asking this question to understand if performance optimization is possible here by caching the result.
Thanks,
CC

Hi All,
Have implemented Java Callout and Custom XPath in the same flow and kept current datetime stamp before and after each of these steps to calculate the difference b/w timestamps thereby finding the execution times of Java Callout and Custom XPath steps (this may not be an elegant way of calculating the execution time of each step in OSB message flow, request someone to suggest the most recommended approach here!) ...
For a load of 10 users, each submitting 10 requests (total 100 requests), following are the execution times (in milliseconds) collected for 10 requests (Server is not occupied with any other activity at this time):
Java Callout(milliseconds) |     Custom XPath(milliseconds)
13 |     1
4 |     0
5 |     1
1 |     2
0 |     1
1 |      0
1 |     0
1 |     0
1 |     0
1 |     2
Where the value of '0' is appearing, I assume it could be some micro seconds. The difference happens to be zero in some cases as we don't have microsecond level logging.
Thanks,
CC
Edited by: Chandu on 19-Jul-2011 22:02

Help needed in index creation and its impact on insertion of records

Hi All,
I have a situation like this, and the process involves 4 tables.
Among the 4 tables, 2 tables have around 30 columns each, and the other 2 has 15 columns each.
This process contains validation and insert procedure.
I have already created some 8 index for one table, and an average of around 3 index on other tables.
Now the situation is like, i have a select statement in validation procedure, which involves select statement based on all the 4 tables.
When i try to run that select statement, it takes around 30 secs, and when checked for plan, it takes around 21k memory.
Now, i am in a situation to create new index for all the table for the purpose of this select statement.
The no.of times this select statement executes, is like, for around 1000 times of insert into table, 200 times this select statement gets executed, and the record count of these tables would be around one crore.
Will the no.of index created in a table impacts insert statement performace, or can we create as many index as we want in a table ? Which is the best practise ?
Please guide me in this !!!
Regards,
Shivakumar A

Hi,
index creation will most definitely impact your DML performance because when inserting into the table you'll have to update index entries as well. Typically it's a small overhead that is acceptable in most situations, but the only way to say definitively whether or not it is acceptable to you is by testing. Set up some tests, measure performance of some typical selects, updates and inserts with and without an index, and you will have some data to base your decision on.
Best regards,
Nikolay

Why index creation is slower on the new server?

Hi there,
Here is a bit of background/env info:
Existing prod server (physical): Oracle 10gR2 10.2.0.5.8 on ASM
RAM: 96GB
CPUs: 8
RHEL 5.8 64bit
Database size around 2TB
New server:
VMWare VM with Oracle 10gR2 10.2.0.5.8 on ASM
RAM 128GB
vCPUs: 16
RHEL 5.8 64bit
Copy of prod DB (from above server) - all init param are the same
I noticed that Index creation is slower on this server. I ran following query:
SELECT name c1, cnt c2, DECODE (total, 0, 0, ROUND (cnt * 100 / total)) c3
FROM (SELECT name, VALUE cnt, (SUM (VALUE) OVER ()) total
FROM v$sysstat
WHERE name LIKE 'workarea exec%')
C1
C2
C3
workarea executions - optimal
100427285
100
workarea executions - onepass
2427
0
workarea executions - multipass
0
0
Following bitmap index takes around 40mins in prod server while it takes around 2Hrs on the VM.
CREATE BITMAP INDEX MY_IDX ON
MY_HIST(PROD_YN) TABLESPACE TS_IDX PCTFREE 10
STORAGE(INITIAL 12582912 NEXT 12582912 PCTINCREASE 0 ) NOLOGGING
This index is created during a batch-process and the dev team is complaining of slowness of the batch on new server. I have found this one statement responsible for some of the grief. There may be more and I am investigating.
I know that adding "parallel" option may speedup but I want find out why is it slow on the new server.
I tried creating a simple index on a large table and it took 2min in prod and 3.5min on this VM. So I guess index creation is slower on this VM in general. DMLs (select/insert/delete/update) seem to work with better elapsed time.
Any clues what might be causing this slowness in index creation?
Best regards

I have been told that the SAN in use by the VM has capacity of 10K IOPS. Not sure of this info helps. I don't know more than this about the storage.
What else do I need to find out? Please let me know - I'll check with my Sys Admin and update the thread.
Best regards

Partitioning for Performance

Hi All,
Currently we have a STAR Schema with ORDER_FACT and ORDER_HEADER_DIM , ORDER_LINE_DIM, STORE_DIM, TIME_DIM and PRODUCT_DIM.
We are planning to partition ORDER_FACT for performance improvements both reporting and loading. We have around 100 million rows in ORDER_FACT. Daily we inserted around 1 million rows and update around 2 million rows.
We are trying to come up with some good stratgies and we have few questions..
1) Our ORDER_FACT does not have any date columns except INSERT_DATE and LAST_UPDATE_DATE , more of timestamp columns. ORDER_DATE would be the appropriate one but we do not store it in fact. We have ORDER_DATE_KEY which is surrogatekey of TIME_DIM.
Can a range partition (monthly) still be performed ? ( I quess we need a ORDER_DATE column in our fact )
If somebody has handled this situation in some other way , any guidance will be helpful.
2) Question below is assuming - we have a partitioned ORDER_FACT on ORDER_DATE.
Currently we are doing a merge (Update/Insert) on ORDER_FACT. We have a incremental load (only newly inserted or updated rows from source) are processed.
Update/Insert is slow.
Can we use PEL (Partition Enabled loading ) and avoid merge (Update/Insert) ?
PEL is fine for new rows , since it replaces empty partition in target with a loaded partition from source . How to handle updation and insertion of rows in partition which has existing rows?
Any help on these would be helpful.
Thanks,
Samurai.

Speaking from our experience, at some point you need to build your fact rows so you need an insert/update prior to PEL anyway, and you would need your partitions closely matched to your refresh frequency for it really to be effective.
So what we have done is focus on the "E" part of ETL.
Our remote source database is mirrored on our side via Streams. This mirrors into a local copy that we can run various reports/ processes/ queries against without impacting production.
We also perform a custom aply that populates a second local copy of the tables, but these ones are partitioned daily and are used for our ETL. So, at the end of the day we have a partitioned set of data that contains only the current status of rows that have changed over the day. Now, of course, this is problematic for ETL because you need to have all of the associated information with those changes in order to do your ETL.
(simple example, data in a customer's address record changes. Your ETL query undoubtably joins the customer record and the address record to build your customer dimension row. But Streams only propogates the changed address record so you wouldn't have the customer record in that daily partition for your join)
So, we have a process that runs after the Streams aply is finished that walks the dependency tree and populates all dependant data into the current daily partition, so - at the end of our prep process we have a partitioned set of data that holds a complete set of source tables where anything has changed across any dependencies.
This gives us a small, efficient daily data set to run our ETL queries against.
The final piece of the puzzle is that we access this segment via synonyms, and the synonyms are pointed at this day's partition. We have a control structure that manages the list of partitions and repoints the synonyms prior to running the ETL. The partition loading and the ETL synonym pointing are completely decoupled so, for example, if we ever needed to suspend our ETL to get a code fix in place we can let the partition loading move ahead for a day or two and then play catchup loading the partitions in sequence and be confident that we have each end-of-day picture there to use.
By running our ETL against only the changed data, we acheive huge efficiencies in query performance. And by managing the ETL partitions, we don't incur the space costs of a second full copy of the source as we prune out the partitions once we are satisfied with the load at the end of a month (with full backups of course in case there is ever a huge problem to go back and correct).
Now for facts, of course, we expect these to be insert only. Facts shouldn't change. For dimensions we use set based fail over to row based (target only), with a couple specified to be Row Based Target Only as they are simply too large to ever complete in Set Based Mode.
Yes, this is a bit of a convoluted process - exacerbated by our need to have a full local copy for some reporting needs and the partitioned change copy for the datamart ETL, but at the end of the day it all works and works well with properly designed control mechanisms.
Cheers,
Mike

No data in Active table of DSO for fields populated by End Routine

Hi,
I have a Standard DSO where we are populating few fields by using End Routine.
Last week we added 5 more fields to DSO and wrote a logic in End ROutine to populate the DSO. These new fields dont have any mapping and these are just populated by end routine only.
When I loaded the data from Data Source TO DSO, Data is loaded correctly into NEW DATA Table of DSO for all the fields. I could see correct data as per the logic in NEW Table including old and new fields.
However, when I activate the DSO, I could not find the data for new fields which I added last week. Remaining fields are getting data as per the logic. Only these five fields are not having any data.
Can you please let me know if any one had similar issue. I was under impression that all the data in the new table will go to Active table when we activate the DSO.
Your inputs are highly appreciated.
Thanks
Krishna

What version of BW are you using? When editing your end-routine, a pop-up should display saying which fields you want populated/transferred from the end routine. This pop-up will not display if you are using a lower version of BW 7.x. To get around this, make sure that your newly added fields have a transformation rule type set to constant. This will make sure that the fields get populated when transferring from new to active tables.

Date fields are showing as / / in DSO for blank dates or no dates

We are loading flat file data to DSO and the date fields are showing as / / in DSO for blank dates or no dates in the flat file source system. We don't want to see this / / and instead of this, we would want to this field in DSO to be in blank. Please help how to achieve this. Is there any way to do this transformation. If yes, then can you please provide the sample coding.
Advance Thanks,
Christy

I have added the code and data loading is successful. while DSO activation, it is failing. The error message is,
Value '#' of characteristic 0DATE is not a number with 000008 spaces.
It seems that we need to change the code. Can you provide me the corrected code please. Thanks.
Christy

Creation of DSO for a standard cube

Hi All,
I am new in BI modeling area & looking for help from you experts. What I have to do is , I need to create a DSO for a standard Cube 0PS_CS01.
In this I am doing is to take that data source which is in BI content for this Cube and from there I am extracting data fields and keyfields. Once this DSO is ready I will create update rules from this standard Data source to this newly created to DSO and after that I will create Update rules for Cube based on this DSO.
Can you guys help me to find the best way to collect keyfields & data fields based on the data source. Also suggest me if it is the right way to design data model fot the same as I desribed above.
All helpful replies will be appriciated with points.
Thanks a lot in Advance.
Sincerely,
John

1>double click on cube(0PS_CS01) --copy all characteristics(these will be key fields in DSO).
DSO only take 16 key fields so rest will go under data fields.most unique 16 fields will go under key fields.
2.all the keyfigues will go under data fields of DSO.
change settings and activate DSO.create transformations between (DSO and DS) and ( DSO and CUBE);
Hope this helps.
if you need further info just check these two 0FIAP_C03(cube) and 0FIAP_O03(DSO).compare the characteristics and key figure with the key fields and data fields respectively.you will get good idea.
in the above cube the data flow is like DS-DSO-CUBE

Creation of DSO for a Z InfoCube on 3.5

Hi experts,
How can I create a DSO for a Z Infocube to be able to make delta to it in 3.5?
Thanks!
Artur.

To overwrite the values in ODS, you need to check the key fields of ODS. If the key fields for a particular record coming in BW are same as the already residing record in BW, then it would be overwritten, otherwise, will be added as a new record in ODS.

I am looking for a way to automate index creation using Adobe Reader Pro without having to use the screen user interface, as the indexing has to be run by a batch process.

I am looking for a way to automate index creation using Adobe Reader Pro without having to use the screen user interface, as the indexing has to be run by a batch process.

[discussion moved to Creating, Editing & Exporting PDFs forum.]

CONTEXT index creation - performance!

Hi,
I have a table with about 5Million rows. The content that needs to be indexed is of RAW datatype. The average size (length) of this field is about 50 characters (it could be more).
I am trying to index this column to perform a keyword search. DEtails are furnished below.
table:
SQL> desc kwtai
Name Null? Type
TSD_HH24 DATE
COUNTRY_CODE_ALPHA_2 VARCHAR2(2)
ONETWORK NUMBER(6)
OADDRESS VARCHAR2(25)
DNETWORK NUMBER(6)
DADDRESS VARCHAR2(25)
MESSAGE_LENGTH NUMBER
MESSAGE_CONTENT RAW(2000)
Preferences:-
begin
Ctx_Ddl.Create_Preference('mc_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('mc_storage','I_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'K_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'R_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('mc_storage', 'N_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M)');
ctx_ddl.set_attribute('mc_storage', 'I_INDEX_CLAUSE',
'tablespace large_index storage (initial 1M) compress 2');
ctx_ddl.create_preference('mc_lex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mc_lex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/.,');
ctx_ddl.set_attribute('mc_lex', 'INDEX_STEMS','NONE');
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters (' lexer mc_lex storage mc_storage memory 500M ')
parallel 16;
This create index takes about 4 hours to complete on a 8CPU dual core machine.
This is on Oracle 10g (10.2.0.4)
The reason i am creating the index as opposed to syncing it is because the data gets loaded into this table only once a day and it gets cleared once my keyword analysis is done.
Any pointers to speed up the index creation will be really appreciated! Thanks in advance!

My base table has the text that needs to be indexed stored in the "MESSAGE_CONTENT" column which for now is RAW data type. The data stored in this table are in hex representation.
Some examples -
MESSAGE_CONTENT
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69F16F
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69C3B16F
6865792E2C2C77686174277320676F696E67206F6E2E2E2E7066206368616E67277320697320736F6D652072657374617572616E742E2074686579206172652070736564756F2D636F6F6C
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E20706F73742D64617461
Now with your suggestion i tried to bypass this. So what i did was added a format column to my base table and updated it to "TEXT". My database is in UTF8.
Now when i create the index with the following preferences it takes less than a minute.
begin
Ctx_Ddl.Create_Preference('kwta_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('kwta_storage','I_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'K_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'R_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('kwta_storage', 'N_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M)');
ctx_ddl.set_attribute('kwta_storage', 'I_INDEX_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) compress 2');
ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mylex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/,');
ctx_ddl.set_attribute('mylex','punctuations','.?!');
ctx_ddl.set_attribute('mylex', 'INDEX_STEMS','NONE');
ctx_ddl.set_attribute('mylex', 'continuation','\-');
Ctx_Ddl.Create_Stoplist ( 'mystop' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'is' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'has' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'the' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'that' );
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters ('filter ctxsys.auto_filter format column fmt stoplist mystop lexer mylex storage kwta_storage memory 500M')
parallel 16;
When i select distinct tokens from the $I table i get the following
TOKEN_TEXT
RESTAURANT
GREEK
WHATS
ARE
DELTA
ZETA
ALPHA
ALPHABET
EPSILON
PF
PSEDUOCOOL
SOME
CHANGS
NIÃO
ON
POSTDATA
SCRIPT
BEEN
GAMMA
GOING
HEY
NI
O
THEY
BETA
Now what i am also wondering is if the text (message_content column) is being converted to UTF8 (database characterset) by using AUTO_FILTER. Is my assumption correct? Not sure how to validate this?
And, would you kindly share of why RAW must not be used in this case?
Thanks for all your pointers!

Index creation of 0figl_o02 taking too long.

Hi,
we load data to a ODS 0FIGL_O02 approx .5 million records daily. and recreate the index using the function module - RSSM_PROCESS_ODS_CREA_INDEXES.
The index creation job used to last for 3 -4 hours six months ago. but now the job runs for 6 hours, is there a way to decrese the job time.
the no of records in the active table of ODS is 424 million.

hi,
this DSO is based on DS 0FI_GL_4 which is delta enabled.
Do you mean to say that you are receiving .5 million data daily?
if yes then there is not much that you can do, as the program will try to create the incremental index and will have to find the current index of 240 million records. One thing you can do is that as a regular Monthly activity you can completely delete the index of the cube and recreate it(this may take huge time but it would correct some of the corrupt indexes).
this below sap note might help you.
Note 1413496 - DB2-z/OS: BW: Building indexes on active DSO data
If you are not using to report or lookup on this DSO then please do not create secondary indexes.
regards,
Arvind.
Edited by: Arvind Tekra on Aug 25, 2011 5:18 PM

Index creation on a field in DSO for performance improvement of a select st

Similar Messages

Maybe you are looking for