Speed up table query performance

Hi,
I have a table with 200mil rows (approx 30G size). What are the multiple ways to improve query performance on this table? We have tried indexing, but doesn't help much. Partitioning - I am not sure how to use it, since there is no clear criteria for creating partitions. What other options could I use?
If this is in the wrong forum, please suggest appropriate forum.
Thanks in advance.

Assuming you have purchased the partitioning option from Oracle and are not violating the terms of your license agreement then partitioning is the way to go.
For the concept docs go to http://tahiti.oracle.com
For demos of all of the various forms of partitioning go to Morgan's Library at www.psoug.org and look up partitioning.
New partitioning options have been added in 11gR1 so some of the demos may not work for you: Most will.

Similar Messages

Speed up SQL Query performance

Hi,
I am having a SQL query which has got some inner joins between tables.
In this query i will be selecting values from set of values obtained by going through all rows in a table.
I am using a inner join between two tables to achive this purpose.
But, as the table which i go through all rows is extremely big it takes lot of time to go through all rows and the query slows down.
Is there any other way by which i can speed up query.

This is the out put of my test plan.
Please suggest which one needs to be improved.
PLAN_TABLE_OUTPUT
Plan hash value: 3453987661
| Id | Operation                               | Name                           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                        |                                |     3 | 1002 | 3920   (1)| 00:00:48 |
|   1 | SORT ORDER BY                          |                                |     3 | 1002 | 3920   (1)| 00:00:48 |
|* 2 |   TABLE ACCESS BY INDEX ROWID           | AS_EVENT_CHR_DATA              |     1 |    17 |     4   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                         |                                |     3 | 1002 | 3919   (1)| 00:00:48 |
|* 4 |     HASH JOIN                           |                                |     3 |   951 | 3907   (1)| 00:00:47 |
|* 5 |      TABLE ACCESS FULL                  | EV_CHR_DATA_TYPE               |     1 |    46 |     2   (0)| 00:00:01 |
|   6 |      TABLE ACCESS BY INDEX ROWID        | AS_EVENT_CHR_DATA              |   702 | 50544 | 3883   (1)| 00:00:47 |
|   7 |       NESTED LOOPS                      |                                |   348 | 94308 | 3904   (1)| 00:00:47 |
|   8 |        NESTED LOOPS                     |                                |     1 |   199 |    21   (5)| 00:00:01 |
|   9 |         NESTED LOOPS                    |                                |     1 |   174 |    20   (5)| 00:00:01 |
|* 10 |          HASH JOIN                      |                                |     1 |   127 |    18   (6)| 00:00:01 |
| 11 |           NESTED LOOPS                  |                                |     1 |    95 |    13   (0)| 00:00:01 |
| 12 |            NESTED LOOPS                 |                                |     1 |    60 |    12   (0)| 00:00:01 |
| 13 |             NESTED LOOPS                |                                |     1 |    33 |    10   (0)| 00:00:01 |
| 14 |              TABLE ACCESS BY INDEX ROWID| ASSET                          |     1 |    21 |     2   (0)| 00:00:01 |
|* 15 |               INDEX UNIQUE SCAN         | SERIAL_NUMBER_K3               |     1 |       |     1   (0)| 00:00:01 |
|* 16 |              INDEX FAST FULL SCAN       | SYS_C0053318                   |     1 |    12 |     8   (0)| 00:00:01 |
| 17 |             TABLE ACCESS BY INDEX ROWID | SEGMENT_CHILD                  |     1 |    27 |     2   (0)| 00:00:01 |
|* 18 |              INDEX RANGE SCAN           | SYS_C0053319                   |    12 |       |     1   (0)| 00:00:01 |
| 19 |            TABLE ACCESS BY INDEX ROWID | SEGMENT                        |     1 |    35 |     1   (0)| 00:00:01 |
|* 20 |             INDEX UNIQUE SCAN           | SYS_C0053318                   |     1 |       |     0   (0)| 00:00:01 |
|* 21 |           TABLE ACCESS FULL             | SEGMENT_TYPE                   |     1 |    32 |     4   (0)| 00:00:01 |
| 22 |          TABLE ACCESS BY INDEX ROWID    | ASSET_ON_SEGMENT               |     1 |    47 |     2   (0)| 00:00:01 |
|* 23 |           INDEX RANGE SCAN              | ASSET_ON_SEGME_UK8115533871153 |     1 |       |     1   (0)| 00:00:01 |
| 24 |         TABLE ACCESS BY INDEX ROWID     | ASSET                          |     1 |    25 |     1   (0)| 00:00:01 |
|* 25 |          INDEX UNIQUE SCAN              | SYS_C0053240                   |     1 |       |     0   (0)| 00:00:01 |
|* 26 |        INDEX RANGE SCAN                 | AS_EV_CHR_DATA_ASSETPK         | 4673 |       |    28   (4)| 00:00:01 |
|* 27 |     INDEX RANGE SCAN                    | SYS_C0053249                   |     5 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("PARAMETRIC_TAG_NAME"."DATA_VALUE"='EngineOilConsumption')
   4 - access("AS_EVENT_CHR_DATA"."EC_DB_SITE"="EV_CHR_DATA_TYPE"."EC_DB_SITE" AND
              "AS_EVENT_CHR_DATA"."EC_DB_ID"="EV_CHR_DATA_TYPE"."EC_DB_ID" AND
              "AS_EVENT_CHR_DATA"."EC_TYPE_CODE"="EV_CHR_DATA_TYPE"."EC_TYPE_CODE")
   5 - filter("EV_CHR_DATA_TYPE"."NAME"='servicing ptric time unit')
