Query performance time

Is it true that a query running on a table with default values of null is slower than a query running on a table with default values of ceros and blank spaces? If it's true, why does this happens, and if not , what is the main factor that affects query performance time?
If anyone can answer me, i will be grateful!!!

Hi,
It happends cause columns with NULL, NOT NULL or no constraint influence CBO (Cost Based Optimizer) when he chooses his explain plan.
For a complete explication, check the documentation on CBO on technet.
Good Luck,
Fred

Similar Messages

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.

How to measure query run time and mnitor performance

Hai All,
A simple question. How to measure query run time and mnitor performance? I want to see the parameters like how long it took to execute, how much space it took etc.
Thank you.

hi,
some ways
1. use transaction st03, expert mode.
2. tables rsddstat*
3. install bw statistics (technical content)
there are docs on this, also bi knowledge performance center.
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/3f66ba90-0201-0010-ac8d-b61d8fd9abe9
BW Performance Tuning Knowledge Center - SAP Developer Network (SDN)
Business Intelligence Performance Tuning [original link is broken]
also take a look
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
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/31b6b490-0201-0010-e4b6-a1523327025e
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'.

Query performance analysis in RSRT --- event text 'Wait Time, User' means?

Hi All,
I am running some queries in RSRT in 'execute + debug' mode.
selecting 'statistics data for query' option.
Statistics says that most of the time is taken by the event 'Wait Time, User' (event text).
handler type is OLAP or DFLT depending on the query.
This is taking around 90% of the query run time.
Can any one tell me what it means ? Where is it actualy taking time?
What does it mean by :
Event text --> 'waiting time, User'
Handler type DFLT
Handler type OLAP.
A sample record of the statistics:
4A2Z2CFA1GLIRPIK9O2Z18GK1 4A2Z2SN22IFE3AKOL50W9DQZ5 BEX3 2 ZS233BIWDEV 11.06.2008 19:29:08 DFLT 2 1 Wait Time, User 98.467887 0 1
Thanks in advance.
rgds,
Raghu.
Edited by: Raghu tej harish reddy on Jun 11, 2008 4:19 PM

Thank you for your immediate response.
But i won't think it is the time taken to enter the values in the variable screen because of two reasons:
1.There are some events starting before these events(i can say by seeing the starting time of the events)
2.For some queries this time is around 3 minutes; and i hardly take 30 seconds to enter the variable values.
Thanks,
Raghu

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.

Query performance in two environments

Hi all,
I have developed simple select queries on a multiprovider and I am facing issues with query performance in quality box. A query runs pretty fast in in dev and return results while the same one dumps in Quality environment giving a time out error. This sounds more strange because our dev box has comparitively more records than the quality environment right now.
On anlyzing the query path in both environments, we noticed that the query does an index scan in dev but not in Quality environment, especially when the selection is such that the query is supposed to return lot of records. Since the query does a sequential scan in quality, it dumps. Is there any setting that I need to make seprately in the quality environment.
Any tips on query optimization would be great help. Thanks
Regards
Niranjana

Execute some of the RSRT tests in the QA for the query using "Execute+Debug" option and use some test for Multiprovider and Databases checks in it ,try to compare with Dev as well.
Hope it Helps
Chetan
@CP..

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;

Query execution time

Dear SCN,
I am new to BOBJ Environment. I have created a webi report on top of bex query by using BISC connection. Bex query is build for Vendor Ageing Analysis. My bex query will take very less time to execute the report (max 1 min). But in case of webi is takeing around 5 min when i click on refresh. I have not used any conditions,filters,restrictions are done at webi level all are done at bex level only.
Please let me know techniques to optimize the query execution time in webi. Currently we are in BO 4.0.
Regards,
PRK

Hi Praveen
Go through this document for performance optimization using BICS connection
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0e3c552-e419-3010-1298-b32e6210b58d?QuickLink=index&…

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>

Query Performance - Query very slow to run

I have built a query to show payroll costings per month per employee by cost centres for the current fiscal year. The cost centres are selected with a hierarchy variable - it's quite a latrge hierarchy. The problem is the query takes ages to run - nearly ten minutes. It's built on a DSO so I cant aggregate it. Is there anything I can do to improve performance.

Hi Joel,
Walkthrough 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.
16. Check Sequential vs Parallel read on Multiproviders.
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.
24. Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase.
25. If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The u201Cnot assignedu201D nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected.
Regards
Vivek Tripathi

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

Query performance using distinct

