View Query Performance

Help please, I have the following view:
CREATE OR REPLACE VIEW OBRA.ASSESSMENTS_VIEW
AS
SELECT c.last_name, c.first_name, c.clients_rec, c.social_security_number, c.date_of_birth, c.gender,
c.tracking, c.archived, c.thirty_month_rule, ass.cli_clients_rec, ass.assessments_rec,
ass.transfer_trauma, c.termination_types_rec, c.termination_date, ass.assessment_type,
ass.dia_diagnoses_rec, ass.mental_health_services, ass.date_received, ass.evaluation_date,
ass.re_evaluation_date, ass.age_agencies_rec, ass.det_determinations_rec, ass.date_notified,
ass.date_authorized, ass.method_of_notifications_rec, ass.notified_persons_rec,
ass.date_notified_obra, ass.rev_reviewers_rec, ass.rec_recommendations_rec, ass.notes,
ass.transfer_trauma_notes, ass.diagnosis_axis_1, ass.diagnosis_axis_2, ass.diagnosis_axis_3,
ass.referral_date, ass.fac_facilities_rec_recommed, ass.fac_facilities_rec,
ass.referral_criteria_1, ass.referral_criteria_2, ass.referral_criteria_3,
ass.referral_criteria_4, ass.referral_criteria_5, ass.referral_criteria_6,
ass.created_by, ass.created_on, ass.modified_by, ass.modified_on
FROM OBRA.clients c, OBRA.assessments ass
WHERE ass.cli_clients_rec (+) = c.clients_rec;
I use an 8i database and this query is generated from forms 6.0
I have an order by in my form:
last_name, first_name, created_on desc
I have the following indexes:
CLIENTS: (last_name, first_name, clients_rec)
ASSESSMENTS: (cli_clients_rec), (created_on desc, cli_clients_rec) and (created_on desc, assessments_rec)
I have tried to use optimizer hints: first_rows, use_nl(assessemnts), use_nl(clients), index (clients last_name_first...), all indexes
I have used explain plan and I always get the same result:
SORT ORDER BY
MERGE JOIN OUTER
SORT JOIN
TABLE ACCESS FULL CLIENTS
SORT JOIN
TABLE ACCESS FULL ASSESSMENTS
The query takes 20 minutes if no sort criteria is entered in the form.
I have a master detail form (same tables) to auto query all records with same order by takes only 2 seconds. I use optimizer hints of clients last_name index and assessments created_on assessments_rec
Sorry for the long explanation
Any suggestions
I have no DBA knowledge.
Dave
null

After reviewing my information I neglected to put in important information. I am doing spatial queries against a view. I will repost to the spatial forum.
Sorry for the inconvenience.
Thanks,
John

Similar Messages

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;

Improve Performance on Inline view Query

All,
I have a unique situation where I have to limit the number of rows based on group. so I created an Inline view and applied a limit on it.
ex:
SELECT col_A, col_B FROM ( SELECT col_a, count(*) FROM tab_a WHERE col_a = 'XXX' GROUP BY col_a) ROWNUM <-10.
but this design was rejected, because it seems to have a great impact on performance due to inline view.
Also I cant set a rowlimit directly on the query because GROUP BY clause is used in the select.
When the rownum is directly applied in the WHERE, first it limits the rows and then it makes a GROUP, so when user asks to retrieve 10 records, it may show less than 10 rows because of the grouping.
please help to find a alternative solution which helps to get the expected result set and same time without loosing performance

but this design was rejected, because it seems to have a great impact on performance due to inline view.What proof was offered that this query performed badly. There is nothing inherently non-performant about in-line views. I would demand to see some evidence that this query uses an unreasonable amount of system resource.
However, you could try this:
SELECT t.col1, avg(t.col2)
FROM   t1 t
WHERE t.col1 IN ( SELECT DISTINCT x.col1
                   FROM   t1 x
                   WHERE col3 = 'XXX'
                   AND    rownum <=10 )
GROUP BY t.col1
/I assume your example is not derived from your real code (otherwise the WHERE clause would restrict the inline query to one returned row - problem solved!)
Cheers, APC

Query performance.

Hi
I have created a procedure that accepts two bind variables from a report. The user will select one or the other, both or neither of the variables. To return the appropriate results i have created a view with the entire result set and in the procedure are a number of if statements that determine what to place in the where clause selecting from the view, depending on what variables populated.
My concern is that the query that generates the view includes several joins and in total outputs around 150,000 records and seems to be rather slow to run.
Would you recommend another solution such as placing the query in the procedure itself repeated for every if statement?
Or should I work on the query performance?
What would be the most efficient solution for my problem?
Any advice would be greatly appreciated.
Thanks