10 - access("OILSEG"."SG_TYPE_CODE"="SEGMENT_TYPE"."SG_TYPE_CODE")
15 - access("ASSET"."SERIAL_NUMBER"='30870')
16 - filter("ASSET"."ASSET_ID"="SEGMENT"."SEGMENT_ID")
18 - access("SEGMENT"."SEGMENT_SITE"="SEGMENT_CHILD"."SEGMENT_SITE" AND
              "SEGMENT"."SEGMENT_ID"="SEGMENT_CHILD"."SEGMENT_ID")
20 - access("SEGMENT_CHILD"."CHILD_SG_SITE"="OILSEG"."SEGMENT_SITE" AND
              "SEGMENT_CHILD"."CHILD_SG_ID"="OILSEG"."SEGMENT_ID")
21 - filter("SEGMENT_TYPE"."NAME"='Aircraft Equipment Engine Holder')
23 - access("OILSEG"."SEGMENT_ID"="ASSET_ON_SEGMENT"."SEGMENT_ID")
25 - access("ASSET_ON_SEGMENT"."ASSET_ORG_SITE"="OILASSET"."ASSET_ORG_SITE" AND
              "ASSET_ON_SEGMENT"."ASSET_ID"="OILASSET"."ASSET_ID")
26 - access("ASSET_ON_SEGMENT"."ASSET_ORG_SITE"="AS_EVENT_CHR_DATA"."ASSET_ORG_SITE" AND
              "ASSET_ON_SEGMENT"."ASSET_ID"="AS_EVENT_CHR_DATA"."ASSET_ID")
27 - access("AS_EVENT_CHR_DATA"."AS_EV_ID"="PARAMETRIC_TAG_NAME"."AS_EV_ID")

Unexplained poor table query performance

Hi All
I am really open to any advice as I have hit a kind of brick wall, a developer came to me asking about y a procedure was performing so slowly in beta as opposed to dev and after looking at exactly what it did I indentified the offending
select statement.
The query was basically passing some ids into a user defined table and using that thoses ids to filter.
Select gc.id
From temperatures as gcm left outer join
gauges gc ON ( gc.id = gcm.id Or gc.id IS NULL )
AND ( gc.countryid = gcm.countryid or gcm.countryid is null )
where souriceid = 3
So the gauges table has around 90K where as the temperatures has around 3 million .
K the test on the development server and the above returns in under 3 seconds where as the beta is just over 1 minute .
The beta in terms of processing power is much fast and both have the same version of SQL2012 sp1 ( 11.0.3128 ( x64))
having ran a quick query on index fragmentation i find there are a few indexes within the temperature table that are reasonable high. I then rebuild them and see that they are pretty much back to an acceptable level. Again I try the select
and a few times and get a range of times .
I then tried a restore from the weekend just to see if there was anything that may have changed and wondering if I was beginning to clutch at straws.
low and behold the restore was not only quick but from an index fragmentation point of view not in as great shape.
Ive compared the two tables which are identical with the only difference being in data to which I copied over to the restore and got the same 2 second result.
Any help on what to do next would be great , as I could replace the table with the restored one but I would like to know why this is happening .
Many Thanks
Robert

The query is a bit strange with the NULL checks on gc.id and gcm.countryid.
Since temperatures is the retained (outer) table, you can remove the part "or gcm.countryid is null".
Also, if table gauges does not allow NULLs (or does not have NULLs) in column id, you should remove the part "OR gc.id IS NULL".
If the query can be simplified as stated above, then all you need is a compound index on (id, countryid) or on (countryid, id) on both tables.
If the problem still persists, you can check the query plan to see what is different, and that should give you a clue about the issue.
Please note that for performance related queries, it is essential to show the exact query you are using. For example, if you are using a local variable or a parameter instead of "3" in your query, that makes a big difference.
If you need more help, then please post DDL for the tables and indexes that are involved.
Gert-Jan

How to improve Query performance on large table in MS SQL Server 2008 R2

I have a table with 20 million records. What is the best option to improve query performance on this table. Is partitioning the table into filegroups is a best option or splitting the table into multiple smaller tables?

Hi bala197164,
First, I want to inform that both to partition the table into filegroups and split the table into multiple smaller tables can improve the table query performance, and they are fit for different situation. For example, our table have one hundred columns and
some columns are not related to this table object directly (for example, there is a table named userinfo to store user information, it has columns address_street, address_zip,address_ province columns, at this time, we can create a new table named as Address,
and add a foreign key in userinfo table references Address table), under this situation, by splitting a large table into smaller, individual tables, queries that access only a fraction of the data can run faster because there is less data to scan. Another
situation is our table records can be grouped easily, for example, there is a column named year to store information about product release date, at this time, we can partition the table into filegroups to improve the query performance. Usually, we perform
both of methods together. Additionally, we can add index to table to improve the query performance. For more detail information, please refer to the following document:
Partitioning:
http://msdn.microsoft.com/en-us/library/ms178148.aspx
CREATE INDEX (Transact-SQL):
http://msdn.microsoft.com/en-us/library/ms188783.aspx
TechNet
Subscriber Support
If you are
TechNet Subscription user and have any feedback on our support quality, please send your feedback
here.
Allen Li
TechNet Community Support

Poor query performance when joining CONTAINS to another table

