Query response is slow!!

Hi,
I have a schema X. In that i have a table T1 and an index (X.T1_IDX_INDEX)is created on that table as well.
Now the problem i am facing is, on firing a query on table T1 from schema X, the response time is 25s(In explain plan, full table scan is performed. Index is ignored, I dont know why?). When i fire the same query through "system" user the response time is less than a second(In xplain plan, Index is used).
Please suggest, how to resolve this problem.?
OS==> Centos
Oracle version : 11.2
Thanks in advance,
Regards,
Amit

Structure of the table
CREATE TABLE CUST_APP_CONF.NEW
NEW_ID NUMBER(8) NOT NULL,
NEW_NAME VARCHAR2(60 BYTE) NOT NULL,
CREATION_DATE DATE NOT NULL,
DESCRIPTION VARCHAR2(100 BYTE),
OWNER VARCHAR2(100 BYTE),
MEDIA VARCHAR2(100 BYTE),
XXX_SH_DPROF_ID NUMBER(4),
UPDATE_DATE DATE NOT NULL,
EAN NUMBER(10),
RESET_VAL NUMBER(37),
MUL_FAC NUMBER(10),
NEW_TYP_ID NUMBER(4) NOT NULL,
NEW_NEW_ID VARCHAR2(100 BYTE),
NEW_CALC_DVC_TYP VARCHAR2(100 BYTE),
NEW_CALC_DVC_TYP VARCHAR2(100 BYTE),
NEW_DVC_ID NUMBER(8),
NEW_CALC_DVC_ID VARCHAR2(100 BYTE),
CYCLE VARCHAR2(100 BYTE),
ROUTE VARCHAR2(100 BYTE),
WORKORDER_YEAR_NUMBER VARCHAR2(100 BYTE),
SERVICE VARCHAR2(100 BYTE),
NEW_NEW_ID_UPDATE_DATE DATE
TABLESPACE GENERIC_CONFIG_TBS
PCTUSED 0
PCTFREE 10
INNEWRANS 1
MAXTRANS 255
STORAGE (
BUFFER_POOL DEFAULT
PARTNEWION BY RANGE (NEW_ID)
INTERVAL( 100000)
PARTNEWION NEW_P2 VALUES LESS THAN (100000)
LOGGING
NOCOMPRESS
TABLESPACE GENERIC_CONFIG_TBS
PCTFREE 10
INNEWRANS 1
MAXTRANS 255
STORAGE (
INNEWIAL 64K
NEXT 64K
MINEXTENTS 1
MAXEXTENTS UNLIMNEWED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOCOMPRESS
NOCACHE
NOPARALLEL
MONNEWORING;
CREATE INDEX CUST_APP_CONF.IDX_PERF_NEW_NEW_ID ON CUST_APP_CONF.NEW
(NEW_CALC_DVC_ID)
LOGGING
TABLESPACE GENERIC_IND_CONFIG_TBS
PCTFREE 10
INNEWRANS 2
MAXTRANS 255
STORAGE (
INNEWIAL 64K
NEXT 64K
MINEXTENTS 1
MAXEXTENTS UNLIMNEWED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE UNIQUE INDEX CUST_APP_CONF.PK_1 ON CUST_APP_CONF.NEW
(NEW_ID)
LOGGING
TABLESPACE GENERIC_IND_CONFIG_TBS
PCTFREE 10
INNEWRANS 2
MAXTRANS 255
STORAGE (
INNEWIAL 64K
NEXT 64K
MINEXTENTS 1
MAXEXTENTS UNLIMNEWED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE UNIQUE INDEX CUST_APP_CONF.UK_1 ON CUST_APP_CONF.NEW
(NEW_NAME)
LOGGING
TABLESPACE GENERIC_IND_CONFIG_TBS
PCTFREE 10
INNEWRANS 2
MAXTRANS 255
STORAGE (
INNEWIAL 64K
NEXT 64K
MINEXTENTS 1
MAXEXTENTS UNLIMNEWED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE UNIQUE INDEX CUST_APP_CONF.UK_147_1 ON CUST_APP_CONF.NEW
(NEW_NEW_ID)
LOGGING
TABLESPACE GENERIC_IND_CONFIG_TBS
PCTFREE 10
INNEWRANS 2
MAXTRANS 255
STORAGE (
INNEWIAL 64K
NEXT 64K
MINEXTENTS 1
MAXEXTENTS UNLIMNEWED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
Query is used on the same table no joins....
select
NEW0_.NEW_ID as NEW1_1424_,
NEW0_.NEW_DVC_ID as NEW23_1424_,
NEW0_.NEW_CALC_DVC_ID as NEW2_1424_,
NEW0_.NEW_CALC_DVC_TYP as NEW3_1424_,
NEW0_.CREATION_DATE as CREATION5_1424_,
NEW0_.CYCLE as CYCLE1424_,
NEW0_.DESCRIPTION as DESCRIPT7_1424_,
NEW0_.EAN as EAN1424_,
NEW0_.NEW_NEW_ID as NEW9_1424_,
NEW0_.NEW_NEW_ID_UPDATE_DATE as NEW10_1424_,
NEW0_.NEW_CALC_DVC_TYP as NEW11_1424_,
NEW0_.NEW_NAME as NEW12_1424_,
NEW0_.NEW_TYP_ID as NEW13_1424_,
NEW0_.MEDIA as MEDIA1424_,
NEW0_.MUL_FAC as MUL15_1424_,
NEW0_.OWNER as OWNER1424_,
NEW0_.RESET_VAL as RESET17_1424_,
NEW0_.ROUTE as ROUTE1424_,
NEW0_.SERVICE as SERVICE1424_,
NEW0_.SMM_SH_DPROF_ID as SMM20_1424_,
NEW0_.UPDATE_DATE as UPDATE21_1424_,
NEW0_.WORKORDER_YEAR_NUMBER as WORKORDER22_1424_
from
CUST_APP_CONF.NEW NEW0_
where
NEW0_.NEW_CALC_DVC_ID in ('100001','100002','100003','100004','100005','100006','100007','100008','100009','100010','100011','100012','100013','100014','100015','100016','100017','100018','100019','100020','100021','100022','100023','100024','100025','100026','100027','100028','100029','100030','100031','100032','100033','100034','100035','100036','100037','100038','100039','100040','100041','100042','100043','100044','100045','100046','100047','100048','100049','100050','100051','100052','100053','100054','100055','100056','100057','100058','100059','100060','100061','100062','100063','100064','100065','100066','100067','100068','100069','100070','100071','100072','100073','100074','100075','100076','100077','100078','100079','100080','100081','100082','100083','100084','100085','100086','100087','100088','100089','100090','100091','100092','100093','100094','100095','100096','100097','100098','100099','100100','100101','100102','100103','100104','100105','100106','100107','100108','100109','100110','100111','100112','100113','100114','100115','100116','100117','100118','100119','100120','100121','100122','100123','100124','100125','100126','100127','100128','100129','100130','100131','100132','100133','100134','100135','100136','100137','100138','100139','100140','100141','100142','100143','100144','100145','100146','100147','100148','100149','100150','100151','100152','100153','100154','100155','100156','100157','100158','100159','100160','100161','100162','100163','100164','100165','100166','100167','100168','100169','100170','100171','100172','100173','100174','100175','100176','100177','100178','100179','100180','100181','100182','100183','100184','100185','100186','100187','100188','100189','100190','100191','100192','100193','100194','100195','100196','100197','100198','100199','100200','100201','100202','100203','100204','100205','100206','100207','100208','100209','100210','100211','100212','100213','100214','100215','100216','100217','100218','100219','100220','100221','100222','100223','100224','100225','100226','100227','100228','100229','100230','100231','100232','100233','100234','100235','100236','100237','100238','100239','100240','100241','100242','100243','100244','100245','100246','100247','100248','100249','100250','100251','100252','100253','100254','100255','100256','100257','100258','100259','100260','100261','100262','100263','100264','100265','100266','100267','100268','100269','100270','100271','100272','100273','100274','100275','100276','100277','100278','100279','100280','100281','100282','100283','100284','100285','100286','100287','100288','100289','100290','100291','100292','100293','100294','100295','100296','100297','100298','100299','100300','100301','100302','100303','100304','100305','100306','100307','100308','100309','100310','100311','100312','100313','100314','100315','100316','100317','100318','100319','100320','100321','100322','100323','100324','100325','100326','100327','100328','100329','100330','100331','100332','100333','100334','100335','100336','100337','100338','100339','100340','100341','100342','100343','100344','100345','100346','100347','100348','100349','100350','100351','100352','100353','100354','100355','100356','100357','100358','100359','100360','100361','100362','100363','100364','100365','100366','100367','100368','100369','100370','100371','100372','100373','100374','100375','100376','100377','100378','100379','100380','100381','100382','100383','100384','100385','100386','100387','100388','100389','100390','100391','100392','100393','100394','100395','100396','100397','100398','100399','100400','100401','100402','100403','100404','100405','100406','100407','100408','100409','100410','100411','100412','100413','100414','100415','100416','100417','100418','100419','100420','100421','100422','100423','100424','100425','100426','100427','100428','100429','100430','100431','100432','100433','100434','100435','100436','100437','100438','100439','100440','100441','100442','100443','100444','100445','100446','100447','100448','100449','100450','100451','100452','100453','100454','100455','100456','100457','100458','100459','100460','100461','100462','100463','100464','100465','100466','100467','100468','100469','100470','100471','100472','100473','100474','100475','100476','100477','100478','100479','100480','100481','100482','100483','100484','100485','100486','100487','100488','100489','100490','100491','100492','100493','100494','100495','100496','100497','100498','100499','100500','100501','100502','100503','100504','100505','100506','100507','100508','100509','100510','100511','100512','100513','100514','100515','100516','100517','100518','100519','100520','100521','100522','100523','100524','100525','100526','100527','100528','100529','100530','100531','100532','100533','100534','100535','100536','100537','100538','100539','100540','100541','100542','100543','100544','100545','100546','100547','100548','100549','100550','100551','100552','100553','100554','100555','100556','100557','100558','100559','100560','100561','100562','100563','100564','100565','100566','100567','100568','100569','100570','100571','100572','100573','100574','100575','100576','100577','100578','100579','100580','100581','100582','100583','100584','100585','100586','100587','100588','100589','100590','100591','100592','100593','100594','100595','100596','100597','100598','100599','100600','100601','100602','100603','100604','100605','100606','100607','100608','100609','100610','100611','100612','100613','100614','100615','100616','100617','100618','100619','100620','100621','100622','100623','100624','100625','100626','100627','100628','100629','100630','100631','100632','100633','100634','100635','100636','100637','100638','100639','100640','100641','100642','100643','100644','100645','100646','100647','100648','100649','100650','100651','100652','100653','100654','100655','100656','100657','100658','100659','100660','100661','100662','100663','100664','100665','100666','100667','100668','100669','100670','100671','100672','100673','100674','100675','100676','100677','100678','100679','100680','100681','100682','100683','100684','100685','100686','100687','100688','100689','100690','100691','100692','100693','100694','100695','100696','100697','100698','100699','100700','100701','100702','100703','100704','100705','100706','100707','100708','100709','100710','100711','100712','100713','100714','100715','100716','100717','100718','100719','100720','100721','100722','100723','100724','100725','100726','100727','100728','100729','100730','100731','100732','100733','100734','100735','100736','100737','100738','100739','100740','100741','100742','100743','100744','100745','100746','100747','100748','100749','100750','100751','100752','100753','100754','100755','100756','100757','100758','100759','100760','100761','100762','100763','100764','100765','100766','100767','100768','100769','100770','100771','100772','100773','100774','100775','100776','100777','100778','100779','100780','100781','100782','100783','100784','100785','100786','100787','100788','100789','100790','100791','100792','100793','100794','100795','100796','100797','100798','100799','100800','100801','100802','100803','100804','100805','100806','100807','100808','100809','100810','100811','100812','100813','100814','100815','100816','100817','100818','100819','100820','100821','100822','100823','100824','100825','100826','100827','100828','100829','100830','100831','100832','100833','100834','100835','100836','100837','100838','100839','100840','100841','100842','100843','100844','100845','100846','100847','100848','100849','100850','100851','100852','100853','100854','100855','100856','100857','100858','100859','100860','100861','100862','100863','100864','100865','100866','100867','100868','100869','100870','100871','100872','100873','100874','100875','100876','100877','100878','100879','100880','100881','100882','100883','100884','100885','100886','100887','100888','100889','100890','100891','100892','100893','100894','100895','100896','100897','100898','100899','100900','100901','100902','100903','100904','100905','100906','100907','100908','100909','100910','100911','100912','100913','100914','100915','100916','100917','100918','100919','100920','100921','100922','100923','100924','100925','100926','100927','100928','100929','100930','100931','100932','100933','100934','100935','100936','100937','100938','100939','100940','100941','100942','100943','100944','100945','100946','100947','100948','100949','100950','100951','100952','100953','100954','100955','100956','100957','100958','100959','100960','100961','100962','100963','100964','100965','100966','100967','100968','100969','100970','100971','100972','100973','100974','100975','100976','100977','100978','100979','100980','100981','100982','100983','100984','100985','100986','100987','100988','100989','100990','100991','100992','100993','100994','100995','100996','100997','100998','100999','101000');

Similar Messages

Fact Dimension Attribute causing extreme slow query response

I am using SSAS OLAP in SQL Server 2012. My server has 16 GB or RAM - it has only OLAP engine that is being used - nothing related to the relational engine. My fact table has a column called Product Status - for which I've a Fact dimension. Fact table has
18M rows, but the Product Staus has only 2-3 distinct values. When my users bring that attribute in their analysis, the response time is very slow - 10 to 15 minutes. Can anyone share their experiences with how I can go about optimizing this?
I tried to use the user based optimization, but the wizard suggests no aggregations.
Thanks!
GBM

Hi GBM,
For a cube of moderate to large size, partitions can greatly improve query performance, load performance, and ease of cube maintenance. Have you define partitions in your cube? Here is a good article regaridng Analysis Services Query Performance Top 10 Best
Practices for your reference, please see:
http://technet.microsoft.com/en-us/library/cc966527.aspx
To troubheshoot MDX query performance issue, we can create a trace to capture some events for further investigation in this case. Please see the articles below how to troubleshoot SSAS MDX query performance issue:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/f1f57e7b-eced-4009-b635-3ebb1d7fa5b0/how-do-i-troubleshoot-the-slow-mdx-query-performance
http://www.mssqltips.com/sqlservertip/2886/improving-sql-server-analysis-services-query-response-time-with-msmdsrv/
Hope this helps.
Regards,
Elvis Long
TechNet Community Support

Query is dead slow

declare @search varchar(100)
select id,name,grade from VCustomer(10 million records)
where cast(id as varchar) like @search +%
here id is bigint and cast operation used in where condition so query is getting slow.Please do the needful.How to avoid this cast opeartion in query.
Cheers,

Thanks for your valuable response.But still I am getting table scan.
I have modified the column data type into Varchar.But in where clause there are two string search i.e.
declare @search varchar(100)
ID varchar(50),CustomerID varchar(50)
select id,name,grade from VCustomer(10 million records) VC LEFT OUTER JOIN VBooking VB(20 Millions)
ON VC.ID=VB.CustomerID
where ID like @search +'%' or CustomerID like @search +'%'
Here I am getting both table scans.Please do the needful.
Cheers,

Rules of thumb for acceptable query response times?

Once I read a statement from SAP which said that users typically tolerate
response times up to 7 seconds. So you should strive to achive this goal.
Unfortunately I cannot remember in which document or webpage this
statement was made. Does anybody happen to have a reference for this rule
or any other SAP rules about the BW query response times?
Regards,
Mark

Share with us the situations where your query is running slow. How many rows are you returning via SQL Commands?
On reports; the maximum row count being returned and/or the pagination scheme can have impact on performance.
Jeff

Help required in optimizing the query response time

Hi,
I am working on a application which uses a jdbc thin client. My requirement is to select all the table rows in one table and use the column values to select data in another table in another database.
The first table can have maximum of 6 million rows but the second table rows will be around 9000.
My first query is returning within 30-40 milliseconds when the table is having 200000 rows. But when I am iterating the result set and query the second table the query is taking around 4 millisecond for each query.
the second query selection criteria is to find the value in the range .
for example my_table ( varchar2 column1, varchar2 start_range, varchar2 end_range);
My first query returns a result which then will be used to select using the following query
select column1 from my_table where start_range < my_value and end_range> my_value;
I have created an index on start_range and end_range. this query is taking around 4 millisseconds which I think is too much.
I am using a preparedStatement for the second query loop.
Can some one suggest me how I can improve the query response time?
Regards,
Shyam

Try the code below.
Pre-requistee: you should know how to pass ARRAY objects to oracle and receive resultsets from java. There are 1000s of samples available on net.
I have written a sample db code for the same interraction.
Procedure get_list takes a array input from java and returns the record set back to java. You can change the tablenames and the creteria.
Good luck.
DROP TYPE idlist;
CREATE OR REPLACE TYPE idlist AS TABLE OF NUMBER;
CREATE OR REPLACE PACKAGE mypkg1
AS
   PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor);
END mypkg1;
CREATE OR REPLACE PACKAGE BODY mypkg1
AS
   PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor)
   AS
      ctr   NUMBER;
   BEGIN
      DBMS_OUTPUT.put_line (myval_list.COUNT);
      FOR x IN (SELECT object_name, object_id, myvalue
                  FROM user_objects a,
                       (SELECT myval_list (ROWNUM + 1) myvalue
                          FROM TABLE (myval_list)) b
                 WHERE a.object_id < b.myvalue)
      LOOP
         DBMS_OUTPUT.put_line (   x.object_name
                               || ' - '
                               || x.object_id
                               || ' - '
                               || x.myvalue
      END LOOP;
   END;
END mypkg1;
[pre]
Testing the code above. Make sure dbms output is ON.
[pre]
DECLARE
   a      idlist;
   refc   sys_refcursor;
   c number;
BEGIN
   SELECT x.nu
   BULK COLLECT INTO a
     FROM (SELECT 5000 nu
             FROM DUAL) x;
   mypkg1.get_list (a, refc);
END;
[pre]
Vishal V.

How to obtain the Query Response Time of a query?

Given the Average Length of Row of tables and the number of rows in each table,
is there a way we get the query response time of a query involving
those tables. Query includes joins as well.
For example, suppose there 3 tables t1, t2, t3. I wish to obtain the
time it takes for the following query:
Query
SELECT t1.col1, t2.col2
FROM t1, t2, t3
WHERE t1.col1 = t2.col2
AND t1.col2 IN ('a', 'c', 'd')
AND t2.col1 = t3.col2
AND t2.col1 = t1.col1 (+)
ORDER BY t1.col1
Given are:
Average Row Length of t1 = 200 bytes
Average Row Length of t2 = 100 bytes
Average Row Length of t3 = 500 bytes
No of rows in t1 = 100
No of rows in t2 = 1000
No of rows in t3 = 500
What is required is the 'query response time' for the said query.

I do not know how to do it myself. But if you are running Oracle 10g, I believe that there is a new tool called: SQL Tuning Advisor which might be able to help.
Here are some links I found doing a google search, and it looks like it might meet your needs and even give you more information on how to improve your code.
http://www.databasejournal.com/features/oracle/article.php/3492521
http://www.databasejournal.com/features/oracle/article.php/3387011
http://www.oracle.com/technology/obe/obe10gdb/manage/perflab/perflab.htm
http://www.oracle.com/technology/pub/articles/10gdba/week18_10gdba.html
http://www.oracle-base.com/articles/10g/AutomaticSQLTuning10g.php
Have fun reading:
You can get help from teachers, but you are going to have to learn a lot by yourself, sitting alone in a room ....Dr. Seuss
Regards
Tim

OBIEE -10.1.3.4.1 - high physical and logical query response

Hi All,
I am facing an performance issue in OBIEE 10g .My report is taking 2 mins to come up and when i fired the physical query in the db the data is coming in 2 secs.
Below is the details from the log file.Here I observed that response time for physical and logical query is 109 sec ~ 2 mins.Please provide me the helpful pointers.
+++Administrator:370000:370015:----2013/01/22 07:28:04
-------------------- Execution Node: <<2650466>>, Close Row Count = 3332, Row Width = 26000 bytes
+++Administrator:370000:370015:----2013/01/22 07:28:04
-------------------- Execution Node: <<2650466>> DbGateway Exchange, Close Row Count = 3332, Row Width = 26000 bytes
+++Administrator:370000:370015:----2013/01/22 07:28:04
-------------------- Execution Node: <<2650466>> DbGateway Exchange, Close Row Count = 3332, Row Width = 26000 bytes
+++Administrator:370000:370015:----2013/01/22 07:28:04
-------------------- Query Status: Successful Completion
+++Administrator:370000:370015:----2013/01/22 07:28:05
-------------------- Rows 3332, bytes 86632000 retrieved from database query id: <<2650466>>
+++Administrator:370000:370015:----2013/01/22 07:28:05
-------------------- Physical query response time 109 (seconds), id <<2650466>>
+++Administrator:370000:370015:----2013/01/22 07:28:05
-------------------- Physical Query Summary Stats: Number of physical queries 1, Cumulative time 109, DB-connect time 0 (seconds)
+++Administrator:370000:370015:----2013/01/22 07:28:05
-------------------- Rows returned to Client 3332
+++Administrator:370000:370015:----2013/01/22 07:28:05
-------------------- Logical Query Summary Stats: Elapsed time 109, Response time 109, Compilation time 0 (seconds)

Did you run the SQL from a client on the OBIEE server or your local machine? Does the Physical SQL on the OBIEE server against the DB run in 2 Seconds and when sent by the OBIEE server it takes 109 seconds?? Is that correct?

My computer than the original response is slow,how to do?

My computer than the original response is slow,how to do.help

Please post in your native language as your English makes no sense.

Query runs much slower the second time!

I am doing a simple SELECT on a fairly complex view:
select * from balances where day = date'2011-08-15';The results are correct, and they arrive in about 3 seconds. However, immediately repeating the exact same query takes about 3 minutes!
Using a different SELECT list and/or WHERE clause gives a quick result, but only once; repeating any past query triggers the big slowdown.
Doing ANALYZE TABLE on any of the tables involved in the view seems to reset things and the queries become fast again, but still only once for each specific query.
This view worked fine on 9i and has only started doing this since we moved to 11g.
Weird, eh?

Here's EXPLAIN PLAN, which is the same before the fast query, before the slow query, and after the slow query.
| Id | Operation                         | Name                  | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |                       |   184K|    11M|       |   364K (1)| 01:12:52 |
|   1 | HASH GROUP BY                    |                       |   184K|    11M|    13M|   364K (1)| 01:12:52 |
|* 2 |   FILTER                          |                       |       |       |       |            |          |
|   3 |    NESTED LOOPS OUTER             |                       |   184K|    11M|       |   361K (1)| 01:12:17 |
|   4 |     NESTED LOOPS                  |                       | 3071 | 82917 |       |    27   (0)| 00:00:01 |
|   5 |      TABLE ACCESS BY INDEX ROWID | GL_DAYS               |     1 |    12 |       |     2   (0)| 00:00:01 |
|* 6 |       INDEX UNIQUE SCAN           | GL_DAYS_DAY           |     1 |       |       |     1   (0)| 00:00:01 |
|* 7 |      TABLE ACCESS FULL            | GL_ACCOUNTS           | 3071 | 46065 |       |    25   (0)| 00:00:01 |
|   8 |     VIEW                          |                       |    60 | 2340 |       |   118   (0)| 00:00:02 |
|* 9 |      FILTER                       |                       |       |       |       |            |          |
|* 10 |       TABLE ACCESS BY INDEX ROWID | GL_ENTRIES            |    60 | 1380 |       |    28   (0)| 00:00:01 |
|* 11 |        INDEX RANGE SCAN           | GL_ENTRIES_BY_ACCOUNT |    46 |       |       |     2   (0)| 00:00:01 |
| 12 |       NESTED LOOPS                |                       |     1 |    15 |       |     3   (0)| 00:00:01 |
| 13 |        TABLE ACCESS BY INDEX ROWID| GL_VOUCHERS           |     1 |     7 |       |     2   (0)| 00:00:01 |
|* 14 |         INDEX UNIQUE SCAN         | GL_VOUCHERS_PK        |     1 |       |       |     1   (0)| 00:00:01 |
|* 15 |        TABLE ACCESS BY INDEX ROWID| GL_PERIODS            |   104 |   832 |       |     1   (0)| 00:00:01 |
|* 16 |         INDEX UNIQUE SCAN         | GL_PERIODS_PK         |     1 |       |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(TO_DATE(' 2011-08-15 00:00:00', 'syyyy-mm-dd hh24:mi:ss')<CURRENT_DATE+730)
   6 - access("D"."DAY"=TO_DATE(' 2011-08-15 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter("D"."DAY"<CURRENT_DATE+730)
   7 - filter("A"."HAS_SUB"=0)
   9 - filter("D"."FISCAL_YEAR"= (SELECT "P"."FISCAL_YEAR" FROM MFA4."GL_PERIODS" "P",MFA4."GL_VOUCHERS"
              "V" WHERE "V"."ID"=:B1 AND "P"."ID"="V"."PERIOD_ID" AND "P"."PERIOD_NO"<13))
10 - filter("E"."ENTRY_DATE"<="D"."DAY")
11 - access("E"."ACCOUNT_ID"="A"."ID")
14 - access("V"."ID"=:B1)
15 - filter("P"."PERIOD_NO"<13)
16 - access("P"."ID"="V"."PERIOD_ID")As for the trace file, did you want the raw .trc file or the tkprof output?

How to get query response time from ST03 via a script ?

Hello People,
I am trying to get average query response time for BW queries with a script (for monitoring/historisation).
I know that this data can be found manually in ST03n in the "BI workload'.
However, I don't know how to get this stat from a script.
My idea is to run a SQL query to get this information, here is the state of my query :
select count(*) from sapbw.rsddstat_olap
where calday = 20140401
and (eventid = 3100 or eventid = 3010)
and steptp = 'BEX3'
The problem is that this query is not returning the same number of navigations as the number shown in ST03n.
Can you help me to set the correct filters to get the same number of navigation as in ST03n ?
Regards.

Hi Experts,
Do you have ideas for this SQL query ?
Regards.

How to get Query response Time?

II am on BI 7.0. I ran some queries using RSRT command. I want to find how much time the queries took.
I went to
st03 -> expert mode -> BI system load-> select today / week/month according to the query runtime day
I do not see any Info Providers. Query was on a cube so why no Info Providers.
Does something have to turned on InfoPorvider to show.
When I look in RSDDSTAT_OLAP table, I do see many rows but cannot make any sense. Is there some documentation on how to get total query time from this table?
Is there any other way to get query response time?
Thanks a lot.

HI,
why not use RSRT ? You can add database statistics option in "Execut & Debug" and you get all the runtime metrics of your query
In transaction RSRT, enter the query name and press u2018Execute +Debugu2019.
Selecting u2018Display Statistics Datau2019 .
After executing the query will return a list of the measured metrics.
The event id / text describes the steps (duration in seconds):
"OLAP: Read data" gives the SQL statements repsonse time (ok - because the SAP
application server acts as an Oracle client a little network traffic from the db server is included,
but as far as you not transferring zillions of rows it can be ignored)
But it gives you much more (i.e. if the OLAP cache gets used or not )...
In the "Aggreagate statistcs" you get all the infoproviders involved in that query.
bye
yk

TP Yoga 15 - Windows: Keyboard response too slow after coming back from hibernation

I've got the same issue as outlined in this thread for a Y50 - there seems to be a BIOS update to solve it, but what about TP Yoga 15? Quote:Simply put, In keyboard properties , the Repeat delay is default at maximum (eg, holding down a keyboard button and how fast it generates the key strokes). When the system is put in hiberanation, then turned on again to come back, the Repeat delay some how gets decreased to about 2/3 of what it originally is. https://forums.lenovo.com/t5/Lenovo-P-Y-and-Z-series/Re-Y50-Windows-8-Keyboard-response-too-slow-after-coming-back/td-p/1676309/page/1

hi guys,
Can you please provide also these additional information:
(this is to check if the issue is isolated to a certain model number)
Model Number (eg. 59-xxxxxx):
Place of Purchase (eg. Amazon, Bestbuy, etc.):
In addition, the solution from this thread seems to be a good workaround (the app is for Win7 but may also work for Win8.1)
Regards
Did someone help you today? Press the star on the left to thank them with a Kudo!
If you find a post helpful and it answers your question, please mark it as an "Accepted Solution"! This will help the rest of the Community with similar issues identify the verified solution and benefit from it.
Follow @LenovoForums on Twitter!

I am a new Apple user and had a visitor, with an iPad, at my house. I noticed the response time slowed greatly. I have a Linksys N router and wondered is I need an Apple router to allow the speed to be consistent.

I am a new Apple user and had a visitor, with an iPad, at my house. I noticed the response time slowed greatly. I have a Linksys N router and wondered if I need an Apple router to allow the speed to be consistent.

I am a new Apple user and had a visitor, with an iPad, at my house. I noticed the response time slowed greatly. I have a Linksys N router and wondered if I need an Apple router to allow the speed to be consistent.

Disabling cached query responses?

Here's the problem I have...
Whenever I go to our SharePoint site to upload a document, CSA will flag whatever file I click on in the "Open file" window (before I go to upload) and query me if I want to give access to iexplore.exe to read the file. If a normal user is in this situation, they'd probably click no. Then, when you go to upload that file, the access is automatically blocked by the remembered query answer.
The query I've made (I made a specific one for this) DISABLES the "Don't Ask Me Again" option. My question is how can I disable all cached responses so that users can deny access in a certain situation, then grant access in another? Or is there a way to force the Agent to clear it's cached responses every couple minutes?

It is the Don't ask again checkbox available from the Query Settings page in the MC that controls whether the end user has the ability to have a query response remembered permanently. As the administrator, you decide whether or not users have the option to choose Don't ask again. If user queries do not include a Don't ask again option and responses are only cached temporarily (for approximately an hour) users can click the Clear button in the agent Query User Responses window to delete all temporarily cached responses.
Look at the URL for more information
http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a0080424780.html#wp962337

Parallel hint causes a query to run slower?

I have an insert...select query where the select is a join between a table with one billion rows (although there is a where clause on an indexed column that restricts it to "only" 300 million), a table with 30 million rows, and a table with about 100,000 rows, where the result is about 20 rows. When I first ran it, it took about 2 hours. I added a Parallel hint, and explain plan showed that it was being used (and v$session showed that I had about 30 additional connections while it ran). but not it takes four hours.
Is there a reason parallel processing would cause a query to run slower?
insert /*+ append */ into employees_by_age_group
pay_plan
, age_range
, pay_level
, fy
, employee_count
select /*+ parallel */
       emp.pay_plan
     , to_char(d.min_age) || '-' || to_char(d.max_age) as age_range
     , emp.pay_level
     , pay.fy
     , count(pay.employee_id) as employee_count
from
select /*+ index(pay_info pay_info_index_on_site) */
         employee_id
       , extract(year from (dte_ppe_end + 92)) as fy
       , count(employee_id) as num_recs
from pay_info
where extract(month from dte_ppe_end) = 10
and   extract(day from dte_ppe_end) between 14 and 27
and   substr(pay_type, 1, 1) IN ('A', 'B', 'C')
and   site like 'Z%'
group by employee_id, extract(year from (dte_ppe_end + 92))
) pay
join
select employee_id
       , pay_plan
       , pay_grade
       , pay_step
       , file_date
from
    select /*+ index(employee_info employee_info_index_on_site) */
           employee_id
         , pay_level
         , file_date
         , max(file_date)
           over (partition by extract(year from (file_date + 61)))
           as last_file_date
    from employee_info
    where site like 'Z%'
where file_date = last_file_date
) emp
on (
     emp.employee_id = pay.employee_id
     and extract(year from emp.file_date) = pay.fy - 1
join (
       select employee_id
            , dob
       from (
              select employee_id
                   , date_birth
                   , row_number() over (partition by employee_id order by date_file desc) as r
              from employee_birthdates
              where site like 'Z%'
       where r = 1
     ) dob
on dob.employee_id = pay.employee_id
join
            select 20 as min_age, 24 as max_age from dual
union all select 25 as min_age, 29 as max_age from dual
union all select 30 as min_age, 34 as max_age from dual
union all select 35 as min_age, 39 as max_age from dual
union all select 40 as min_age, 44 as max_age from dual
union all select 45 as min_age, 49 as max_age from dual
union all select 50 as min_age, 54 as max_age from dual
union all select 55 as min_age, 59 as max_age from dual
union all select 60 as min_age, 64 as max_age from dual
union all select 65 as min_age, 69 as max_age from dual
union all select 70 as min_age, 74 as max_age from dual
union all select 75 as min_age, 79 as max_age from dual
union all select 80 as min_age, 84 as max_age from dual
union all select 85 as min_age, 89 as max_age from dual
union all select 90 as min_age, 94 as max_age from dual
union all select 95 as min_age, 99 as max_age from dual
) d
group by emp.pay_plan, d.min_age, d.max_age, emp.pay_level, pay.fy;

Paul - here are three different explain plans
First, the original one (without the parallel hint):
INSERT STATEMENT ALL_ROWS                                              Cost: 26,684,255 Bytes: 114 Cardinality: 1
35 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
    34 HASH GROUP BY                                                    Cost: 26,684,255 Bytes: 114 Cardinality: 1
      33 NESTED LOOPS                                                   Cost: 26,684,254 Bytes: 114 Cardinality: 1
        14 HASH JOIN                                                    Cost: 26,684,222 Bytes: 108 Cardinality: 1
          9 MERGE JOIN                                                  Cost: 4,408,803 Bytes: 8,322 Cardinality: 146
            3 VIEW DONBOT_DBA.                                          Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
              2 WINDOW SORT PUSHED RANK                                 Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
                1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
            8 SORT JOIN                                                 Cost: 4,293,940 Bytes: 3,645 Cardinality: 135
              7 VIEW DONBOT_DBA.                                        Cost: 4,293,939 Bytes: 3,645 Cardinality: 135
                6 SORT GROUP BY                                         Cost: 4,293,939 Bytes: 4,185 Cardinality: 135
                  5 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO          Cost: 4,293,938 Bytes: 4,185 Cardinality: 135
                    4 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE     Cost: 487,124 Cardinality: 402,683,034
          13 VIEW DONBOT_DBA                                            Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
            12 WINDOW SORT                                              Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
              11 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
                10 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE   Cost: 50,419 Cardinality: 38,019,281
        32 VIEW DONBOT_DBA
          31 UNION-ALL
            15 FAST DUAL Cost: 2 Cardinality: 1
            16 FAST DUAL Cost: 2 Cardinality: 1
            17 FAST DUAL Cost: 2 Cardinality: 1
            18 FAST DUAL Cost: 2 Cardinality: 1
            19 FAST DUAL Cost: 2 Cardinality: 1
            20 FAST DUAL Cost: 2 Cardinality: 1
            21 FAST DUAL Cost: 2 Cardinality: 1
            22 FAST DUAL Cost: 2 Cardinality: 1
            23 FAST DUAL Cost: 2 Cardinality: 1
            24 FAST DUAL Cost: 2 Cardinality: 1
            25 FAST DUAL Cost: 2 Cardinality: 1
            26 FAST DUAL Cost: 2 Cardinality: 1
            27 FAST DUAL Cost: 2 Cardinality: 1
            28 FAST DUAL Cost: 2 Cardinality: 1
            29 FAST DUAL Cost: 2 Cardinality: 1
            30 FAST DUAL Cost: 2 Cardinality: 1          Next, one with the parallel hint:
INSERT STATEMENT ALL_ROWS                                                                              Cost: 26,507,111 Bytes: 114 Cardinality: 1
51 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
    50 PX COORDINATOR
      49 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10005 :Q1005                                     Cost: 26,507,111 Bytes: 114 Cardinality: 1
        48 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1005                                           Cost: 26,507,111 Bytes: 114 Cardinality: 1
          47 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1005                                            Cost: 26,507,111 Bytes: 114 Cardinality: 1
            46 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10004 :Q1004                                    Cost: 26,507,111 Bytes: 114 Cardinality: 1
              45 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,111 Bytes: 114 Cardinality: 1
                44 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1004                                    Cost: 26,507,111 Bytes: 114 Cardinality: 1
                  25 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,109 Bytes: 108 Cardinality: 1
                    17 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                  Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                      16 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10003 :Q1003                          Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                        15 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1003                               Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                          7 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1003
                            6 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                           Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                              5 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000                     Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                                4 VIEW DONBOT_DBA.                                                      Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                                  3 SORT GROUP BY                                                       Cost: 4,293,939 Bytes: 2,077 Cardinality: 67
                                    2 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO                        Cost: 4,293,938 Bytes: 2,077 Cardinality: 67
                                      1 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE                   Cost: 487,124 Cardinality: 199,756,151
                          14 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1003                      Cost: 7,561 Bytes: 29,625,180 Cardinality: 987,506
                            13 WINDOW SORT PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1003             Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                              12 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                        Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                11 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 :Q1002                Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                  10 WINDOW CHILD PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1002      Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                    9 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002             Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
                                      8 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT EMPLOYEE_BIRTHDATES :Q1002     Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
                    24 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1004
                      23 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                        22 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10001                               Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                          21 VIEW DONBOT_DBA.                                                           Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                            20 WINDOW SORT                                                              Cost: 22,205,605 Bytes: 417,522,615 Cardinality: 11,284,395
                              19 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO                        Cost: 22,137,046 Bytes: 417,522,615 Cardinality: 11,284,395
                                18 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE                   Cost: 50,419 Cardinality: 18,859,958
                  43 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1004                              Cost: 32 Bytes: 6 Cardinality: 1
                    42 UNION-ALL PARALLEL_COMBINED_WITH_PARENT :Q1004
                      26 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      27 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      28 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      29 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      30 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      31 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      32 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      33 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      34 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      35 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      36 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      37 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      38 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      39 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      40 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      41 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1                  Finally, one without the parallel hint, and without the index hint on PAY_TABLE:
INSERT STATEMENT ALL_ROWS                                              Cost: 23,348,654 Bytes: 114 Cardinality: 1
34 LOAD AS SELECT ARMYMP.EMPLOYEES_BY_AGE
    33 HASH GROUP BY                                                    Cost: 23,348,654 Bytes: 114 Cardinality: 1
      32 NESTED LOOPS                                                   Cost: 23,348,653 Bytes: 114 Cardinality: 1
        13 HASH JOIN                                                    Cost: 23,348,621 Bytes: 108 Cardinality: 1
          8 MERGE JOIN                                                  Cost: 1,073,202 Bytes: 8,322 Cardinality: 146
            3 VIEW DONBOT_DBA.                                          Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
              2 WINDOW SORT PUSHED RANK                                 Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
                1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
            7 SORT JOIN                                                 Cost: 958,339 Bytes: 3,645 Cardinality: 135
              6 VIEW DONBOT_DBA.                                        Cost: 958,338 Bytes: 3,645 Cardinality: 135
                5 SORT GROUP BY                                         Cost: 958,338 Bytes: 4,185 Cardinality: 135
                  4 TABLE ACCESS FULL TABLE PAY_INFO                    Cost: 958,337 Bytes: 4,185 Cardinality: 135
          12 VIEW DONBOT_DBA.                                           Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
            11 WINDOW SORT                                              Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
              10 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
                9 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_UIC              Cost: 50,419 Cardinality: 38,019,281
        31 VIEW DONBOT_DBA.                                             Cost: 32 Bytes: 6 Cardinality: 1
          30 UNION-ALL
            14 FAST DUAL Cost: 2 Cardinality: 1
            15 FAST DUAL Cost: 2 Cardinality: 1
            16 FAST DUAL Cost: 2 Cardinality: 1
            17 FAST DUAL Cost: 2 Cardinality: 1
            18 FAST DUAL Cost: 2 Cardinality: 1
            19 FAST DUAL Cost: 2 Cardinality: 1
            20 FAST DUAL Cost: 2 Cardinality: 1
            21 FAST DUAL Cost: 2 Cardinality: 1
            22 FAST DUAL Cost: 2 Cardinality: 1
            23 FAST DUAL Cost: 2 Cardinality: 1
            24 FAST DUAL Cost: 2 Cardinality: 1
            25 FAST DUAL Cost: 2 Cardinality: 1
            26 FAST DUAL Cost: 2 Cardinality: 1
            27 FAST DUAL Cost: 2 Cardinality: 1
            28 FAST DUAL Cost: 2 Cardinality: 1
            29 FAST DUAL Cost: 2 Cardinality: 1        I am surprised the cost without the index is less than the cost with it, considering that it is replacing a Table Access By Index Rowid with a Table Access Full on a table with 1 billion (1000 million) records.
Igor - two questions:
One - I cannot find "Materialize" in the hints in the SQL Reference anywhere. What does it do?
Two - does replacing subqueries with With clauses make that much of a difference?

Query response is slow!!

Similar Messages

Maybe you are looking for