[url http://forums.oracle.com/forums/thread.jspa?threadID=501834&tstart=0]When your query takes too long

How to improve the query performance in to report level and designer level

How to improve the query performance in to report level and designer level......?
Plz let me know the detail view......

first its all based on the design of the database, universe and the report.
at the universe Level, you have to check your Contexts very well to get the optimal performance of the universe and also your joins, keep your joins with key fields, will give you the best performance.
at the report level, try to make the reports dynamic as much as you can, (Parameters) and so on.
and when you create a paremeter try to get it match with the key fields in the database.
good luck
Amr

Spatial vs. materialized views/query rewrite

Dear all,
we are trying to use Spatial (Locator) functionality together with performance optimization using materialized views and query rewrite, and it does not seem to work. Does anybody has experience with this?
The problem in more detail:
* There is a spatial attribut (vom Typ GEOMETRY) in our table;
* we define a materialized view on that table;
* we run a query that could be better answered using the materialized view with query rewrite;
*the optimizer does not choose the plan using the materialized view, query rewrite does not take place;
This happenes, even if neither the materialized view, nor the query contains the spatial attribut.
The explanation given by the procedure DBMS_MVIEW.Explain_Rewrite is:
"QSM-01064 query has a fixed table or view Cause: Query
rewrite is not allowed if query references any fixed tables or views"
We are using Oracle 9R2, Enterprise Edition, with locator. Nevertheless, it would also be interesting, if there is any improvement in 10g?
A more complicated task, using materialized views to optimize spatial operations (e.g., sdo_relate) would also be very interesting, as spatial joins are very expensive operations.
Thanks in advance for any comments, ideas!
Cheers,
Gergely Lukacs

Hi Dan,
thanks for your rapid response!
A simple example is:
alter session set query_rewrite_integrity=trusted;
alter session set query_rewrite_enabled=true;
set serveroutput on;
/* Creating testtable */
CREATE TABLE TESTTABLE (
KEY1 NUMBER (4) NOT NULL,
KEY2 NUMBER (8) NOT NULL,
KEY3 NUMBER (14) NOT NULL,
NAME VARCHAR2 (255),
X NUMBER (9,2),
Y NUMBER (9,2),
ATTR1 VARCHAR2 (2),
ATTR2 VARCHAR2 (30),
ATTR3 VARCHAR2 (80),
ATTR4 NUMBER (7),
ATTR5 NUMBER (4),
ATTR6 NUMBER (5),
ATTR7 VARCHAR2 (40),
ATTR8 VARCHAR2 (40),
CONSTRAINT TESTTABLE_PK
PRIMARY KEY ( KEY1, KEY2, KEY3 ));
/* Creating materialized view */
CREATE MATERIALIZED VIEW TESTTABLE_MV
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS SELECT DISTINCT ATTR7, ATTR8
FROM TESTTABLE;
/* Creating statistics, just to make sure */
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE', cascade=>TRUE);
execute dbms_stats.gather_table_stats(ownname=> 'TESTSCHEMA', tabname=> 'TESTTABLE_MV', cascade=>TRUE);
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The message you get is:
QSM-01009 materialized view, string, matched query text
Cause: The query was rewritten using a materialized view, because query text matched the materialized view text.
Action: No action required.
i.e. query rewrite works!
/* Adding geometry column to the testtable -- not to the materialized view, and not to the query! */
ALTER TABLE TESTTABLE
ADD GEOMETRYATTR mdsys.sdo_geometry;
/* Explain rewrite procedure */
DECLARE
Rewrite_Array SYS.RewriteArrayType := SYS.RewriteArrayType();
querytxt VARCHAR2(1500) :=
'SELECT COUNT(*) FROM (
SELECT DISTINCT
ATTR8 FROM
TESTTABLE
i NUMBER;
BEGIN
DBMS_MVIEW.Explain_Rewrite(querytxt, 'TESTTABLE_MV', Rewrite_Array);
FOR i IN 1..Rewrite_Array.count
LOOP
DBMS_OUTPUT.PUT_LINE(Rewrite_Array(i).message);
END LOOP;
END;
The messages you get are:
QSM-01064 query has a fixed table or view
Cause: Query rewrite is not allowed if query references any fixed tables or views.
Action: No action required.
QSM-01019 no suitable materialized view found to rewrite this query
Cause: There doesn't exist any materialized view that can be used to rewrite this query.
Action: Consider creating a new materialized view.
i.e. query rewrite does not work!
If this works, the next issue is to use materialized views for optimizing spatial operations, e.g., a spatial join. I can supply you with an example, if necessary (only makes sense, I think, after the first problem is solved).
Thanks in advance for any ideas, comments!
Cheers,
Gergely

Creating a Hierarchy Viewer query

Hello,
I'm having huge difficulties creating a Hierarchy Viewer Query. I've looked through the source code contained withing the demo, but it seems to require great knowledge regarding the component. I'm using a three-node model, each node grouped within it's parent.
So I created a custom View to be used as a result list for the query and this part is working just fine. I can pick the unique ID for the node I want from the search results when the user selects one, but I don't know how I can make that specific node my "anchor", my "current node", after that.
Since I'm looking for a specific "contact_id" selected from the search results, I think the correct way of doing it is finding it's node on the TreeModel, and then setting it as my current anchor.
Please, any tips, directions or suggestions on how can I go about doing this?
Thanks!!

Hi!
Thanks for the attention, but I've been through all the basic stuff. The HV documentation only teaches the most primitive part of it. I searched all blogs related to HV, all articles I could find, I've meddled with the demo source code and all I can think of, but I couldn't find anyone who would give much insight on the mechanics of the component or how to build a really powerful search engine for it.
As a sugestion for the developer team, it would be great if the query for this component allowed us to specify actions to be performed on all levels of the tree, instead of only the root node, since most of the time people use HV as a multi-root tree.

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>

Impact of real time cube on query performance and OLAP cache

Hi:
We have actual and plan cubes both setup as real time cubes (only plan cube is being planned against, not actual cube) and both cubes are compressed once a day.
We are planning on implementing BIA accelerator and have questions related to query performance optimization:
1/ Is there are any query performance benefits in changing the actual cube to be a basic cube (using program SAP_CONVERT_NORMAL_TRANS) if the F table is fully compressed
2/ Can OLAP cache be leveraged for the queries run against the real time cubes e.g. actual cubes
3/ What is the impact on BIA of having the actual cube as real time (whetehr or not there is data being loaded/planned during the day in that cube)
Thank you in advance,
Catherine

1) Is there are any query performance benefits in changing the actual cube to be a basic cube (using program SAP_CONVERT_NORMAL_TRANS) if the F table is fully compressed
From the performance point of view, tha actual cubes i.e std cubes are relatively better.
2) Yes OLAP cache can be leveraged for bringing up the plan query but all the calculations are done in the planning buffer.
3) Not sure.