We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
For example, we can find all the records a user has access to from our base table by the following query:
SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID;
This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
Our search query looks like this:
SELECT score(1), d.*
FROM duns d
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
WITH subset
AS
(SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID
SELECT score(1), d.*
FROM duns d
JOIN subset s
ON d.duns_loc = s.duns_loc
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
Thanks!!

Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
SCOTT@orcl_11gR2> -- tables:
SCOTT@orcl_11gR2> CREATE TABLE duns
2    (duns_loc NUMBER,
3      text_key VARCHAR2 (30))
4 /
Table created.
SCOTT@orcl_11gR2> CREATE TABLE primary_contact
2    (duns_loc NUMBER,
3      emp_id       NUMBER)
4 /
Table created.
SCOTT@orcl_11gR2> -- data:
SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO duns
2 SELECT object_id, object_name
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact
2 SELECT object_id, namespace
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> -- indexes:
SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
2 ON duns (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
2 ON primary_contact (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
SCOTT@orcl_11gR2> -- as suggested by Roger:
SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
2 ON duns (text_key)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 FILTER BY duns_loc
5 /
Index created.
SCOTT@orcl_11gR2> -- gather statistics:
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- variables:
SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
SCOTT@orcl_11gR2> EXEC :employeeid := 1
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
SCOTT@orcl_11gR2> EXEC :search := 'highway'
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- original query:
SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
SCOTT@orcl_11gR2> WITH
2    subset AS
3       (SELECT d.duns_loc
4        FROM      duns d
5        JOIN      primary_contact pc
6        ON      d.duns_loc = pc.duns_loc
7        AND      pc.emp_id = :employeeID)
8 SELECT score(1), d.*
9 FROM   duns d
10 JOIN   subset s
11 ON     d.duns_loc = s.duns_loc
12 WHERE CONTAINS (TEXT_KEY, :search,1) > 0
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 4228563783
| Id | Operation                      | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                   |     2 |    84 |   121   (4)| 00:00:02 |
|   1 | SORT ORDER BY                 |                   |     2 |    84 |   121   (4)| 00:00:02 |
|* 2 |   HASH JOIN                    |                   |     2 |    84 |   120   (3)| 00:00:02 |
|   3 |    NESTED LOOPS                |                   |    38 | 1292 |    50   (2)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 5 |      DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | DUNS_DUNS_LOC_IDX |     1 |     5 |     1   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL           | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
   5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
   6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
   7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
SCOTT@orcl_11gR2> WITH
2    subset1 AS
3       (SELECT pc.duns_loc
4        FROM      primary_contact pc
5        WHERE pc.emp_id = :employeeID),
6    subset2 AS
7       (SELECT score(1), d.*
8        FROM      duns d
9        WHERE CONTAINS (TEXT_KEY, :search,1) > 0)
10 SELECT subset2.*
11 FROM   subset1, subset2
12 WHERE subset1.duns_loc = subset2.duns_loc
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
SCOTT@orcl_11gR2> SELECT subset2.*
2 FROM   (SELECT pc.duns_loc
3           FROM   primary_contact pc
4           WHERE pc.emp_id = :employeeID) subset1,
5          (SELECT score(1), d.*
6           FROM   duns d
7           WHERE CONTAINS (TEXT_KEY, :search,1) > 0) subset2
8 WHERE subset1.duns_loc = subset2.duns_loc
9 ORDER BY score(1) DESC
10 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- ansi join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 JOIN   primary_contact
4 ON     duns.duns_loc = primary_contact.duns_loc
5 WHERE CONTAINS (duns.text_key, :search, 1) > 0
6 AND    primary_contact.emp_id = :employeeid
7 ORDER BY SCORE(1) DESC
8 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- old join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns, primary_contact
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc = primary_contact.duns_loc
5 AND    primary_contact.emp_id = :employeeid
6 ORDER BY SCORE(1) DESC
7 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- in clause:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc IN
5          (SELECT primary_contact.duns_loc
6           FROM   primary_contact
7           WHERE primary_contact.emp_id = :employeeid)
8 ORDER BY SCORE(1) DESC
9 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 3825821668
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN SEMI              |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2>

SELECT query performance : One big table Vs many small tables

Hello,
We are using BDB 11g with SQLITE support. I have a query about 'select' query performance when we have one huge table vs. multiple small tables.
Basically in our application, we need to run select query multiple times and today we have one huge table. Do you guys think breaking them into
multiple small tables will help ?
For test purposes we tried creating multiple tables but performance of 'select' query was more or less same. Would that be because all tables will map to only one database in backed with key/value pair and when we run lookup (select query) on small table or big table it wont make difference ?
Thanks.

Hello,
There is some information on this topic in the FAQ at:
http://www.oracle.com/technology/products/berkeley-db/faq/db_faq.html#9-63
If this does not address your question, please just let me know.
Thanks,
Sandra

Having more LTSs in logical dimension table hit the query performance?

Hi,
We have a logical table having around 19 LTSs. Having more LTSs in logical dimension table hit the query performance?
Thanks,
Anilesh

Hi Anilesh,
Its kind of both YES and NO. Here is why...
NO:
LTS are supposed to give BI Server an optimistic and logical way to retrieve the data. So, having more Optimistic LTS might help the BI Server with some good options tailored to a variety of analysis requests.
YES:
Many times, we have to bring in multiple physical tables as a part of single LTS (Mostly when the physical model is a snowflake) which might cause performance issues. Say there is a LTS with two tables "A" and "B", but for a ad-hoc analysis just on columns in "A", the query would still include the join with table "B" if this LTS is being used. We might want to avoid this kind of situations with multiple LTS each for a table and one for both of them.
Hope this helps.
Thank you,
Dhar

Reg: Process Chain, query performance tuning steps

Hi All,
I come across a question like, There is a process chain of 20 processes.out of which 5 processes are completed at the 6th step error occured and it cannot be rectified. I should start the chain again from the 7th step.If i go to a prticular step i can do that particular step, How can i start the entair chain again from step 7.i know that i need to use a function module but i dont know the name of FM. Please somebody help me out.
Please let me know the steps involved in query performance tuning and aggregate tuning.
Thanks & Regards
Omkar.K

Hi,
Process Chain
Method 1 (when it fails in a step/request)
/people/siegfried.szameitat/blog/2006/02/26/restarting-processchains
How is it possible to restart a process chain at a failed step/request?
Sometimes, it doesn't help to just set a request to green status in order to run the process chain from that step on to the end.
You need to set the failed request/step to green in the database as well as you need to raise the event that will force the process chain to run to the end from the next request/step on.
Therefore you need to open the messages of a failed step by right clicking on it and selecting 'display messages'.
In the opened popup click on the tab 'Chain'.
In a parallel session goto transaction se16 for table rspcprocesslog and display the entries with the following selections:
1. copy the variant from the popup to the variante of table rspcprocesslog
2. copy the instance from the popup to the instance of table rspcprocesslog
3. copy the start date from the popup to the batchdate of table rspcprocesslog
Press F8 to display the entries of table rspcprocesslog.
Now open another session and goto transaction se37. Enter RSPC_PROCESS_FINISH as the name of the function module and run the fm in test mode.
Now copy the entries of table rspcprocesslog to the input parameters of the function module like described as follows:
1. rspcprocesslog-log_id -> i_logid
2. rspcprocesslog-type -> i_type
3. rspcprocesslog-variante -> i_variant
4. rspcprocesslog-instance -> i_instance
5. enter 'G' for parameter i_state (sets the status to green).
Now press F8 to run the fm.
Now the actual process will be set to green and the following process in the chain will be started and the chain can run to the end.
Of course you can also set the state of a specific step in the chain to any other possible value like 'R' = ended with errors, 'F' = finished, 'X' = cancelled ....
Check out the value help on field rspcprocesslog-state in transaction se16 for the possible values.
Query performance tuning
General tips
Using aggregates and compression.
Using less and complex cell definitions if possible.
1. Avoid using too many nav. attr
2. Avoid RKF and CKF
3. Many chars in row.
By using T-codes ST03 or ST03N
Go to transaction ST03 > switch to expert mode > from left side menu > and there in system load history and distribution for a particual day > check query execution time.
/people/andreas.vogel/blog/2007/04/08/statistical-records-part-4-how-to-read-st03n-datasets-from-db-in-nw2004
/people/andreas.vogel/blog/2007/03/16/how-to-read-st03n-datasets-from-db
Try table rsddstats to get the statistics
Using cache memoery will decrease the loading time of the report.
Run reporting agent at night and sending results to email.This will ensure use of OLAP cache. So later report execution will retrieve the result faster from the OLAP cache.
Also try
1. Use different parameters in ST03 to see the two important parameters aggregation ratio and records transferred to F/E to DB selected.
2. Use the program SAP_INFOCUBE_DESIGNS (Performance of BW infocubes) to see the aggregation ratio for the cube. If the cube does not appear in the list of this report, try to run RSRV checks on the cube and aggregates.
Go to SE38 > Run the program SAP_INFOCUBE_DESIGNS
It will shown dimension Vs Fact tables Size in percent.If you mean speed of queries on a cube as performance metric of cube,measure query runtime.
3. --- sign is the valuation of the aggregate. You can say -3 is the valuation of the aggregate design and usage. ++ means that its compression is good and access is also more (in effect, performance is good). If you check its compression ratio, it must be good. -- means the compression ratio is not so good and access is also not so good (performance is not so good).The more is the positives...more is useful the aggregate and more it satisfies the number of queries. The greater the number of minus signs, the worse the evaluation of the aggregate. The larger the number of plus signs, the better the evaluation of the aggregate.
if "-----" then it means it just an overhead. Aggregate can potentially be deleted and "+++++" means Aggregate is potentially very useful.
Refer.
http://help.sap.com/saphelp_nw70/helpdata/en/b8/23813b310c4a0ee10000000a114084/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/60/f0fb411e255f24e10000000a1550b0/frameset.htm
4. Run your query in RSRT and run the query in the debug mode. Select "Display Aggregates Found" and "Do not use cache" in the debug mode. This will tell you if it hit any aggregates while running. If it does not show any aggregates, you might want to redesign your aggregates for the query.
Also your query performance can depend upon criteria and since you have given selection only on one infoprovider...just check if you are selecting huge amount of data in the report
Check for the query read mode in RSRT.(whether its A,X or H)..advisable read mode is X.
5. In BI 7 statistics need to be activated for ST03 and BI admin cockpit to work.
By implementing BW Statistics Business Content - you need to install, feed data and through ready made reports which for analysis.
http://help.sap.com/saphelp_nw70/helpdata/en/26/4bc0417951d117e10000000a155106/frameset.htm
/people/vikash.agrawal/blog/2006/04/17/query-performance-150-is-aggregates-the-way-out-for-me
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1955ba90-0201-0010-d3aa-8b2a4ef6bbb2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
http://help.sap.com/saphelp_nw04/helpdata/en/c1/0dbf65e04311d286d6006008b32e84/frameset.htm
You can go to T-Code DB20 which gives you all the performance related information like
Partitions
Databases
Schemas
Buffer Pools
Tablespaces etc
use tool RSDDK_CHECK_AGGREGATE in se38 to check for the corrupt aggregates
If aggregates contain incorrect data, you must regenerate them.
Note 646402 - Programs for checking aggregates (as of BW 3.0B SP15)
Thanks,
JituK

How to improve query performance using infoset

I create one infoset that including 4 char.and 3 DSO which all are time-dependent.When query run, system show very poor perfomance, sometimes no data show in BEX anayzer. In this case I have to close BEX analyzer at first and then open it again, after that it show real results. It seems very strange. Does anybody has experience on infoset performance improvement. pls info, thanks!

Hi
As info set itself doesn't have any data so it improves Performance
also go through the below tips.
Find the query Run-time
where to find the query Run-time ?
557870 'FAQ BW Query Performance'
130696 - Performance trace in BW
This info may be helpful.
General tips
Using aggregates and compression.
Using less and complex cell definitions if possible.
1. Avoid using too many nav. attr
2. Avoid RKF and CKF
3. Many chars in row.
By using T-codes ST03 or ST03N
Go to transaction ST03 > switch to expert mode > from left side menu > and there in system load history and distribution for a particular day > check query execution time.
Statistical Records Part 4: How to read ST03N datasets from DB in NW2004
How to read ST03N datasets from DB
Try table rsddstats to get the statistics
Using cache memory will decrease the loading time of the report.
Run reporting agent at night and sending results to email. This will ensure use of OLAP cache. So later report execution will retrieve the result faster from the OLAP cache.
Also try
1. Use different parameters in ST03 to see the two important parameters aggregation ratio and records transferred to F/E to DB selected.
2. Use the program SAP_INFOCUBE_DESIGNS (Performance of BW infocubes) to see the aggregation ratio for the cube. If the cube does not appear in the list of this report, try to run RSRV checks on the cube and aggregates.
Go to SE38 > Run the program SAP_INFOCUBE_DESIGNS
It will shown dimension Vs Fact tables Size in percent.If you mean speed of queries on a cube as performance metric of cube,measure query runtime.
3. To check the performance of the aggregates,see the columns valuation and usage in aggregates.
Open the Aggregates...and observe VALUATION and USAGE columns.
"---" sign is the valuation of the aggregate. You can say -3 is the valuation of the aggregate design and usage. ++ means that its compression is good and access is also more (in effect, performance is good). If you check its compression ratio, it must be good. -- means the compression ratio is not so good and access is also not so good (performance is not so good).The more is the positives...more is useful the aggregate and more it satisfies the number of queries. The greater the number of minus signs, the worse the evaluation of the aggregate. The larger the number of plus signs, the better the evaluation of the aggregate.
if "-----" then it means it just an overhead. Aggregate can potentially be deleted and "+++++" means Aggregate is potentially very useful.
In valuation column,if there are more positive sign it means that the aggregate performance is good and it is useful to have this aggregate.But if it has more negative sign it means we need not better use that aggregate.
In usage column,we will come to know how far the aggregate has been used in query.
Thus we can check the performance of the aggregate.
Refer.
http://help.sap.com/saphelp_nw70/helpdata/en/b8/23813b310c4a0ee10000000a114084/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/60/f0fb411e255f24e10000000a1550b0/frameset.htm
performance ISSUE related to AGGREGATE
Note 356732 - Performance Tuning for Queries with Aggregates
Note 166433 - Options for finding aggregates (find optimal aggregates for an InfoCube)
4. Run your query in RSRT and run the query in the debug mode. Select "Display Aggregates Found" and "Do not use cache" in the debug mode. This will tell you if it hit any aggregates while running. If it does not show any aggregates, you might want to redesign your aggregates for the query.
Also your query performance can depend upon criteria and since you have given selection only on one infoprovider...just check if you are selecting huge amount of data in the report
Check for the query read mode in RSRT.(whether its A,X or H)..advisable read mode is X.
5. In BI 7 statistics need to be activated for ST03 and BI admin cockpit to work.
By implementing BW Statistics Business Content - you need to install, feed data and through ready made reports which for analysis.
http://help.sap.com/saphelp_nw70/helpdata/en/26/4bc0417951d117e10000000a155106/frameset.htm
/people/vikash.agrawal/blog/2006/04/17/query-performance-150-is-aggregates-the-way-out-for-me
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1955ba90-0201-0010-d3aa-8b2a4ef6bbb2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
http://help.sap.com/saphelp_nw04/helpdata/en/c1/0dbf65e04311d286d6006008b32e84/frameset.htm
You can go to T-Code DB20 which gives you all the performance related information like
Partitions
Databases
Schemas
Buffer Pools
Tablespaces etc
use tool RSDDK_CHECK_AGGREGATE in se38 to check for the corrupt aggregates
If aggregates contain incorrect data, you must regenerate them.
202469 - Using aggregate check tool
Note 646402 - Programs for checking aggregates (as of BW 3.0B SP15)
You can find out whether an aggregate is usefull or useless you can find out through a proccess of checking the tables RSDDSTATAGGRDEF*
Run the query in RSRT with statistics execute and come back you will get STATUID... copy this and check in the table...
This gives you exactly which infoobjects it's hitting, if any one of the object is missing it's useless aggregate.
6
Check SE11 > table RSDDAGGRDIR . You can find the last callup in the table.
Generate Report in RSRT
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
Business Intelligence Journal Improving Query Performance in Data Warehouses
http://www.tdwi.org/Publications/BIJournal/display.aspx?ID=7891
Achieving BI Query Performance Building Business Intelligence
http://www.dmreview.com/issues/20051001/1038109-1.html
Assign points if useful
Cheers
SM

Speeding up a query on a concatenated field.

Hi,
I have a view with a concatenated field that basically comes down on this:
ALTER VIEW [dbo].[_FO_QP_Items_4_0] AS
SELECT
Col A ,Col B --etc
,CONVERT(nvarchar(36), sysguid) +'|'+crdnr AS [LevCode]
FROM table A
As you see I am concatenating 2 fields together to get a unique [LevCode] (concatenating Itemcode + Supplier code)
If I query that view like this, it runs rather slow on a 500.000+ rows table:
SELECT *
FROM [dbo].[_FO_QP_Items_4_0]
WHERE [LevCode] = 'DF007704-38EF-4389-8544-E70CC32404D5| 60102'
ORDER BY Col A
Unfortunately I am not able to add an extra column to the table and concatenate the fields there.
Is there a way to speed up the query (or view).
Thanks for helping me out here.

Index view has high overhead. It has to be really justified.
BOL: "Indexed views work best when the underlying data is infrequently updated. The maintenance of an indexed view can be greater than the cost of maintaining a table index. If the underlying data is updated frequently, the cost of maintaining the indexed
view data may outweigh the performance benefits of using the indexed view. If the underlying data is updated periodically in batches but treated primarily as read-only between updates, consider dropping any indexed views before updating, and rebuilding them
afterward. Doing this may improve performance of the updates."
Reference:
https://technet.microsoft.com/en-us/library/ms187864%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

QUERY PERFORMANCE AND DATA LOADING PERFORMANCE ISSUES

WHAT ARE QUERY PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES...PLZ URGENT
WHAT ARE DATALOADING PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES PLZ URGENT
WILL REWARD FULL POINT S
REGARDS
GURU

BW Back end
Some Tips -
1)Identify long-running extraction processes on the source system. Extraction processes are performed by several extraction jobs running on the source system. The run-time of these jobs affects the performance. Use transaction code SM37 Background Processing Job Management to analyze the run-times of these jobs. If the run-time of data collection jobs lasts for several hours, schedule these jobs to run more frequently. This way, less data is written into update tables for each run and extraction performance increases.
2)Identify high run-times for ABAP code, especially for user exits. The quality of any custom ABAP programs used in data extraction affects the extraction performance. Use transaction code SE30 ABAP/4 Run-time Analysis and then run the analysis for the transaction code RSA3 Extractor Checker. The system then records the activities of the extraction program so you can review them to identify time-consuming activities. Eliminate those long-running activities or substitute them with alternative program logic.
3)Identify expensive SQL statements. If database run-time is high for extraction jobs, use transaction code ST05 Performance Trace. On this screen, select ALEREMOTE user and then select SQL trace to record the SQL statements. Identify the time-consuming sections from the results. If the data-selection times are high on a particular SQL statement, index the DataSource tables to increase the performance of selection (see no. 6 below). While using ST05, make sure that no other extraction job is running with ALEREMOTE user.
4)Balance loads by distributing processes onto different servers if possible. If your site uses more than one BW application server, distribute the extraction processes to different servers using transaction code SM59 Maintain RFC Destination. Load balancing is possible only if the extraction program allows the option
5)Set optimum parameters for data-packet size. Packet size affects the number of data requests to the database. Set the data-packet size to optimum values for an efficient data-extraction mechanism. To find the optimum value, start with a packet size in the range of 50,000 to 100,000 and gradually increase it. At some point, you will reach the threshold at which increasing packet size further does not provide any performance increase. To set the packet size, use transaction code SBIW BW IMG Menu on the source system. To set the data load parameters for flat-file uploads, use transaction code RSCUSTV6 in BW.
6)Build indexes on DataSource tables based on selection criteria. Indexing DataSource tables improves the extraction performance, because it reduces the read times of those tables.
7)Execute collection jobs in parallel. Like the Business Content extractors, generic extractors have a number of collection jobs to retrieve relevant data from DataSource tables. Scheduling these collection jobs to run in parallel reduces the total extraction time, and they can be scheduled via transaction code SM37 in the source system.
8). Break up your data selections for InfoPackages and schedule the portions to run in parallel. This parallel upload mechanism sends different portions of the data to BW at the same time, and as a result the total upload time is reduced. You can schedule InfoPackages in the Administrator Workbench.
You can upload data from a data target (InfoCube and ODS) to another data target within the BW system. While uploading, you can schedule more than one InfoPackage with different selection options in each one. For example, fiscal year or fiscal year period can be used as selection options. Avoid using parallel uploads for high volumes of data if hardware resources are constrained. Each InfoPacket uses one background process (if scheduled to run in the background) or dialog process (if scheduled to run online) of the application server, and too many processes could overwhelm a slow server.
9). Building secondary indexes on the tables for the selection fields optimizes these tables for reading, reducing extraction time. If your selection fields are not key fields on the table, primary indexes are not much of a help when accessing data. In this case it is better to create secondary indexes with selection fields on the associated table using ABAP Dictionary to improve better selection performance.
10)Analyze upload times to the PSA and identify long-running uploads. When you extract the data using PSA method, data is written into PSA tables in the BW system. If your data is on the order of tens of millions, consider partitioning these PSA tables for better performance, but pay attention to the partition sizes. Partitioning PSA tables improves data-load performance because it's faster to insert data into smaller database tables. Partitioning also provides increased performance for maintenance of PSA tables for example, you can delete a portion of data faster. You can set the size of each partition in the PSA parameters screen, in transaction code SPRO or RSCUSTV6, so that BW creates a new partition automatically when a threshold value is reached.
11)Debug any routines in the transfer and update rules and eliminate single selects from the routines. Using single selects in custom ABAP routines for selecting data from database tables reduces performance considerably. It is better to use buffers and array operations. When you use buffers or array operations, the system reads data from the database tables and stores it in the memory for manipulation, improving performance. If you do not use buffers or array operations, the whole reading process is performed on the database with many table accesses, and performance deteriorates. Also, extensive use of library transformations in the ABAP code reduces performance; since these transformations are not compiled in advance, they are carried out during run-time.
12)Before uploading a high volume of transaction data into InfoCubes, activate the number-range buffer for dimension IDs. The number-range buffer is a parameter that identifies the number of sequential dimension IDs stored in the memory. If you increase the number range before high-volume data upload, you reduce the number of reads from the dimension tables and hence increase the upload performance. Do not forget to set the number-range values back to their original values after the upload. Use transaction code SNRO to maintain the number range buffer values for InfoCubes.
13)Drop the indexes before uploading high-volume data into InfoCubes. Regenerate them after the upload. Indexes on InfoCubes are optimized for reading data from the InfoCubes. If the indexes exist during the upload, BW reads the indexes and tries to insert the records according to the indexes, resulting in poor upload performance. You can automate the dropping and regeneration of the indexes through InfoPackage scheduling. You can drop indexes in the Manage InfoCube screen in the Administrator Workbench.
14)IDoc (intermediate document) archiving improves the extraction and loading performance and can be applied on both BW and R/3 systems. In addition to IDoc archiving, data archiving is available for InfoCubes and ODS objects.
Hope it Helps
Chetan
@CP..

