Select query generating redo
Hi
I am trying to run a select query in a database which has performance problems and I get the following stats
recursive calls 47
db block gets 0
consistent gets 36909
physical reads 203
redo size 205164
bytes sent via SQL*Net to client 1873
bytes received via SQL*Net from client 1716
SQL*Net roundtrips to/from client 4
sorts (memory) 2
sorts (disk) 0
I get a lot of consistent gets and redo size compare to the same query run on a good performing db(results below). Why should a select query generate a lot of redo? Can some one suggest me where should I be looking at to resolve this issue?
Thanks
recursive calls 47
db block gets 0
consistent gets 3470
physical reads 0
redo size 0
bytes sent via SQL*Net to client 1885
bytes received via SQL*Net from client 1725
SQL*Net roundtrips to/from client 5
sorts (memory) 2
sorts (disk) 0
Edited by: APV on Nov 18, 2008 1:08 PM
Queries can also generate redo if auditing is enabled. If you don't have auditing enabled and you find that a SELECT statement with no FOR UPDATE clause sometimes generates redo entries, you might be witnessing a case of delayed block cleanout
Similar Messages
-
How a select statement generates redo logs
Can some one explain how a select statement generates redo logs
NaveenRedo with a select statement happens when dirty blocks get written to the database, and are then "cleaned up" when next read of that data block. This could happen when a large DML statement does not commit before the DB Writer needs to write modified blocks to disk. The next time the blocks are read by a select statement they get modified, hence REDO is generated by the select statement.
Read the following for more and better understandings.
http://www.dbspecialists.com/specialists/specialist2003-10.htm
Jaffar -
Redo entry generation for select query
Does "SELECT" query generate redo entry?
If yes, Why?A SELECT may generate redo for "delayed block cleanout" and "delayed logging block cleanout" when it is querying blocks that were recently updated by a transaction that did not execute a "commit cleanout" completely.
See http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/
Hemant K Chitale -
SELECT query sometimes runs extremely slowly - UNDO question
Hi,
The Background
We have a subpartitioned table:
CREATE TABLE TAB_A
RUN_ID NUMBER NOT NULL,
COB_DATE DATE NOT NULL,
PARTITION_KEY NUMBER NOT NULL,
DATA_TYPE VARCHAR2(10),
START_DATE DATE,
END_DATE DATE,
VALUE NUMBER,
HOLDING_DATE DATE,
VALUE_CURRENCY VARCHAR2(3),
NAME VARCHAR2(60),
PARTITION BY RANGE (COB_DATE)
SUBPARTITION BY LIST (PARTITION_KEY)
SUBPARTITION TEMPLATE
(SUBPARTITION GROUP1 VALUES (1) TABLESPACE BROIL_LARGE_DATA,
SUBPARTITION GROUP2 VALUES (2) TABLESPACE BROIL_LARGE_DATA,
SUBPARTITION GROUP3 VALUES (3) TABLESPACE BROIL_LARGE_DATA,
SUBPARTITION GROUP4 VALUES (4) TABLESPACE BROIL_LARGE_DATA,
SUBPARTITION GROUP5 VALUES (DEFAULT) TABLESPACE BROIL_LARGE_DATA
PARTITION PARTNO_03 VALUES LESS THAN
(TO_DATE(' 2008-07-22 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
( SUBPARTITION PARTNO_03_GROUP1 VALUES (1),
SUBPARTITION PARTNO_03_GROUP2 VALUES (2),
SUBPARTITION PARTNO_03_GROUP3 VALUES (3),
SUBPARTITION PARTNO_03_GROUP4 VALUES (4),
SUBPARTITION PARTNO_03_GROUP5 VALUES (DEFAULT) ),
PARTITION PARTNO_01 VALUES LESS THAN
(TO_DATE(' 2008-07-23 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
( SUBPARTITION PARTNO_01_GROUP1 VALUES (1),
SUBPARTITION PARTNO_01_GROUP2 VALUES (2),
SUBPARTITION PARTNO_01_GROUP3 VALUES (3),
SUBPARTITION PARTNO_01_GROUP4 VALUES (4),
SUBPARTITION PARTNO_01_GROUP5 VALUES (DEFAULT) ),
PARTITION PARTNO_02 VALUES LESS THAN
(TO_DATE(' 2008-07-24 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
( SUBPARTITION PARTNO_02_GROUP1 VALUES (1),
SUBPARTITION PARTNO_02_GROUP2 VALUES (2),
SUBPARTITION PARTNO_02_GROUP3 VALUES (3),
SUBPARTITION PARTNO_02_GROUP4 VALUES (4),
SUBPARTITION PARTNO_02_GROUP5 VALUES (DEFAULT) ),
PARTITION PARTNO_OTHER VALUES LESS THAN (MAXVALUE)
( SUBPARTITION PARTNO_OTHER_GROUP1 VALUES (1),
SUBPARTITION PARTNO_OTHER_GROUP2 VALUES (2),
SUBPARTITION PARTNO_OTHER_GROUP3 VALUES (3),
SUBPARTITION PARTNO_OTHER_GROUP4 VALUES (4),
SUBPARTITION PARTNO_OTHER_GROUP5 VALUES (DEFAULT) )
CREATE INDEX TAB_A_IDX ON TAB_A
(RUN_ID, COB_DATE, PARTITION_KEY, DATA_TYPE, VALUE_CURRENCY)
LOCAL;The table is subpartitioned as each partition typically has 135million rows in it.
Overnight, serveral runs occur that load data into this table (the partitions are rolled over daily, such that the oldest one is dropped and a new one created. Stats are exported from the oldest partition prior to being dropped and imported to the newly created partition. The oldest partition once the partition has been created has it's stats analyzed).
Data loads can load anything from 200 rows to 20million rows into the table, with most of the rows ending up in the Default subpartition. Most of the runs that load a larger set of rows have been set up to add into one of the other 4 subpartitions.
We then run a process to extract data from the table that gets put into a file. This is a two step process (due to Oracle completely picking the wrong execution plan and us not being able to rewrite the query in such a way that it'll pick the right path up by itself!):
1. Identify all the unique currencies
2. Update the (dynamic) sql query to add a CASE clause into the select clause based on the currencies identified in step 1, and run the query.
Step 1 uses this query:
SELECT DISTINCT value_currency
FROM tab_a
WHERE run_id = :b3 AND cob_date = :b2 AND partition_key = :b1;and usually finishes this within 20 minutes.
The problem
Occasionally, this simple query runs over 20 minutes (I don't think we've ever seen it run to completion on these occurrences, and I've certainly seen it take over 3 hours before we killed it, for a run where it would normally complete in 2 or 3 minutes), which we've now come to recognise as it "being stuck". The execution path it takes is the same as when it runs normally, there are no unusual wait events, and no unusual wait times. All in all, it looks "normal" except for the fact that it's taking forever (tongue-in-cheek!) to run. When we kill and rerun, the execution time returns to normal. (We've sent system state dumps to Oracle to be analyzed, and they came back with "The database is doing stuff, can't see anything wrong")
We've never been able to come up with any explanation before, but the same run has failed consistently for the last three days, so I managed to wangle a DBA to help me investigate it further.
After looking through the ASH reports, he proposed a theory that the problem was it was having to go to the UNDO to retrieve results, and that this could explain the massive run time of the query.
I looked at the runs and agreed that UNDO might have been used in that particular instance of the query, as another run had loaded data into the table at the same time it was being read.
However, another one of the problematic runs had not had any inserts (or updates/deletes - they don't happen in our process) during the reading of the data, and yet it had taken a long time too. The ASH report showed that it too had read from UNDO.
My question
I understand from this link: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:44798632736844 about how Selects may generate REDO, but I don't see why UNDO would possibly be generated by a select. Does anyone know of a situation where a select would end up looking through UNDO, even though no inserts/updates/deletes had taken place on the table/index it was looking at?
Also, does the theory that having to look through the UNDO (currently UNDO ts is 50000MB, in case that's relevant) causing queries to take an extremely long time hold water? We're on 10.2.0.3
Message was edited by:
Boneist
Ok, having carried on searching t'internet, I can see that it's maybe Delayed Block Cleanout that's causing the UNDO to be referenced. Even taking that into account, I can't see why going back to the UNDO to be told to commit the change to disk could slow the query down that much? What waits would this show up as, if any?Since you're on 10.2 and I understand that you use
the statistics of the "previous" content for the
partition that you are now loading (am I right?) you
have to be very careful with the 10g optimizer. If
the statistics tell the optimizer that the values
that you're querying for are sufficiently
out-of-range this might change the execution plan
because it estimates that only a few or no rows will
be returned. So if the old statistics do not fit the
new data loaded in terms of column min/max values
then this could be a valid reason for different
execution plans for some executions (depending on the
statistics of the old partition and the current
values used). Your RUN_ID is a good candidate I guess
as it could be ever increasing... If the max value of
the old partition is sufficiently different from the
current value this might be the cause.
Do you actually use bind variables for that
particular statement? Then we have in addition bind
variable peeking and potentially statement re-using
to consider.
I would prefer literals instead of bind variables or
do you encounter parse issues?Yes, that query runs as part of a procedure and uses bind variables (well, pl/sql variables!). We are aware that because of the histograms that get produced, the stats are not as good as we'd like. I'm wondering if analyzing the partition would be the best way to go, only that means analysing the entire partition, not just the subpartition, I guess? But if other inserts are taking place at the same time, having several analyzes taking place won't help the speed of inserting, or won't it matter?
Do you have the "default" 10g statistics gathering
job active? This could also explain why you get
different execution plans at different execution
times. If the job determines that the statistics of
some of your partitions are stale then it will
attempt to gather statistics even if you already have
statistics imported/generated.No, we turned that off. The stats do not change when we rerun the query - we guess there is some sort of contention taking place, possibly when reading from the UNDO, although I would expect that to show up in the waits - it doesn't appear to though.
Data loads can load anything from 200 rows to
20million rows into the table, with most of therows
ending up in the Default subpartition. Most of the
runs that load a larger set of rows have been setup
to add into one of the other 4 subpartitions.
I'm not sure about above description. Do most of the
rows end up in the default subpartition (most rows in
default partition) or do the larger sets load into
the other 4 ones... (most rows in the non-default
partitions)?Sorry, I mean that the loads that load say 20million + rows at a time have a specified subpartition to go into (defined via some config. We had to make up a "partition key" in order to do this as there is nothing in the data that lends itself to the subpartition list, unfortunately - the process determines which subpartition to load to/extract from via a config table), but this applies to not many of the runs. So, the majority of the runs (with fewer rows) go into the default partition.
The query itself scans the index, not the table, doing partition pruning, etc.
The same SQL_ID doesn't mean it's the same plan. So
are you 100% sure that the plans where the same? I
could imagine (see above) that the execution plans
might be different.The DBA looking at it said that the plans were the same, and I have no reason to doubt him. Also, the session browser in Toad shows the same explain plan in the "Current Statement" tab for normal and abnormal runs and is as follows:
Time IO Cost CPU Cost Cardinality Bytes Cost Plan
6 SELECT STATEMENT ALL_ROWS
4 1 4 4 4 82,406 4 1 4 20 4 6 4 HASH UNIQUE
3 1 3 4 3 28,686 3 1 3 20 3 5 3 PARTITION RANGE SINGLE Partition #: 2
2 1 2 4 2 28,686 2 1 2 20 2 5 2 PARTITION LIST SINGLE Partition #: 3
1 1 1 4 1 28,686 1 1 1 20 1 5 1 INDEX RANGE SCAN INDEX TAB_A_IDX Access Predicates: "RUN_ID"=:B3 AND "COB_DATE"=:B2 AND "PARTITION_KEY"=:B1 Partition #: 3
How do you perform your INSERTs? Are overlapping
loads and queries actually working on the same
(sub-)partition of the table or in different ones? Do
you use direct-path inserts or parallel dml?
Direct-path inserts as far I know create "clean"
blocks that do not need a delayed block cleanout.We insert using a select from an external table - there's a parallel hint in there, but I think that is often ignored (at least, I've never seen any hint of sessions running in parallel when looking at the session browser, and I've seen it happen in one of our dev databases, so...). As mentioned above, rows could get inserted into different partitions, although the majority of runs load into the default subpartition. In practise, I don't think more than 3 or 4 loads take place at the same time.
If you loading and querying different partitions then
your queries shouldn't have to check for UNDO except
for the delayed block cleanout case.
You should check at least two important things:
- Are the execution plans different for the slow and
normal executions?
- Get the session statistics (logical I/Os, redo
generated) for the normal and slow ones in order to
see and compare the amount of work that they
generate, and to find out how much redo your query
potentially generated due to delayed block cleanout.It's difficult to do a direct comparison that's exact, due to other work going on in the database, and the abnormal query taking far longer than normal, but here is the ASH comparison between a normal run (1st) and our abnormal run (2nd) (both taken over 90 mins, and the first run may well include other runs that use the same query in the results):
Exec Time of DB Exec Time (ms) #Exec/sec CPU Time (ms) Physical Reads / Exec #Rows Processed
Time / Exec (DB Time) / Exec / Exec
SQL Id 1st 2nd Diff 1st 2nd 1st 2nd 1st 2nd 1st 2nd 1st 2nd Multiple Plans SQL Text
gpgaxqgnssnvt 3.54 15.76 12.23 223,751 1,720,297 0.00 0.00 11,127 49,095 42,333.00 176,565.00 2.67 4.00 No SELECT DISTINCT VALUE_CURRENCY... -
Select query resulting in redo?
Hi All,
Does select query results in redo? In what cases this happens?
Regards,
Sphinxmtefft wrote:
Another possibility is that the SELECT query invokes a PL/SQL function that performs insert, update or delete.
This is a poor practice for a number of reasons but they are out there.
Disagree with that. Proof:
SQL> create table x(y number);
Table created.
SQL> create function f return number as
2 begin
3 insert into x values (2);
4 return 1;
5 end;
6 /
Function created.
SQL> select dummy, f() from dual;
select dummy, f() from dual
ERROR at line 1:
ORA-14551: cannot perform a DML operation inside a query
ORA-06512: at "HR.F", line 3 -
Simple SELECT query to generate INSERT for a table
Hi,
I am looking for a SELECT query which generates INSERT statements for a table.Please guide.
Thanks
PG.Like this?
SQL> SELECT * from kons;
COL1 COL2
1 1
2 2
SQL> SELECT 'INSERT INTO kons VALUES('||col1||','||col2||');' statement FROM kons;
STATEMENT
INSERT INTO kons VALUES(1,1);
INSERT INTO kons VALUES(2,2);
SQL> If you have character and / or date columns you will have to change my example,
but you might get the idea from it.
You can spool the result to a file.
Regards,
Guido
Edit: ';' added to end of statement... -
Must specift the table to select from error in query generator.
SELECT OPCH.CardCode,OPCH.CardName, DateName(month,OPCH.TaxDate) + '-' + DateName(year,OPCH.TaxDate) As [Year],OPCH.TransId as [JE Ref],'IN' As [DocType]
,OPCH.DocEntry As [Base DocEntry],OPCH.WTSUM As [Recieved Amount],((OPCH.WTSUM/110.3) * 100 ) As [Invoice Amount],((OPCH.WTSUM/110.3) * 100 * 0.1) As [Service Tax]
,((OPCH.WTSUM/110.3) * 100 * 0.002) As [Edu.Cess],((OPCH.WTSUM/110.3) * 100 * 0.001) As [S.H.Cess]
,((OPCH.WTSUM/110.3) * 100 * 0.1) + ((OPCH.WTSUM/110.3) * 100 * 0.002) + ((OPCH.WTSUM/110.3) * 100 * 0.001) As [Total Service Tax]
FROM OPCH,PCH1
WHERE OPCH.DocEntry = PCH1.DocEntry
AND OPCH.WTSUM > 0
And PCH1.TargetType <> '19'
AND OPCH.DocDate >= [%0]
AND OPCH.DocDate <= [%1]
When i try to run this query in query generator system gives me error msg as "Must specify table to select from" if i remove the last two lines
" AND OPCH.DocDate >= [%0]
AND OPCH.DocDate <= [%1] "
it works fine in the query generator.
can any one help in this regards,
thanks,
praveenHai Praveen!
This problem is because of [%0] in query.
Declare @FromDate as datetime
Declare @ToDate as datetime
set @FromDate = (select min(opch.docdate) from opch where opch.docdate >= '[%0]')
set @ToDate = (select max(opch.docdate) from opch where opch.docdate <= '[%1]')
Use this query in first lines of ur query and write your query.
SELECT OPCH.CardCode,OPCH.CardName, DateName(month,OPCH.TaxDate) + '-' + DateName(year,OPCH.TaxDate) As Year,OPCH.TransId as JE Ref,'IN' As DocType
,OPCH.DocEntry As Base DocEntry,OPCH.WTSUM As Recieved Amount,((OPCH.WTSUM/110.3) * 100 ) As Invoice Amount,((OPCH.WTSUM/110.3) * 100 * 0.1) As Service Tax
,((OPCH.WTSUM/110.3) * 100 * 0.002) As http://Edu.Cess,((OPCH.WTSUM/110.3) * 100 * 0.001) As http://S.H.Cess
,((OPCH.WTSUM/110.3) * 100 * 0.1) + ((OPCH.WTSUM/110.3) * 100 * 0.002) + ((OPCH.WTSUM/110.3) * 100 * 0.001) As Total Service Tax
FROM OPCH,PCH1
WHERE OPCH.DocEntry = PCH1.DocEntry
AND OPCH.WTSUM > 0
And PCH1.TargetType '19'
AND OPCH.DocDate >= @FromDate
AND OPCH.DocDate <= @ToDate
Regards,
Thanga Raj.K -
How can i update rows in a table based on a match from a select query
Hello
How can i update rows in a table based on a match from a select query fron two other tables with a update using sqlplus ?
Thanks Glenn
table1
attribute1 varchar2 (10)
attribute2 varchar2 (10)
processed varchar2 (10)
table2
attribute1 varchar2 (10)
table3
attribute2 varchar2 (10)
An example:
set table1.processed = "Y"
where (table1.attribute1 = table2.attribute1)
and (table1.attribute2 = table3.attribute2)Hi,
Etbin wrote:
Hi, Frank
taking nulls into account, what if some attributes are null ;) then the query should look like
NOT TESTED !
update table1 t1
set processed = 'Y'
where exists(select null
from table2
where lnnvl(attribute1 != t1.attribute1)
and exists(select null
from table3
where lnnvl(attribute2 != t1.attribute2)
and processed != 'Y'Regards
EtbinYes, you could do that. OP specifically requested something else:
wgdoig wrote:
set table1.processed = "Y"
where (table1.attribute1 = table2.attribute1)
and (table1.attribute2 = table3.attribute2)This WHERE clause won't be TRUE if any of the 4 attribute columns are NULL. It's debatable about what should be done when those columns are NULL.
But there is no argument about what needs to be done when processed is NULL.
OP didn't specifically say that the UPDATEshould or shouldn't be done on rows where processed was already 'Y'. You (quite rightly) introduced a condition that would prevent redo from being generated and triggers from firing unnecessarily; I'm just saying that we have to be careful that the same condition doesn't keep the row from being UPDATEd when it is necessary. -
Getting deadlock detected while waiting for resource error for select Query.....
Hi all,
i am getting a below error whenever executing the below select query....
some times it will show dead lock detected while waiting for resource and terminated...
some times it executes and gives result..
but all the time it writes an alert to alert log
Plesae suggest how to resolve the issue..........
Thanks in advance
Env: Linux / Oracle 11.2.0.3.3
Error from alert log:
Errors in file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc:
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
Trace file info... bdrdb_p017_6076.trc:
Trace file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name: bdrdb.cteplindia.com
Release: 2.6.18-308.el5PAE
Version: #1 SMP Fri Jan 27 17:40:09 EST 2012
Machine: i686
Instance name: bdrdb
Redo thread mounted by this instance: 1
Oracle process number: 92
Unix process pid: 6076, image: [email protected] (P017)
*** 2013-11-04 23:18:57.915
*** SESSION ID:(423.59970) 2013-11-04 23:18:57.915
*** CLIENT ID:() 2013-11-04 23:18:57.915
*** SERVICE NAME:(bdrdb) 2013-11-04 23:18:57.915
*** MODULE NAME:() 2013-11-04 23:18:57.915
*** ACTION NAME:() 2013-11-04 23:18:57.915
*** 2013-11-04 23:18:57.915
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
Rows waited on:
Session 423: no row
Session 128: obj - rowid = 00021DC1 - AAAh3BAAVAAAQL/AAA
(dictionary objn - 138689, file - 21, block - 66303, slot - 0)
----- Information for the OTHER waiting sessions -----
Session 128:
sid: 128 ser: 46176 audsid: 1836857 user: 102/DBLOCAL
flags: (0x8000041) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 33 O/S info: user: oracle, term: UNKNOWN, ospid: 31611
image: [email protected]
client details:
O/S info: user: masked, term: masked, ospid: 5924:568
machine: masked program: Toad.exe
application name: TOAD background query session, hash value=526966934
current SQL:
application name: TOAD background query session, hash value=526966934
current SQL:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = :"SYS_B_00"
AND B_FP_TEST.TEST_NUM NOT IN (:"SYS_B_01", :"SYS_B_02", :"SYS_B_03")
AND L_ATMS_TEST_TYPE.IS_DELETED = :"SYS_B_04"
AND J_FP_INVESTIGATOR.is_pi = :"SYS_B_05"
AND L_TEST_STATUS.STATUS IN (:"SYS_B_06", :"SYS_B_07", :"SYS_B_08")
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
----- End of information for the OTHER waiting sessions -----
*** 2013-11-04 23:18:57.916
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
More......
Query:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = 0
AND B_FP_TEST.TEST_NUM NOT IN (1, 2, 99)
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND J_FP_INVESTIGATOR.is_pi = 1
AND L_TEST_STATUS.STATUS IN ('Scheduled', 'In-Progress', 'Completed')
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
AND ( (j_op_test_anml.end_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (j_op_test_anml.start_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (TO_DATE ('28-Oct-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date)
OR (TO_DATE ('04-Nov-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date))
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND B_FP_TEST.DATASOURCE_ID = 9
Query Exp plan:
Plan hash value: 3398228788
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 1 | HASH UNIQUE | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 2 | CONCATENATION | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ30005 | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | P->S | QC (RAND) |
|* 5 | HASH JOIN | | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 6 | PX RECEIVE | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 7 | PX SEND HASH | :TQ30004 | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | P->P | HASH |
|* 8 | HASH JOIN | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 9 | PX RECEIVE | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 10 | PX SEND HASH | :TQ30003 | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | P->P | HASH |
|* 11 | HASH JOIN | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | PCWP | |
| 12 | BUFFER SORT | | | | | | | | Q3,03 | PCWC | |
| 13 | PX RECEIVE | | | | | | | | Q3,03 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ30000 | | | | | | | | S->P | BROADCAST |
| 15 | NESTED LOOPS | | | | | | | | | | |
| 16 | NESTED LOOPS | | 485 | 20855 | 781 (0)| 00:00:10 | | | | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID| J_OP_TEST_ANML | 485 | 10185 | 296 (0)| 00:00:04 | ROWID | ROWID | | | |
|* 18 | INDEX RANGE SCAN | IDX$$_2D190001 | 485 | | 4 (0)| 00:00:01 | | | | | |
|* 19 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 20 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 21 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWC | |
|* 22 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWP | |
| 23 | BUFFER SORT | | | | | | | | Q3,04 | PCWC | |
| 24 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q3,04 | PCWP | |
| 25 | PX SEND HASH | :TQ30001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 26 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
| 27 | BUFFER SORT | | | | | | | | Q3,05 | PCWC | |
| 28 | PX RECEIVE | | 30 | 150 | 3 (0)| 00:00:01 | | | Q3,05 | PCWP | |
| 29 | PX SEND HASH | :TQ30002 | 30 | 150 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 30 | TABLE ACCESS FULL | L_ATMS_TEST_TYPE | 30 | 150 | 3 (0)| 00:00:01 | | | | | |
| 31 | NESTED LOOPS | | | | | | | | | | |
| 32 | NESTED LOOPS | | 3 | 210 | 329 (1)| 00:00:04 | | | | | |
| 33 | NESTED LOOPS | | 3 | 195 | 329 (1)| 00:00:04 | | | | | |
|* 34 | HASH JOIN | | 2 | 114 | 325 (1)| 00:00:04 | | | | | |
| 35 | NESTED LOOPS | | | | | | | | | | |
| 36 | NESTED LOOPS | | 6 | 258 | 322 (1)| 00:00:04 | | | | | |
| 37 | PARTITION RANGE SINGLE | | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 38 | TABLE ACCESS FULL | J_OP_TEST_ANML | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 39 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 40 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
|* 41 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | J_FP_INVESTIGATOR | 1 | 8 | 2 (0)| 00:00:01 | | | | | |
|* 43 | INDEX RANGE SCAN | FI_TEST_ID_PK | 1 | | 1 (0)| 00:00:01 | | | | | |
|* 44 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 45 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | | | |
| 46 | PX COORDINATOR | | | | | | | | | | |
| 47 | PX SEND QC (RANDOM) | :TQ20003 | | | | | | | Q2,03 | P->S | QC (RAND) |
| 48 | NESTED LOOPS | | | | | | | | Q2,03 | PCWP | |
| 49 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q2,03 | PCWP | |
|* 50 | HASH JOIN | | 33 | 2145 | 397 (2)| 00:00:05 | | | Q2,03 | PCWP | |
| 51 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,03 | PCWP | |
| 52 | PX SEND HASH | :TQ20002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | P->P | HASH |
|* 53 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | PCWP | |
| 54 | BUFFER SORT | | | | | | | | Q2,02 | PCWC | |
| 55 | PX RECEIVE | | | | | | | | Q2,02 | PCWP | |
| 56 | PX SEND BROADCAST | :TQ20000 | | | | | | | | S->P | BROADCAST |
| 57 | NESTED LOOPS | | | | | | | | | | |
| 58 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 59 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 60 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 61 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 62 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 63 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWC | |
|* 64 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWP | |
| 65 | BUFFER SORT | | | | | | | | Q2,03 | PCWC | |
| 66 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 67 | PX SEND HASH | :TQ20001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 68 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 69 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q2,03 | PCWP | |
|* 70 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 71 | PX COORDINATOR | | | | | | | | | | |
| 72 | PX SEND QC (RANDOM) | :TQ10003 | | | | | | | Q1,03 | P->S | QC (RAND) |
| 73 | NESTED LOOPS | | | | | | | | Q1,03 | PCWP | |
| 74 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q1,03 | PCWP | |
|* 75 | HASH JOIN | | 34 | 2210 | 397 (2)| 00:00:05 | | | Q1,03 | PCWP | |
| 76 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,03 | PCWP | |
| 77 | PX SEND HASH | :TQ10002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | P->P | HASH |
|* 78 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | PCWP | |
| 79 | BUFFER SORT | | | | | | | | Q1,02 | PCWC | |
| 80 | PX RECEIVE | | | | | | | | Q1,02 | PCWP | |
| 81 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 82 | NESTED LOOPS | | | | | | | | | | |
| 83 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 84 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 85 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 86 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 87 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 88 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWC | |
|* 89 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 90 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 91 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 92 | PX SEND HASH | :TQ10001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 93 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 94 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP | |
|* 95 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
5 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
8 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
11 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
18 - access("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
19 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
20 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
22 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
26 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
30 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
34 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
38 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
39 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
40 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
41 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
42 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
43 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
44 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
45 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
50 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
53 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
60 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
61 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
62 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
64 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
68 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
69 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
70 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
75 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
78 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
85 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-10-28
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
(LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
86 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
87 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
89 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
93 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
94 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
95 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)Excellent piece of follow-up on my first suggestion.
I nearly made a comment about how the plan doesn't show Bloom filter pruning either - and then I realised why not. The plan you've shown us comes from Explain Plan with literal values present; the trace file shows bind variables with names that are generated when cursor_sharing is set to force or similar - so the run-time plan and the plan from explain plan are almost guaranteed to be different.
Oracle support will need you to supply the plan you get from trying to run the query and then making a call to dbms_xplan.display_cursor() - dbms_xplan in 10g | Oracle Scratchpad If you do this I think you'll find that the pstart/pstop columns contain entries like :BF0000, and you may even find operations link PX JOIN FILTER CREATE / PX JOIN FILTER USE
A couple of generic notes:
if a query does sufficient work to merit parallel execution, then it's usually better to supply the best possible information to the optimizer, which means using literals rather than bind variables - you could try executing the query with the hint /*+ cursor_sharing_exact */ to stop Oracle from turning your literals into binds; it might be the presence of bind variables that's making the optimizer choose a path that has to include bloom filter pruning in your case.
Where you have the to_date() call you've used a four-digit year - which is a very good thing and helps the optimizer - but it's also a good idea to include an explicit format string as well: with a four-digit year this probably won't make any difference, but it avoids any risk of ambiguity for the optimizer.
I made a comment about the P->S stage and bottlenecks - I spent a couple more minutes looking at the plan, and I see the optimizer has used concatentation: in effect it has run three query blocks one after the other and fed the results to the query co-ordinator - in this case the P->S would make no difference to the end-user response time there's always a final P->S to the coordinator, you just happen to have three of them.
Regards
Jonathan Lewis -
Oracle SQL Select query takes long time than expected.
Hi,
I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
The query is as follows.
select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
Kindly advice what is going wrong??
Regards,
PurushothamSQL> @/alcatel/omc1/data/query.sql
2 ;
9 rows selected.
Execution Plan
Plan hash value: 3745571015
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | SORT ORDER BY | |
| 2 | NESTED LOOPS | |
| 3 | NESTED LOOPS | |
| 4 | TABLE ACCESS FULL | PARAMETERTABLE |
|* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
|* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
|* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
|* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
Predicate Information (identified by operation id):
5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
6 - access("P1"."ID"="F1"."ID")
7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
8 - access("F1"."ID"="ID")
Note
- rule based optimizer used (consider using cbo)
Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed
SQL> -
CAN WE HAVE IF CONDITION IN QUERY GENERATOR
Hi friends,
am, trying to make use of if condition to obtain a set of values in query generator. Its possible to retrieve the required result set using query analyser but not in query generator. am trying to execute the following query
if exists (select owor.u_reactor from owor,oitt where oitt.code=owor.itemcode and owor.u_reactor = 1 and owor.itemcode = '100-100')
begin
select itt1.u_reactor1 from oitt,itt1 where itt1.father = oitt.code and itt1.father = '100-100'
end
else
if exists (select owor.u_reactor from owor,oitt where oitt.code=owor.itemcode and owor.u_reactor = 2 and owor.itemcode = '100-100')
begin
select itt1.u_reac_23 from oitt,itt1 where itt1.father = oitt.code and itt1.father = '100-100'
end
else
if exists (select owor.u_reactor from owor,oitt where oitt.code=owor.itemcode and owor.u_reactor = 3 and owor.itemcode = '100-100')
begin
select itt1.u_reactor4 from oitt,itt1 where itt1.father = oitt.code and itt1.father = '100-100'
end
if it is not possible to write such query in query generator can someone help me with a workaround solution.
Thank u
VaitheeswaranHi,
I dont think Nested IF Statements are allowed in PLD. The reason that u get the result in Query analyser and not in Query Generator is that SAP supports Transact SQL and many SQL Server 2000 functions are not supported.
However there is a work around in Print Layout Designer for using IF condition by having Linked Objects. Kindly see some tutorials regarding Linked fields available on SDN site and think of some other way of implementing this nested IF query.
Regards
Rizwan Hafeez
Team Lead
SAP Addon Development Section
Abacus Consulting - Pakistan -
How to do this in Query Generator?
Dear Experts,
Please check my following query I've written in Query Generator.
/* select from dbo.OCRD t0 */
declare @BP nvarchar(20)
set @BP=/* t0.CardName */ '[%0]'
declare @Dt1 datetime
declare @Dt2 datetime
set @Dt1=/* Start Date */ [%1]
set Dt2=[%2]
select distinct t1.po, Max(t1.supplier) Supplier,Max(t1.process) Process, Max(t1.OrderNo) OrderNo,Max(t1.Date) Date,
isnull((select sum(t2.Quantity) from dbo.ir t2 where t2.po=t1.po and t2.TType<0),0) Issued,
isnull((select sum(t3.Quantity) from dbo.ir t3 where t3.po=t1.po and t3.TType>0),0) Received,
isnull((select sum(t2.Quantity) from dbo.ir t2 where t2.po=t1.po and t2.TType<0),0)-isnull((select sum(t3.Quantity) from dbo.ir t3 where t3.po=t1.po and t3.TType>0),0) Balance
from dbo.ir t1 where t1.Supplier=@BP and (t1.Date>=@Dt1 and t1.Date<=@Dt2) group by t1.po
The Query works well. But for the the lines
set @Dt1=/* Start Date */ [%1]
set Dt2=[%2]
it displays BP Code as the prompt next the text boxes meant for inputting dates. I would like to display 'Start Date' and 'End Date' respectively for Dt1 and Dt2.
Please explain me how to go about it.
Thanks in advance.
Regards
Ananddeclare @Dt1 datetime
set @Dt1=/* Start Date */ [%0]
declare @Dt2 datetime
set @Dt2=/* End Date */ [%1]
/* select from dbo.OCRD t0 */
declare @BP nvarchar(20)
set @BP=/* t0.CardName */ '[%2]'
I've changed. When I run the query the input box does not appear, the query shows only a blank table.
Thanks
Anand -
How to define the PLD of a Query generator report
Hi All,
I want to define the PLD of a Query Report. Currently I am Convertning it to Excel format. But my client wants it in PLD format. so please tell me the process of defining the PLD for a Query generator Report.
Thanks & Regards
Pankaj Sharma.Hi,
When u wrote yr query at that time save yr query
Now yr query is save in "Query Manager"
Open Query Manager > select yr query
There is a button "Create Report"
Create USer Report Window is display "define yr name" and select "Base Temple"
once u save it double click and edit yr PLD....
Hope it a best way to create uer PLD
Thanks
Kevin -
Dear all,
I face an issue in Query generator.
When i execute the query in query generator, the error is like this
1). [Microsoft][SQL Server Native Client 10.0][SQL Server]Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.
'Service Contracts' (OCTR)
My query is like this
Declare @StartYear as char(4)
Declare @EndYear as char(4)
Declare @Dept as char(3)
Declare @UnitBusiness as char(3)
Begin
set @StartYear = (Select YEAR(T0.[RefDate]) from JDT1 T0 where T0.[RefDate] = [%0] )
set @EndYear = (Select YEAR(T1.[RefDate]) from JDT1 T1 where T1.[RefDate] = [%1])
set @Dept = (Select T2.[Name] from OASC T2 where T2.[Name] = [%2])
set @UnitBusiness = (Select distinct SUBSTRING(T3.[Segment_0],10,2) from OACT T3 where ( T3.[Segment_0] = [%3] OR ( 1 = (CASE WHEN [%3] = 'All' THEN 1 ELSE 2 END) ) ))
Exec NEC_RPT_FinanceReport @StartYear,@EndYear,@Dept,@UnitBusiness
End
The problem is i can not show the input screen after i execute the query generator.
If i remove the the Variable @Dept and replace with the value it runs well.
Does any one know where is the problem ?
Thanks in advance
Regards
Bodhi86HI Neetu, i have change the query without using store procedure
my query is like this
Declare @StartYear as char(4)
Declare @EndYear as char(4)
Declare @Dept as char(3)
Declare @UnitBusiness as char(3)
Begin
set @StartYear = (Select YEAR(T0.[RefDate]) from JDT1 T0 where T0.[RefDate] = [%0] )
set @EndYear = (Select YEAR(T1.[RefDate]) from JDT1 T1 where T1.[RefDate] = [%1])
set @Dept = (Select T2.[Name] from OASC T2 where T2.[Name] = [%2])
set @UnitBusiness = (Select distinct SUBSTRING(T3.[Segment_0],10,2) from OACT T3 where ( T3.[Segment_0] = [%3] OR ( 1 = (CASE WHEN [%3] = 'All' THEN 1 ELSE 2 END) ) ))
Select @StartYear,@EndYear,@Dept,@UnitBusiness
The error is like this
1). [Microsoft][SQL Server Native Client 10.0][SQL Server]Must specify table to select from.
2). [Microsoft][SQL Server Native Client 10.0][SQL Server]Statement 'User-Defined Values' (CSHS) (s) could not be prepared.
Can you help me
Thanks in advance -
Decimal places in Query generator
Hi All,
I am observing a weird behavior in Query generator's execution of a simple sql query. the query is :
Select 0.002834
now, in the general settings - display - amounts , I put the decimal value as 4 or 6, then only it prints 0.0028 or 0.002834.
else it prints 0.00 (if the decimal place is 2). it should ideally have nothing to do with the display of amount. any idea?
(the effect is shown only after you change the decimal display, update it and close and reopen the SAP application.
Thanks,
Binita
Edited by: Binita Joshi on Apr 12, 2010 4:03 PMHello Binita,
>I have tried converting it to numeric(19,4) and numeric(19,6) but still the result was same.
Check your decimal places settings in
\Administration\System Initialization\General Settings\Display tab
Check the following values:
- Units (For meaurement)
- Decimals in Query
Now let' s say,
- Unit set to 6 decimal places
- Decimals in Query set to 2
run the following query in query generator:
select cast(0.000245 as decimal(19,6))
result will be
0.00
run the same query as FMS on item master data in any measurement field (lenght)
select cast(0.000245 as decimal(19,6))
result will be
0.000245
Now set the - Decimals in Query set to 6 on \Administration\System Initialization\General Settings\Display tab
run the following query in query generator:
select cast(0.000245 as decimal(19,6))
result will be
0.000245
This is a normal habit of SAP B1 rounding engine / displaying engine.
Regards
J.
Maybe you are looking for
-
Problem loading AVI with vision
I started building a gait analysis program, and got stuck with the following. Whenever I load AVI files into labview (using IMAQ AVI READ FRAME) it displays about a dozen frames, then I get Error 1074395975: IMAQ Vision: DirectX has timed out readi
-
Which visual studio on Microsoft need to be downloaded for design and programming video games?
I found only for developing of apps
-
We have analog phones in certain applications that use a neon light instead of a ring tone. It requires 90v to activate the neon light. We have VG224 analog gateways which appear to not be able to push 90v. Does anyone have a solution or is there a
-
How do I keep Firefox from saving bank account data?
How do I keep Firefox from saving bank account data? I'm running Win7 64-bit. I can't seem to keep Firefox from saving bank account data.
-
Start managed servers via admin console
Hello, I have installed weblogic server, created a domain, added a managed server. All working fine. Now I want to be able to start managed server through admin console. According to this documentation (http://docs.oracle.com/cd/E13222_01/wls/docs81/