Greetings! We're on Oracle 8.1.7, Solaris 2.8.
I have a query that utilizes a different access path if I use the word distinct in the select from this view. Here is our query:
SELECT
DISTINCT SETID,
VENDOR_ID,
VENDOR_NAME_SHORT,
AR_NUM,
NAME1,
ADDRESS1,
ADDRESS2,
CITY
FROM
PS_VENDOR_VW
WHERE
SETID LIKE 'MNSA' AND
NAME1='FUN' ORDER BY NAME1, SETID, VENDOR_ID
The view SQL is:
SELECT /*+ FIRST_ROWS */ a.setid
, a.vendor_name_short
, a.name1
, c.address1
, c.address2
, c.city
, a.vendor_id
FROM SYSADM.ps_vendor a
SELECT /*+ INDEX_ASC(B PSAVENDOR_ADDR) */
FROM SYSADM.ps_vendor_addr b
WHERE b.effdt = (
SELECT MAX(effdt)
FROM SYSADM.ps_vendor_addr
WHERE setid = b.setid
AND vendor_id = b.vendor_id
AND address_seq_num = b.address_seq_num
AND effdt <= sysdate)) c
WHERE a.setid = c.setid (+)
AND a.vendor_id = c.vendor_id (+)
AND a.prim_addr_seq_num=c.address_seq_num (+)
This query does an index full scan on an index for ps_vendor_addr. It takes 2+ minutes to run. Now, if I remove the word distinct, it uses an index range scan and "view pushed predicate". It runs in 2 seconds.
I've tried with and without the first_rows hint in the view. If I leave off the INDEX_ASC hint then it does a full table scan of table ps_vendor_addr. It refuses to do a range scan with the hint. Can anybody tell me how I can get the 'distinct' query tuned?
2 minutes may not seem like a lot but when online users run the query many times a day, it is very frustrating.
Thanks! I hope I provided enough info.

Thomas:
The different behaviours you are seeing are a result of the DISTINCT in the query. This causes a sort to be performed, and will influence the way that the CBO will execute the query. (You do know that you are using the Cost Based Optimizer because of the hints, and that you should analyze the tables and indexes?) You need to be able to re-write the view to avoid the need for the DISTINCT in the query.
Without knowing the meaning of the fields, it is really hard to say anything meaningful, but my guess is that it is the correlated sub-query that is ultimately causing the need for the DISTINCT. Is the combination of set_id,vendor_id and address_seq_num truly unique, or is the address_seq_num just a sequence.
For example in one of my databases, I have a table with INDV_ID, EFF_DT, EMPSTAT_SEQ. The empstat_seq field is just there to allow for more than one thing happening on the same day. The way we query this table is:
SELECT *
FROM empstat_t a
WHERE indv_id = :emp_id and
      TO_CHAR(eff_dt,'yyyymmdd')||TO_CHAR(empstat_seq,'009') =
              (SELECT MAX(TO_CHAR(eff_dt,'yyyymmdd')||TO_CHAR(empstat_seq,'009')
               FROM empstat_t
               WHERE a.indv_id = indv_id);Could something similar work in your case?
If not, assuming your statistics are up to date, I would also look at creating the view without hints to see what the optimizer comes up with on its own. It may be better than you think.
TTFN
John

Query Performance Issues on a cube sized 64GB.

Hi,
We have a non-time based cube whose size is 64 GB . Effectively, I can't use time dimension for partitioning. The transaction table has ~ 850 million records. We have 20+ dimensions among which 2 of the dimensions have 50 million records.
I have equally distributed the fact table records among 60 partitions. Each partition size is around 900 MB.
The processing of the cube is not an issue as it completes in 3.5 hours. The issue is with the query performance of the cube.
When an MDX query is submitted, unfortunately, in majority of the cases the storage engine has to scan all the partitions (as our cube is not time dependent and we can't find a suitable dimension that will fit the bill to partition measure group based
on it.)
I'm aware of the cache warming and usage based aggregation(UBO) techniques.
However, the cube is available for users to perform adhoc queries and hence the benefits of cache warming and UBO may cease to contribute to the performance gain as there is a high probability that each user may look at the data from different perspectives
(especially when we have 20 + dimensions) as day(s) progress.
Also, we have 15 + average calculations (calculated measures) in the cube. So, the storage engine sends all the granular data that the formula engine might have requested (could be millions of rows) and then perform the average calculation.
A look at the profiler suggested that considerable amount of time has been spent by storage engine to gather the records (from 60 partitions).
FYI - Our server has RAM 32 GB and 8 cores and it is exclusive to Analysis Services.
I would appreciate comments from anyone who has worked on a large cube that is not time dependent and the steps they took to improve the adhoc query performance for the users.
Thanks
CoolP

Hello CoolP,
Here is a good articles regarding how to tuning query performance in SSAS, please see:
Analysis Services Query Performance Top 10 Best Practices:
http://technet.microsoft.com/en-us/library/cc966527.aspx
Hope you can find some helpful clues to tuning your SSAS Server query performance. Moreover, there are two ways to improve the query response time for an increasing number of end-users:
Adding more power to the existing server (scale up)
Distributing the load among several small servers (scale out)
For detail information, please see:
http://technet.microsoft.com/en-us/library/cc966449.aspx
Regards,
Elvis Long
TechNet Community Support

Query performance time

Similar Messages

Maybe you are looking for