Query Performance issue in Oracle Forms

Hi All,
I am using oracle 9i DB and forms 6i.
In query form ,qry took long time to load the data into form.
There are two tables used here.
1 table(A) contains 5 crore records another table(B) has 2 crore records.
The recods fetching range 1-500 records.
Table (A) has no index on main columns,after created the index on main columns in table A ,the query is fetched the data quickly.
But DBA team dont want to create index on table A.Because of table space problem.
If create the index on main table (A) ,then performance overhead in production.
Concurrent user capacity is 1500.
Is there any alternative methods to handle this problem.
Regards,
RS

1) What is a crore? Wikipedia seems to indicate that it's either 10,000,000 or 500,000
http://en.wikipedia.org/wiki/Crore
I'll assume that we're talking about tables with 50 million and 20 million rows, respectively.
2) Large tables with no indexes are definitely going to be slow. If you don't have the disk space to create an appropriate index, surely the right answer is to throw a bit of disk into the system.
3) I don't understand the comment "If create the index on main table (A) ,then performance overhead in production." That seems to contradict the comment you made earlier that the query performs well when you add the index. Are you talking about some other performance overhead?
Justin

How to improve query performance built on a ODS

Hi,
I've built a report on FI_GL ODS (BW3.5). The report execution time takes almost 1hr.
Is there any method to improve or optimize th query performance that build on ODS.
The ODS got huge volume of data ~ 300 Million records for 2 years.
Thanx in advance,
Guru.

