Poor query performance only with migrated 7.0 queries
Dear Team,
We are facing a serious query performance issue after migration of queries from 3.5 to 7.0.
I executed a query in 3.5 with some variable values which takes fraction of seconds to display the output. But the same migrated query with same variable entries is taking very long time and giving time out error.
We are not using any aggregates in the InfoProvider level.
Both the queries are based on same cube but 3.5 query is taking less time and 7.0 is taking very long time if more selection is done.
I checked for notes where I didn't find specific note for this particular scenario. I found notes only for general query performance improvement.
I want to know the reason why only in 7.0 the same 3.5 query is taking a long time and giving time out error. And please suggest some notes or suggestions related to this scenario.
Regards,
Chan
Hi,
Queries in BI 7.0 are almost the same as queries in 3.x format.
inorder to check if the problem is in the query runtime (database time) or JAVA runtime (probably rendering) you should try running it from RSRT once in JAVA web and once in ABAP web.
if the problem is only with JAVA web, than u should take the URL and add &profiling=X at the end.
after the query execution u can use statistics which will be shown at the top of the page.
With my experience, the problem is in the rendering phase of the query. Things that could be done is to limit the number of rows shown at each page, that could be done by changing the 0ANALYSIS web template - it's one of the web template parameters.
Tomer.
Similar Messages
-
How to create a transport request with query and only with its structure.
HI guru,
how to create a transport request with query and only with its structure.transport request should not include any other query items like ( variables, conditions...etc)
thanks in advance.
venkataHi,
Goto RSA1 and then Transport Connection -> In SAP Transports select Object Types-> Query Elements -> Then select Query->Give Technical name of the query and then select for transfer. In the right side you can choose the components which you wanted to transport.
Regards,
anil -
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> -
Poor query performance in Prod.
I am facing lots of issues in my queries.
The query is working fine in Dev. but after i transported it to Prod. the query is taking too much time to retreive the result.
Why i am facing this issue.
How can i do the performance tuning for the query.?
The query is built on multiprovider and it is also jumping to the ODS for ODS query.
But the query performance is really low and poor in Production.
And to surprise the query is wroking perfectly and faster in Dev.
What can be the suggestion.
Please send documents for performnace tuning, notes number... etc.Are datavolumes huge in Prod Box...dat may be cause 4 d slow runtimes.
<b>Look at below performance improving techs</b>
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cbd2d390-0201-0010-8eab-a8a9269a23c2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/aec09790-0201-0010-8eb9-e82df5763455
Business Intelligence Performance Tuning [original link is broken]
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
Note 565725 - Optimizing the performance of ODS objects -
Poor query performance with BETWEEN
I'm using Oracle Reports 6i.
I needed to add Date range parameters (Starting and Ending dates) to a report. I used lexicals in the Where condition to handle the logic.
If no dates given,
Start_LEX := '/**/' and
End_LEX := '/**/'
If Start_date given,
Start_LEX := 'AND t1.date >= :Start_date'
If End_date given,
End_LEX := 'AND t1.date <= :End_date'
When I run the report with no dates or only one of the dates, it finishes in 3 to 8 seconds.
But when I supply both dates, it takes > 5 minutes.
So I did the following
If both dates are given and Start_date = End date,
Start_LEX := 'AND t1.date = :Start_date'
End_LEX := '/**/'
This got the response back to the 3 - 8 second range.
I then tried this
if both dates are given and Start_date != End date,
Start_LEX := 'AND t1.date BETWEEN :Start_date AND :End_date'
End_LEX := '/**/'
This didn't help. The response was still in the 5+ minutes range.
If I run the query outside of Oracle Reports, in PL/SQL Developer or SQLplus, it returns the same data in 3 - 8 seconds in all cases.
Does anyone know what is going on in Oracle Reports when a date is compared with two values either separately or with a BETWEEN? Why does the query take approx. 60 times as long to execute?Hi,
Observe access plan first by using BETWEEN as well as using <= >=.
Try to impose logic of using NVL while forming lexical parameters.
Adinath Kamode -
Query performance difference with same script in two servers
Dear all,
I have problem with an INSERT Procedure. I have 2 servers, say Server A and Server B, In Server A the query execution will be finished in 4 minutes where in the Server B the same Query its taking more than 2 hours.
If I look into the execution plan in both servers, it looks different.
Both have the Default Parallelism settings.
Cost Threshold for Parallelism : 5
Locks : 0
Max Degree of Parallelism : 0
Query Wait : -1
What causing to slow down the process? Is the parallelism slowing down the process?
When I look into the SERVER A's active running processes in management studio, I found that there are 8 INSERT Queries running with only 2 RUNNABLE and 6 SUSPENDED. Anything is getting locked out or Waiting?
Please help and suggest my a solution for it. Thanks in advance.
Regards,
kranthi kumar G.Thanks Tony for your reply. Here are my answers.
Are we talking a large amount of inserts?
YES
What is the autogrowth settings for the database files on the two Servers?
Autogrowth by 10%
The Server you are having an issue with, are the any triggers on the Tables?
No.
Is there a background or other trace running on the slow Server that could be impacting performance?
Yes, we are running a monitoring tool to check the performance of the load.
Is there another database on the slow Server causing issues?
No.
This could be a hardware issue; have you use perfmon to see if there are any disk queues?
We will check with our DBA on this.
What is the Raid Configuration? Are the files on a single spindle? If so what is the fragmentation state of any single spindle volume?
There is no Rain Configuration. Its a Windows Azure A7.
Are you automatically updating statistics on the slow Database?
Yes.
Is the Anti Virus Software on the Slow server scanning the data files?
Yes, but not on the database level.
Regards,
kranthi. -
Poor query performance in WebI on top of BEx queries
Hello,
We are using Web Inteliigence i BO 3.1 (SP0) to report on BEx queries (BW 7.0).
We experience however that reporting is much quicker for the same set of data when using BEx Analyzer than when using WebI. In BEx it is acceptable, but in WebI it's not.
How can we optimize the performance in this scenario? What tricks are there?
The amount of data is not huge (max 500 000 records in the cube)
BR,
FredrikHi,
Dennis is right. But if you need to upgrade (and you do) than maybe going to the latest SP is better. It is SP4. With SP3 the WebI Option "Query Striping" has been introduced which brings Performance as well.
Also check
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0bf4691-cdce-2d10-45ba-d1ff39408eb4
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/109b7d63-7cab-2d10-2fbc-be5c61dcf110
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/006b1374-8f91-2d10-fe9c-f9fa12e2f595
Regards
-Seb. -
Poor query performance when using date range
Hello,
We have the following ABAP code:
select sptag werks vkorg vtweg spart kunnr matnr periv volum_01 voleh
into table tab_aux
from s911
where vkorg in c_vkorg
and werks in c_werks
and sptag in c_sptag
and matnr in c_matnr
that is translated to the following Oracle query:
SELECT
"SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN 20101201 AND 20101231 AND "MATNR" BETWEEN 000000000100000000 AND 000000000999999999;
Because the field SPTAG is not enclosed by apostropher, the oracle query has a very bad performance. Below the execution plans and its costs, with and without the apostrophes. Please help me understanding why I am getting this behaviour.
##WITH APOSTROPHES
SQL> EXPLAIN PLAN FOR
2 SELECT
3 "SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN '20101201' AND '20101231' AND "MATNR" BETWEEN '000000000100000000' AND '000000000999999999';
Explained.
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Id
Operation
Name
Rows
Bytes
Cost (%CPU)
0
SELECT STATEMENT
932
62444
150 (1)
1
TABLE ACCESS BY INDEX ROWID
S911
932
62444
149 (0)
2
INDEX RANGE SCAN
S911~VAC
55M
5 (0)
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("VKORG"='D004' AND "SPTAG">='20101201' AND
"SPTAG"<='20101231')
2 - access("MANDT"='003' AND "MATNR">='000000000100000000' AND
"MATNR"<='000000000999999999')
##WITHOUT APOSTROPHES
SQL> EXPLAIN PLAN FOR
2 SELECT
3 "SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN 20101201 AND 20101231 AND "MATNR" BETWEEN '000000000100000000' AND '000000000999999999';
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
Explained.
SQL>
PLAN_TABLE_OUTPUT
Id
Operation
Name
Rows
Bytes
Cost (%CPU)
0
SELECT STATEMENT
2334
152K
150 (1)
1
TABLE ACCESS BY INDEX ROWID
S911
2334
152K
149 (0)
2
INDEX RANGE SCAN
S911~VAC
55M
5 (0)
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("VKORG"='D004' AND TO_NUMBER("SPTAG")>=20101201 AND
TO_NUMBER("SPTAG")<=20101231)
2 - access("MANDT"='003' AND "MATNR">='000000000100000000' AND
"MATNR"<='000000000999999999')
Best Regards,
Daniel G.Volker,
Answering your question, regarding the explain from ST05. As a quick work around I created an index (S911~Z9), but still I'd like to solve this issue without this extra index, as primary index would work ok, as long as date was correctly sent to oracle as string and not as number.
SELECT
"SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" ,
"PERIV" , "VOLUM_01" , "VOLEH"
FROM
"S911"
WHERE
"MANDT" = :A0 AND "VKORG" = :A1 AND "SPTAG" BETWEEN :A2 AND :A3 AND "MATNR"
BETWEEN :A4 AND :A5
A0(CH,3) = 003
A1(CH,4) = D004
A2(NU,8) = 20101201 (NU means number correct?)
A3(NU,8) = 20101231
A4(CH,18) = 000000000100000000
A5(CH,18) = 000000000999999999
SELECT STATEMENT ( Estimated Costs = 10 , Estimated #Rows = 6 )
5 3 FILTER
Filter Predicates
5 2 TABLE ACCESS BY INDEX ROWID S911
( Estim. Costs = 10 , Estim. #Rows = 6 )
Estim. CPU-Costs = 247.566 Estim. IO-Costs = 10
1 INDEX RANGE SCAN S911~Z9
( Estim. Costs = 7 , Estim. #Rows = 20 )
Search Columns: 4
Estim. CPU-Costs = 223.202 Estim. IO-Costs = 7
Access Predicates Filter Predicates
The table originally includes the following indexes:
###S911~0
MANDT
SSOUR
VRSIO
SPMON
SPTAG
SPWOC
SPBUP
VKORG
VTWEG
SPART
VKBUR
VKGRP
KONDA
KUNNR
WERKS
MATNR
###S911~VAC
MANDT
MATNR
Number of entries: 61.303.517
DISTINCT VKORG: 65
DISTINCT SPTAG: 3107
DISTINCT MATNR: 2939 -
Zen Micro: Poor Battery Performance Even with Firmware Upgr
The Zen Micro's battery life is advertised to last up to 2 hours, but I am only getting approximately 7.5 hours. I have installed the latest firmware v.0.03 upgrade, and fully charged and discharged both batteries at least fi've times each (using the USB and AC adaptors before plutting into outlet). Before the firmware upgrade I was getting just under six hours of battery life. For testing purposes I am using 28kbps MP3 files, volume level 8, no EQ setting, no backlighting, and the headphones that came with the product. Since I have the player sitting on my desk, without being listened to, there's no skipping or forwarding of music tracks. Gi'ven the non-demanding settings, the battery performance is disappointing.
I have contacted tech support and they want me to send in my player for repair or replacement. It seems this issue is prevalent for all Zen Micros and I don't want to send mine in to have it returned all scuffed and scratched and not fixed (or get some grimy second-hand, refurbished model instead).
So I want to confirm that others are experiencing this same problem before I decide what to do. It seems it would be best to get another one from Amazon instead of going through the hassle of repair.I notified Amazon of the problem on Friday and got a brand new replacement on Monday. Talk about great service.
Unfortunately the replacement is a crapper also. My second Zen Micro immediately and completely locks up when plugging in the USB cable. Since I didn't return my original unit yet, I was able to try another cable but got the same results. I fully charged the batteries, tried all of the various recovery mode options, and still had the Creative drivers/software previously installed on my computer from before. I'm running WinXP SP2 with up-to-date patches, and no other software installed since. My PC's motherboard has built-in USB 2.0 support (with power mgmt turned off) and updated drivers and BIOS, but these things shouldn't be an issue anyway since it worked fine with the first Zen Micro. I'm not able to upgrade the firmware, let alone transfer music, because of the lockup problem. I build and fix PCs for friends and coworkers all the time so I'm confident in my trouble-shooting abilities.
The second Micro makes the first one seem perfect. I really wanted to like this MP3 player, but two defecti've products in a row is totally unacceptable to me. What a waste of my time. I should have been more suspicious about Creative products since my Muvo TX FM player was buggy as well (i.e. player would immediately shut down when powering on). I will check out the Rio Carbon or iRi'ver products instead. -
I have an Oracle 10g R2 10.2.0.4 data warehouse with a fact table that holds records that are input in chronological order. Each month of records is contained in its own tablespace. Each tablespace is partitioned by a range partition on the day and subpartitioned by a hash of the primary key into 8 subpartitions, which results in daily partitions. A tablespace usually contains 7 datafiles that are 16384m in size for a total of 114688m (115GB) in physical size. All datafiles are on a SAN within ASM disk groups.
Why when I query for counts in the fact table over the first three days of a month does it return much faster (orders of magnitude faster) than when I query for counts in the last three days of a month?
The schema is a star schema and according to the explain plans for both queries star transforms are being achieved.
Is it the file size? What do you think?As Oraclefusions said I think we need to know more about your stats collection method. Are you using the Oracle provided scheduler job with the default sessing or have you modified it?
When you look at the last_analyzed date for the table how often are the statistics being updated?
Have you tried running explain plan for the two sets of data then if the plans do not vary have you queried v$sql_plan for the actual execution plans to see how Oracle is solving the two queries?
HTH -- Mark D Powell -- -
SQL query performance difference with Index Hint in Oracle 10g
Hi,
I was having a problem in SQL select query which was taking around 20 seconds to get the results. So, by hit and trail method I added Index Oracle Hint into the same query with the list of indexes of the tables and the results are retrieved with in 10 milli seconds. I am not sure to get How this is working with Indexes Hint.
The query with out Index Hint:
select /*+rule*/ FdnTab2.fdn, paramTab3.attr_name from fdnmappingtable FdnTab, fdnmappingtable FdnTab2, parametertable paramTab1 ,parametertable paramTab3 where FdnTab.id=52787 and paramTab1.id= FdnTab.id and paramTab3.id = FdnTab.id and paramTab3.attr_value = FdnTab2.fdn and paramTab1.attr_name='harqUsersMax' and paramTab1.attr_value <> 'DEFAULT' and exists ( select ParamTab2.attr_name from parametertable ParamTab2, templaterelationtable TemplateTab2 where TemplateTab2.id=FdnTab.id and ParamTab2.id=TemplateTab2.template_id and ParamTab2.id=FdnTab2.id and ParamTab2.attr_name=paramTab1.attr_name) ==> EXECUTION TIME: 20 secs
The same query with Index Hint:
select /*+INDEX(fdnmappingtable[PRIMARY_KY_FDNMAPPINGTABLE],parametertable[PRIMARY_KY_PARAMETERTABLE])*/ FdnTab2.fdn, paramTab3.attr_name from fdnmappingtable FdnTab, fdnmappingtable FdnTab2, parametertable paramTab1 ,parametertable paramTab3 where FdnTab.id=52787 and paramTab1.id= FdnTab.id and paramTab3.id = FdnTab.id and paramTab3.attr_value = FdnTab2.fdn and paramTab1.attr_name='harqUsersMax' and paramTab1.attr_value <> 'DEFAULT' and exists ( select ParamTab2.attr_name from parametertable ParamTab2, templaterelationtable TemplateTab2 where TemplateTab2.id=FdnTab.id and ParamTab2.id=TemplateTab2.template_id and ParamTab2.id=FdnTab2.id and ParamTab2.attr_name=paramTab1.attr_name) ==> EXECUTION TIME: 10 milli secs
Can any one suggest what could be the real problem?
Regards,
PurushothamSorry,
The right query and the explain plan:
select /*+rule*/ FdnTab2.fdn, paramTab3.attr_name from fdnmappingtable FdnTab, fdnmappingtable FdnTab2, parametertable paramTab1 ,parametertable paramTab3 where FdnTab.id=52787 and paramTab1.id= FdnTab.id and paramTab3.id = FdnTab.id and paramTab3.attr_value = FdnTab2.fdn and paramTab1.attr_name='harqUsersMax' and paramTab1.attr_value <> 'DEFAULT' and exists ( select ParamTab2.attr_name from parametertable ParamTab2, templaterelationtable TemplateTab2 where TemplateTab2.id=FdnTab.id and ParamTab2.id=TemplateTab2.template_id and ParamTab2.id=FdnTab2.id and ParamTab2.attr_name=paramTab1.attr_name)
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 651267974
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
|* 1 | FILTER | |
| 2 | NESTED LOOPS | |
| 3 | NESTED LOOPS | |
| 4 | NESTED LOOPS | |
|* 5 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
PLAN_TABLE_OUTPUT
|* 6 | TABLE ACCESS BY INDEX ROWID| PARAMETERTABLE |
|* 7 | INDEX UNIQUE SCAN | PRIMARY_KY_PARAMETERTABLE |
| 8 | TABLE ACCESS BY INDEX ROWID | PARAMETERTABLE |
|* 9 | INDEX RANGE SCAN | PRIMARY_KY_PARAMETERTABLE |
| 10 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
|* 11 | INDEX UNIQUE SCAN | SYS_C005695 |
| 12 | NESTED LOOPS | |
|* 13 | INDEX UNIQUE SCAN | PRIMARY_KY_PARAMETERTABLE |
|* 14 | INDEX UNIQUE SCAN | PRIMARY_KEY_TRTABLE |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter( EXISTS (SELECT 0 FROM "TEMPLATERELATIONTABLE"
"TEMPLATETAB2","PARAMETERTABLE" "PARAMTAB2" WHERE
"PARAMTAB2"."ATTR_NAME"=:B1 AND "PARAMTAB2"."ID"=:B2 AND
"PARAMTAB2"."ID"="TEMPLATETAB2"."TEMPLATE_ID" AND
"TEMPLATETAB2"."ID"=:B3))
5 - access("FDNTAB"."ID"=52787)
6 - filter("PARAMTAB1"."ATTR_VALUE"<>'DEFAULT')
7 - access("PARAMTAB1"."ID"="FDNTAB"."ID" AND
PLAN_TABLE_OUTPUT
"PARAMTAB1"."ATTR_NAME"='harqUsersMax')
9 - access("PARAMTAB3"."ID"="FDNTAB"."ID")
11 - access("PARAMTAB3"."ATTR_VALUE"="FDNTAB2"."FDN")
13 - access("PARAMTAB2"."ID"=:B1 AND "PARAMTAB2"."ATTR_NAME"=:B2)
14 - access("TEMPLATETAB2"."ID"=:B1 AND
"PARAMTAB2"."ID"="TEMPLATETAB2"."TEMPLATE_ID")
Note
- rule based optimizer used (consider using cbo)
43 rows selected.
WITH INDEX HINT:
select /*+INDEX(fdnmappingtable[PRIMARY_KY_FDNMAPPINGTABLE],parametertable[PRIMARY_KY_PARAMETERTABLE])*/ FdnTab2.fdn, paramTab3.attr_name from fdnmappingtable FdnTab, fdnmappingtable FdnTab2, parametertable paramTab1 ,parametertable paramTab3 where FdnTab.id=52787 and paramTab1.id= FdnTab.id and paramTab3.id = FdnTab.id and paramTab3.attr_value = FdnTab2.fdn and paramTab1.attr_name='harqUsersMax' and paramTab1.attr_value <> 'DEFAULT' and exists ( select ParamTab2.attr_name from parametertable ParamTab2, templaterelationtable TemplateTab2 where TemplateTab2.id=FdnTab.id and ParamTab2.id=TemplateTab2.template_id and ParamTab2.id=FdnTab2.id and ParamTab2.attr_name=paramTab1.attr_name);
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2924316070
| Id | Operation | Name | Rows | B
ytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 |
916 | 6 (0)| 00:00:01 |
|* 1 | FILTER | | |
| | |
| 2 | NESTED LOOPS | | 1 |
916 | 4 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 |
401 | 3 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 1 |
207 | 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| PARAMETERTABLE | 1 |
194 | 1 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_PARAMETERTABLE | 1 |
| 1 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE | 1 |
PLAN_TABLE_OUTPUT
13 | 1 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | PARAMETERTABLE | 1 |
194 | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PRIMARY_KY_PARAMETERTABLE | 1 |
| 1 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE | 1 |
515 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 11 | INDEX UNIQUE SCAN | SYS_C005695 | 1 |
| 1 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 |
91 | 2 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | PRIMARY_KEY_TRTABLE | 1 |
26 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PRIMARY_KY_PARAMETERTABLE | 1 |
65 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter( EXISTS (SELECT /*+ */ 0 FROM "TEMPLATERELATIONTABLE" "TEMPLATETAB
2","PARAMETERTABLE"
PLAN_TABLE_OUTPUT
"PARAMTAB2" WHERE "PARAMTAB2"."ATTR_NAME"=:B1 AND "PARAMTAB2"."ID"
=:B2 AND
"TEMPLATETAB2"."TEMPLATE_ID"=:B3 AND "TEMPLATETAB2"."ID"=:B4))
5 - filter("PARAMTAB1"."ATTR_VALUE"<>'DEFAULT')
6 - access("PARAMTAB1"."ID"=52787 AND "PARAMTAB1"."ATTR_NAME"='harqUsersMax')
7 - access("FDNTAB"."ID"=52787)
9 - access("PARAMTAB3"."ID"=52787)
11 - access("PARAMTAB3"."ATTR_VALUE"="FDNTAB2"."FDN")
13 - access("TEMPLATETAB2"."ID"=:B1 AND "TEMPLATETAB2"."TEMPLATE_ID"=:B2)
14 - access("PARAMTAB2"."ID"=:B1 AND "PARAMTAB2"."ATTR_NAME"=:B2)
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement
39 rows selected. -
Query performance affected with use of package.function in 11g
Hi,
I have a view that helps select account details for a particular account and use that in a form. The query in the view is:
select acc.* from accounts acc where acc.account_no = pkgacc.fGetAccNo;
Here "pkgacc" is a package that has set and get methods. ACCOUNT_NO is the PK for ACCOUNTS table. This same query when run in a 10g database makes use of the PK INDEX. However in 11g it does a FULL SCAN.
RegardsHi,
1/ Volume is the same
2/ All statistics are up to date
10g Plan
Plan
SELECT STATEMENT ALL_ROWS
Cost: 18 Bytes: 462 Cardinality: 3
23 NESTED LOOPS
21 NESTED LOOPS
Cost: 18 Bytes: 462 Cardinality: 3
19 VIEW VIEW SYS.VW_NSO_1
Cost: 12 Bytes: 39 Cardinality: 3
18 HASH UNIQUE
Cost: 12 Bytes: 110 Cardinality: 3
17 UNION-ALL
2 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.OLD_ACCOUNT_LINKS
Cost: 0 Bytes: 25 Cardinality: 1
1 INDEX RANGE SCAN INDEX SUMMIT.OACCL_2
Cost: 0 Cardinality: 1
8 NESTED LOOPS
6 NESTED LOOPS
Cost: 7 Bytes: 40 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.ACCOUNTS
Cost: 4 Bytes: 18 Cardinality: 1
3 INDEX RANGE SCAN INDEX (UNIQUE) SUMMIT.ACC_PRIME
Cost: 3 Cardinality: 1
5 INDEX RANGE SCAN INDEX SUMMIT.ACCL_2
Cost: 2 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.ACCOUNT_LINKS
Cost: 3 Bytes: 22 Cardinality: 1
16 NESTED LOOPS
Cost: 5 Bytes: 45 Cardinality: 1
14 MERGE JOIN CARTESIAN
Cost: 5 Bytes: 30 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE CVC.ACT01
Cost: 3 Bytes: 15 Cardinality: 1
9 INDEX RANGE SCAN INDEX (UNIQUE) CVC.PK_ACT01
Cost: 2 Cardinality: 1
13 BUFFER SORT
Cost: 2 Bytes: 30 Cardinality: 2
12 TABLE ACCESS BY INDEX ROWID TABLE CVC.ACF02
Cost: 2 Bytes: 30 Cardinality: 2
11 INDEX RANGE SCAN INDEX (UNIQUE) CVC.PK_ACF02
Cost: 1 Cardinality: 2
15 INDEX UNIQUE SCAN INDEX (UNIQUE) CVC.PK_BIT41
Cost: 0 Bytes: 15 Cardinality: 1
20 INDEX UNIQUE SCAN INDEX (UNIQUE) SUMMIT.CUST_PRIME
Cost: 1 Cardinality: 1
22 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.CUSTOMERS
Cost: 2 Bytes: 141 Cardinality: 1
11g Plan
Plan
SELECT STATEMENT ALL_ROWS
Cost: 1,136,322 Bytes: 138,218,223,528 Cardinality: 897,520,932
19 HASH JOIN
Cost: 1,136,322 Bytes: 138,218,223,528 Cardinality: 897,520,932
1 TABLE ACCESS FULL TABLE SUMMIT.CUSTOMERS
Cost: 14,455 Bytes: 355,037,154 Cardinality: 2,517,994
18 VIEW VIEW SYS.VW_NSO_1
Cost: 20,742 Bytes: 11,685,473,072 Cardinality: 898,882,544
17 HASH UNIQUE
Cost: 20,742 Bytes: 35,955,720,360 Cardinality: 898,882,544
16 UNION-ALL
3 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.OLD_ACCOUNT_LINKS
Cost: 0 Bytes: 25 Cardinality: 1
2 INDEX RANGE SCAN INDEX SUMMIT.OACCL_2
Cost: 0 Cardinality: 1
8 HASH JOIN
Cost: 20,354 Bytes: 35,951,952,800 Cardinality: 898,798,820
5 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.ACCOUNTS
Cost: 5,398 Bytes: 1,400,292 Cardinality: 77,794
4 INDEX RANGE SCAN INDEX (UNIQUE) SUMMIT.ACC_PRIME
Cost: 102 Cardinality: 28,006
7 TABLE ACCESS BY INDEX ROWID TABLE SUMMIT.ACCOUNT_LINKS
Cost: 4,634 Bytes: 4,575,208 Cardinality: 207,964
6 INDEX RANGE SCAN INDEX SUMMIT.ACCL_2
Cost: 145 Cardinality: 37,433
15 HASH JOIN
Cost: 388 Bytes: 3,767,535 Cardinality: 83,723
10 TABLE ACCESS BY INDEX ROWID TABLE CVC.ACT01
Cost: 271 Bytes: 4,065 Cardinality: 271
9 INDEX RANGE SCAN INDEX (UNIQUE) CVC.PK_ACT01
Cost: 3 Cardinality: 342
14 HASH JOIN
Cost: 115 Bytes: 92,580 Cardinality: 3,086
12 TABLE ACCESS BY INDEX ROWID TABLE CVC.ACF02
Cost: 76 Bytes: 46,290 Cardinality: 3,086
11 INDEX RANGE SCAN INDEX (UNIQUE) CVC.PK_ACF02
Cost: 4 Cardinality: 555
13 INDEX FAST FULL SCAN INDEX (UNIQUE) CVC.PK_BIT41
Cost: 38 Bytes: 557,220 Cardinality: 37,148 -
Poor query performance when I have select ...xmlsequence in from clause
Here is my query and it takes forever to execute. When I run the xmlsequence query alone, it takes a few seconds. But once added to from clause and I execute the query below together, it takes too long. Is there a better way to do the same?
What I am doing here is what is there in t1 should not be there in what is returned from the subquery (xmlsequence).
select distinct t1.l_type l_type,
TO_CHAR(t1.dt1,'DD-MON-YY') dt1 ,
TO_CHAR(t2.dt2,'DD-MON-YY') dt2, t1.l_nm
from table1 t1,table2 t2,
select k.column_value.extract('/RHS/value/text()').getStringVal() as lki
from d_v dv
, table(xmlsequence(dv.xmltypecol.extract('//c/RHS')))k
) qds
where
t2.l_id = t1.l_id
and to_char(t1.l_id) not in qds.lkiSQL> SELECT *
2 FROM TABLE(DBMS_XPLAN.DISPLAY);
Plan hash value: 2820226721
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 7611M| 907G| | 352M (1)|999:59:59 |
| 1 | HASH UNIQUE | | 7611M| 907G| 2155G| 352M (1)|999:59:59 |
|* 2 | HASH JOIN | | 9343M| 1113G| | 22M (2)| 76:31:45 |
| 3 | TABLE ACCESS FULL | table2 | 1088 | 17408 | | 7 (0)| 00:00:0
| 4 | NESTED LOOPS | | 8468M| 883G| | 22M (1)| 76:15:57 |
| 5 | MERGE JOIN CARTESIAN | | 1037K| 108M| | 4040 (1)| 00:00:49 |
| 6 | TABLE ACCESS FULL | D_V | 1127 | 87906 | | 56 (0)| 00
| 7 | BUFFER SORT | | 921 | 29472 | | 3984 (1)| 00:00:48 |
| 8 | TABLE ACCESS FULL | table1 | 921 | 29472 | | 4 (0)| 00:00:01 |
|* 9 | COLLECTION ITERATOR PICKLER FETCH| XMLSEQUENCEFROMXMLTYPE | | | |
Predicate Information (identified by operation id):
2 - access("t2"."L_ID"="t1"."L_ID")
9 - filter(TO_CHAR("t1"."L_ID")<>"XMLTYPE"."GETSTRINGVAL"("XMLTYPE"."EXTRACT"(VALUE(KOKB
alue/text()')))Message was edited by:
M@$$@cHu$eTt$ -
Hi,
Does using compression & partitioning (by time) affect the Reporting performance adversely? I have a 8GB Cube with 13 dimensions built in 10.1.0.4. Cube was defined with 1 dense dimension and other 12 as sparse in a compressed composite. It was also partitioned by Years. It takes close to 1 hour to build the cube. Since it is compressed, fully aggregated, I would assume. However, performance of discoverer queries on this cube has been pathetic! Any drill downs or slice/dice takes a long time to return if there are multiple dimensions in either edges of the Crosstab. Also, when scrolling down, it freezes for a while and then brings the data. Sometimes it takes couple of minutes!
What are the things I needs to check to speed this up? I think I checked things like sparsity, SGA/PGA sizes, OLAP Page Pool etc..
Regards
SureshHi Suresh,
Before you can implement changes to improve performance, you need to understand the causes of the performance problems. Discoverer for OLAP uses the OLAP API for queries, and the OLAP API generates SQL to query an analytic workspace. There are a few broad possible causes of poor query performance:
retrieving data from the AW is slow
SQL execution is slow, perhaps because the SQL is inefficient
SQL execution is fast, but the OLAP API is slow to fetch data
Each of these causes demands a different approach. I'd suggest that you enable configuration parameters SQL_TRACE and TIMED_STATISTICS, generate some trace files, and use the tkprof utility to try to narrow down the cause of the trouble.
Geof -
Performance problem with Integration with COGNOS and Bex
Hi Gems
I have a performance problem with some of my queries when integrating with the COGNOS
My query is simple which gets the data for the date interval : "
From Date: 20070101
To date:20070829
When executing the query in the Bex it takes 2mins but when it is executed in the COGNOS it takes almost 10mins and above..
Any where can we debug the report how the data is sending to the cognos. Like debugging the OLEDB ..
and how to increase the performance.. of the query in the Cognos ..
Thanks in Advance
Regards
AKHi,
Please check the following CA Unicenter config files on the SunMC server:
- is the Event Adapter (ea-start) running ?, without these daemon no event forwarding is done the CA Unicenter nor discover from Ca unicenter is working.
How to debug:
- run ea-start in debug mode:
# /opt/SUNWsymon/SunMC-TNG/sbin/ea-start -d9
- check if the Event Adaptor is been setup,
# /var/opt/SUNWsymon/SunMC-TNG/cfg_sunmctotng
- check the CA log file
# /var/opt/SUNWsymon/SunMC-TNG/SunMCToTngAdaptorMain.log
After that is all fine check this side it explains how to discover an SunMC agent from CA Unicenter.
http://docs.sun.com/app/docs/doc/817-1101/6mgrtmkao?a=view#tngtrouble-6
Kind Regards
Maybe you are looking for
-
I've been using a BB for 12 years but most of that time with DTM for Windows (until I saw the Mac light three years ago). Since the BB DTM, (aside from the fact we Mac folks get very little RIM love), after I updated my Tour to the "official" Verizo
-
C310 install runs but doesn't finish on Dell Inspiron w/ Windows 7, 64-bit
Whether I run the installation off the disk or a downloaded file, it progresses almost all the way to the end and then just closes. No files get installed. The printer is installed on several other W7-64 bit PCs on this network. I tried the HNDU tool
-
HT201250 Mac OS 10.6 - How to restore OS and Data from Time Machine Backup
my exisitng iMac have a defective hard drive that i need to be replace. how do i restore the OS and data to the new hard disk? i have Time Machine backup from the previous hard disk. (note: the OS is 10.6, and i do not have the install disk)
-
Parallels 7 vs Fusion 4, which is better?
The discussions on this seem to be from a few years ago. Anyone know which of the current versions are better?
-
PO number getting generated but PO doesnt get save in the system
Hi, System creating a PO number, and soon after a terminate message comes and no PO found in the system. What will be the reason, can any one please help? Regards, Sattuj