Query Performance - Analyzer vs WAD

Hi experts,
We've been having user complaints regarding performance in BW. The queries are accessed using Analyzer/Excel interface. As a test I've tried comparing opening the query through Analyzer and then through Web Application Designer. With Excel my load from S900 was taking almost 2 minutes. With the Web Browser my initial load was just 30 seconds! This is great however, this number is deceiving because it's only showing me a subset of the data; the first 25% of the data is shown and if I want to view more I have to click 'next page' (called 'Next Rows' on screen). So the subsequent set of records (say 25-50%) then takes another 30 seconds. So if you hit Next page each time you will end up getting 4 loads of 30 seconds each thus the same performance as Excel (2 minutes total wait), although maybe less stressful to sit and watch.
QUESTION:
It seems like the subsequent loads are taking 30 seconds because they are re-querying the back-end data (the S900 Cube) instead of re-querying the resultset. Is that true? Do you see my problem? Is there a better way to do this to improve performance?
Thanks for any help you can provide!
-Patrick

hi,
dealing with query performance, please check following, hope you get ideas ....
Prakash's weblog on this topic..
/people/prakash.darji/blog/2006/01/27/query-creation-checklist
/people/prakash.darji/blog/2006/01/26/query-optimization
oss note
557870 'FAQ BW Query Performance'
and 567746 'Composite note BW 3.x performance Query and Web'
some docs
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3f66ba90-0201-0010-ac8d-b61d8fd9abe9
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/c8c4d794-0501-0010-a693-918a17e663cc

Display Query performance in WAD