Hi Raj,
Here are some few tips which helps you in improving ur query performance
Checklist for Query Performance
1. If exclusions exist, make sure they exist in the global filter area. Try to remove exclusions by subtracting out inclusions.
2. Use Constant Selection to ignore filters in order to move more filters to the global filter area. (Use ABAPer to test and validate that this ensures better code)
3. Within structures, make sure the filter order exists with the highest level filter first.
4. Check code for all exit variables used in a report.
5. Move Time restrictions to a global filter whenever possible.
6. Within structures, use user exit variables to calculate things like QTD, YTD. This should generate better code than using overlapping restrictions to achieve the same thing. (Use ABAPer to test and validate that this ensures better code).
7. When queries are written on multiproviders, restrict to InfoProvider in global filter whenever possible. MultiProvider (MultiCube) queries require additional database table joins to read data compared to those queries against standard InfoCubes (InfoProviders), and you should therefore hardcode the infoprovider in the global filter whenever possible to eliminate this problem.
8. Move all global calculated and restricted key figures to local as to analyze any filters that can be removed and moved to the global definition in a query. Then you can change the calculated key figure and go back to utilizing the global calculated key figure if desired
9. If Alternative UOM solution is used, turn off query cache.
10. Set read mode of query based on static or dynamic. Reading data during navigation minimizes the impact on the R/3 database and application server resources because only data that the user requires will be retrieved. For queries involving large hierarchies with many nodes, it would be wise to select Read data during navigation and when expanding the hierarchy option to avoid reading data for the hierarchy nodes that are not expanded. Reserve the Read all data mode for special queriesu2014for instance, when a majority of the users need a given query to slice and dice against all dimensions, or when the data is needed for data mining. This mode places heavy demand on database and memory resources and might impact other SAP BW processes and tasks.
11. Turn off formatting and results rows to minimize Frontend time whenever possible.
12. Check for nested hierarchies. Always a bad idea.
13. If "Display as hierarchy" is being used, look for other options to remove it to increase performance.
14. Use Constant Selection instead of SUMCT and SUMGT within formulas.
15. Do review of order of restrictions in formulas. Do as many restrictions as you can before
calculations. Try to avoid calculations before restrictions.
17. Turn off warning messages on queries.
18. Check to see if performance improves by removing text display (Use ABAPer to test and validate that this ensures better code).
19. Check to see where currency conversions are happening if they are used.
20. Check aggregation and exception aggregation on calculated key figures. Before aggregation is generally slower and should not be used unless explicitly needed.
21. Avoid Cell Editor use if at all possible.
22. Make sure queries are regenerated in production using RSRT after changes to statistics, consistency changes, or aggregates.
23. Within the free characteristics, filter on the least granular objects first and make sure those come first in the order.

System/Query Performance: What to look for in these tcodes

Hi
I have been researching on system/query performance in general in the BW environment.
I have seen tcodes such as
ST02 :Buffer/Table analysis
ST03 :System workload
ST03N:
ST04 : Database monitor
ST05 : SQL trace
ST06 :
ST66:
ST21:
ST22:
SE30: ABAP runtime analysis
RSRT:Query performance
RSRV: Analysis and repair of BW objects
For example, Note 948066 provides descriptions of these tcodes but what I am not getting are thresholds and their implications. e.g. ST02 gave tune summary screen with several rows and columns (?not sure what they are called) with several numerical values.
Is there some information on these rows/columns such as the typical range for each of these columns and rows; and the acceptable figures, and which numbers under which columns suggest what problems?
Basically some type of a metric for each of these indicators provided by these performance tcodes.
Something similar to when you are using an Operating system, and the CPU performance is consistently over 70% which may suggest the need to upgrade CPU; while over 90% suggests your system is about to crush, etc.
I will appreciate some guidelines on the use of these tcodes and from your personal experience, which indicators you pay attention to under each tcode and why?
Thanks

hi Amanda,
i forgot something .... SAP provides Early Watch report, if you have solution manager, you can generate it by yourself .... in Early Watch report there will be red, yellow and green light for parameters
http://help.sap.com/saphelp_sm40/helpdata/EN/a4/a0cd16e4bcb3418efdaf4a07f4cdf8/frameset.htm
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0f35bf3-14a3-2910-abb8-89a7a294cedb
EarlyWatch focuses on the following aspects:
·        Server analysis
·        Database analysis
·        Configuration analysis
·        Application analysis
·        Workload analysis
EarlyWatch Alert a free part of your standard maintenance contract with SAP is a preventive service designed to help you take rapid action before potential problems can lead to actual downtime. In addition to EarlyWatch Alert, you can also decide to have an EarlyWatch session for a more detailed analysis of your system.
ask your basis for Early Watch sample report, the parameters in Early Watch should cover what you are looking for with red, yellow, green indicators
Understanding Your EarlyWatch Alert Reports
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4b88cb90-0201-0010-5bb1-a65272a329bf
hope this helps.