All
Is there a way to display the query performance statistics in the report result for a web report created in the WAD (is there a standard template/web object?
Eg display number of records read and time taken for query result.
I am sure I have seen this in SAP demos but don't know if it is a standard content offering
Thanks
Gidon

Thanks, very helpfull.
I´m using BI 7.0
However, when I do as you suggested, I still get the query name, not the query view name.
The query view should be selected dynamically from the view that is displayed at that moment.
Also, can you incorporate saved views from the Bex Portfolio and display their names?
Edited by: Max Cohen on Sep 11, 2008 5:16 PM

Query Performance on ODS

Hi all,
        I have an ODS with around 23000 records. The ODS has around 20 fields in it (3 key fields). I built a query on the ODS. The User only inputs Cost center Hierarchy. The report does not have any calculations. It is a direct view of the fields, but the report is taking a long time to run if I select first 2nd or 3rd level of the hierarchy as the starting point. If I select the 5th or 6th level for the hierarchy then the query output is fast. With just 23000 records on the ODS I thought query performance should be fast for any level of hierarchy.
I even created an index on Costcenter, even then no improvement in performance. Is there any way to achieve faster query performance on the ODS.
Thanks,
Prabhu.

Technical content cubes[ if installed ] gives more generic statistics of query run time...
RSRT option mentioned by Sudheer is more targeted approach.
The same RSRT can be help full to do the following....[ from help.sap]
Definition
The read mode determines how the OLAP processor gets data during navigation. You can set the mode in Customizing for an InfoProvider and in the Query Monitor for a query.
Use
The following types are supported:
       1.      Query to be read when you navigate or expand hierarchies (H)
The amount of data transferred from the database to the OLAP processor is the smallest in this mode. However, it has the highest number of read processes.
In the following mode Query to read data during navigation, the data for the fully expanded hierarchy is requested for a hierarchy drilldown. In the Query to be read when you navigate or expand hierarchies mode, the data across the hierarchy is aggregated and transferred to the OLAP processor on the hierarchy level that is the lowest in the start list. When expanding a hierarchy node, the children of this node are then read.
You can improve the performance of queries with large presentation hierarchies by creating aggregates on a middle hierarchy level that is greater or the same as the hierarchy start level.
       2.      Query to read data during navigation (X)
The OLAP processor only requests data that is needed for each navigational status of the query in the Business Explorer. The data that is needed is read for each step in the navigation.
In contrast to the Query to be read when you navigate or expand hierarchies mode, presentation hierarchies are always imported completely on a leaf level here.
The OLAP processor can read data from the main memory when the nodes are expanded.
When accessing the database, the best aggregate table is used and, if possible, data is aggregated in the database.
       3.      Query to read all data at once (A)
There is only one read process in this mode. When you execute the query in the Business Explorer, all data in the main memory area of the OLAP processor that is needed for all possible navigational steps of this query is read. During navigation, all new navigational states are aggregated and calculated from the data from the main memory.
The read mode Query to be read when you navigate or expand hierarchies significantly improves performance in almost all cases compared to the other two modes. The reason for this is that only the data the user wants to see is requested in this mode.
Compared to the Query to be read when you navigate or expand hierarchies, the setting Query to read data during navigation only effects performance for queries with presentation hierarchies.
Unlike the other two modes, the setting Query to Read All Data At Once also has an effect on performance for queries with free characteristics. The OLAP processor aggregates on the corresponding query view. For this reason, the aggregation concept, that is, working with pre-aggregated data, is least supported in the Query to read all data at once mode.
We recommend you choose the mode Query to be read when you navigate or expand hierarchies.
Only choose a different read mode in exceptional circumstances. The read mode Query to read all data at once may be of use in the following cases:
§         The InfoProvider does not support selection. The OLAP processor reads significantly more data than the query needs anyway.
§         A user exit is active in a query. This prevents data from already being aggregated in the database.

Easiest way to monitor query performance?

Hi,
What is the easiest method to track query performance? I need information about data collection from DataSource, data processing speed and front-end performance.
I would like to compare the results when:
1. the query is executed directly from BEx/WAD and
2. the query accessed from portal.
So basically I'm looking for a tool-set to monitor reporting performance at query level, per user.
-Miikka

It really depends on how indepth you want to go with your monitoring. You could issue the show interface command and view the details there. You could also view the top talkers on the ASDM dashboard. And another option is to use Netflow.
Outside of that you would need to get either get Cisco Prime or another 3rd party monitoring software.
Please remember to rate helpful posts and select a correct answer

Physical partitioning query performance wore than without

Hello experts,
I have copied InfoCube 0COPC_C04 to ZCPOC_C06 with a test-query and took over data from 0COPC_C04 to test the functionality of Repartitioning (~ 4 million records)
I did Repartitioning following instructions from note 1008833 for 0FISCPER (I used se38 RSDU_SET_FV_TO_FIX_VALUE to set 0FISCVARNT to constant) - starting-point is 001.2000 - end-point is 016.2010
Indexes and Statistcs are re-created.
We have Oracle 10.2.0.2.0 and SAPKW70022 on BW 700
So - from my point of view everything is fine - BUT: Queryperformance is worst than before - shown in rsrv.
Variable in Query is over 0FISCYEAR and 0FISCPER3 and NOT over 0FISCPER (a querytest with 0FISCPER brought the same bad performance result).
Even I read, that with physical partitioning the query reads PARALLEL --- I can not see any parallel things in sm50 / sm66 - I have excpected to see parallel readings due to my query - I asked for results from 001.2006 - 12.2010 - and 13 partions were created (related to se14 ).
What might be the problem?
Thanks for your answer,
Thomas
Edited by: Thomas Liebschner on Jan 4, 2011 3:28 PM

#1171650 is already implemented (since 14.12.2010) --- I asked my collegaue from Basis-Team to send me the report.
> I read parallel-queryexcution in the SAP Press Galileo Press Book "SAP BW Peformanceoptimierung" written by Thomas Schröder (ISBN: 3-89842-718-8), Page 376. If you like, I can send this page as pdf to your mail stored in your business card.
Would be interesting to see that excerpt, yes.
> What I missed was to compress the F-Table.
>
> I'm wondering, that:
> 1. After Compressing 0COPC_C04 with 8 million records gave a dramatically improvement of query-performance. No partitioning.
Sure, usually a lot less data needs to be read now.
> 2. After a new Full-load from 0COPC_C04 to ZCOPC_C06 with rebuilding indices and statistics I got similar query-performance compared to 1
Also easy to understand.
The F-Facttable contains data per load. So data concerning the same business items will be in that table multiple times and need to be aggregated on-the-fly during query execution.
The E-Facttable in contrast just contains one entry per business item. Which is the same situation you'll find when you just have one single data load request.
> 3. If I compress ZCOPC_C06, then query-performance drops dramatically down (needs double time, if I use 0FISCPER, needs 8 times more in query with 0FISCYEAR and 0FISCPER3)
>
> additional information: I have merged partitions from ZCOPC_C06 to one partition --> checked by se14 /BIC/FZCOPC_C06 -- storage parameters
Hmm... ok, here we would really need to see what Oracle does with your Query and the partitioning scheme then.
What seems obvious is that as soon as you have just one partition, then there is no way for Oracle to split up work and leave uninteresting data aside (partition-pruning),
> Conclusion: it seems for me, that compression is enough - partitioning has no advantage in that dedicated scenario.
> Do I think right?
I think that compression is a must-do in 99% of all cases for SAP BI and that the partitioning of the E-Facttable should be reviewed on your system.
Up to here there is too little information available to tell whether or not it could benefit your query execution time.
Another aspect you might consider with partitioning the E-facttable is your data retention policy.
If you're about to throw away your data on, say, a yearly basis, then having the table partitioned that way can provide huge benefits.
My personal view to this is: you already payed for the most expensive and feature-rich database engine available for SAP BI - so why not go and exploit these features where possible?
best regards
Lars

DBlink Query performance

Curently we are extracting data from two Oracle apps instance using view i.e. the view is created in one oracle apps instance and we access the view in DWH instance using db_ink.
we execute the following query on instance WH.
select * from Testview@oa
Following is the testview query in oa instance
select a.c1,b.c2,c.c3,d.c4
from t1@pl a,t2 b,t3@pl c,t4@pl d
where ....
For some of views the performance is very bad, its takes 2 hours to read?
Is there any better alternative to extract data
Thanks
Rakesh

We are on high speed network and data base is Oracle
10G rel2.Still having us pull teeth, I see.
I guess information about operating system (including edition and patch level), database version/patch level and actual network speed is confidential. Not surprising, even if that level of information is fundamental to performance issues.
>
Will it help if we bring the remote data locally and
then perform join instead of joining over database
link?Let's try an analogy:
You have two swimming pools joined by a garden hose. One pool is filled with blue water, the other with pink water. You are at the edge of the blue pool with a 10L scoop. You want to get 50 liters of water from both pools. What are some of the ways you could do that?
While you are thinking about the options, realize as well, that ... if you choose, you could have a hundred liter tank (materialized view) installed in the blue pool and set up a separate pump to fill that overnight. Or get a bigger hose. Or ...

View Query Performance

Similar Messages

Maybe you are looking for