Oracle Query Performance While calling a function in a View

Hi,
We have a performance issue in one of our Oracle queries.
Here is the scenario
We use a hard coded value (which is the maximum value from a table) in couple of DECODE statements in our query. We would like to remove this hard coded value from the query. So we wrote a function which will return a maximum value from the table. Now when we execute the query after replacing the hard coded value with the function, this function is called four times which hampers the query performance.
Pl find below the DECODE statements in the query. This query is part of a main VIEW.
Using Hardcoded values
=================
DECODE(pro_risk_weighted_ctrl_scr, 10, 9.9, pro_risk_weighted_ctrl_scr)
DECODE(pro_risk_score, 46619750, 46619749, pro_risk_score)
Using Functions
============
DECODE (pro_risk_weighted_ctrl_scr, rprowbproc.fn_max_rcsa_range_values ('CSR'), rprowbproc.fn_max_rcsa_range_values('CSR')- 0.1, pro_risk_weighted_ctrl_scr)
DECODE (pro_risk_score, rprowbproc.fn_max_rcsa_range_values ('RSR'), rprowbproc.fn_max_rcsa_range_values ('RSR') - 1, pro_risk_score)
Can any one suggest a way to improve the performance of the query.
Thanks & Regards,
Raji

drop table max_demo;
create table max_demo
(rcsa   varchar2(10)
,value number);
insert into max_demo
select case when mod(rownum,2) = 0
            then 'CSR'
            else 'RSR'
       end
,      rownum
from   dual
connect by rownum <= 10000;
create or replace function f_max (
i_rcsa    in   max_demo.rcsa%TYPE
return number
as
l_max number;
begin
   select max(value)
   into   l_max
   from   max_demo
   where rcsa = i_rcsa;
   return l_max;
end;
-- slooooooooooooowwwwww
select m.*
,      f_max(rcsa)
,      decode(rcsa,'CSR',decode(value,f_max('CSR'),'Y - max is '||f_max('CSR'),'N - max is '||f_max('CSR'))) is_max_csr
,      decode(rcsa,'RSR',decode(value,f_max('RSR'),'Y - max is '||f_max('RSR'),'N - max is '||f_max('RSR'))) is_max_rsr
from   max_demo m
order by value desc;
-- ssllooooowwwww
with subq_max as
     (select f_max('CSR') max_csr,
             f_max('RSR') max_rsr
      from   dual)
select m.*
,      decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
,      decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
,      decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from   max_demo m
,      subq_max s
order by value desc;
-- faster
with subq_max as
     (select /*+materialize */
             f_max('CSR') max_csr,
             f_max('RSR') max_rsr
      from   dual)
select m.*
,      decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
,      decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
,      decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from   max_demo m
,      subq_max s
order by value desc;
-- faster
with subq_max as
     (select f_max('CSR') max_csr,
             f_max('RSR') max_rsr,
             rownum
      from   dual)
select m.*
,      decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
,      decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
,      decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from   max_demo m
,      subq_max s
order by value desc;
-- sloooooowwwwww
select m.*
,      decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
,      decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
,      decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from   max_demo m
,      (select /*+ materialize */
             f_max('CSR') max_csr,
             f_max('RSR') max_rsr
      from   dual) s
order by value desc;
-- faster
select m.*
,      decode(rcsa,'CSR',s.max_csr,'RSR',s.max_rsr) max
,      decode(rcsa,'CSR',decode(value,s.max_csr,'Y - max is '||s.max_csr,'N - max is '||s.max_csr)) is_max_csr
,      decode(rcsa,'RSR',decode(value,s.max_rsr,'Y - max is '||s.max_rsr,'N - max is '||s.max_rsr)) is_max_rsr
from   max_demo m
,      (select f_max('CSR') max_csr,
               f_max('RSR') max_rsr,
               rownum
        from   dual) s
order by value desc;

Speed up table query performance

Similar Messages

Maybe you are looking for