Execution plan of query
Hi all,
There is a statement:
For example for qid=-4 takes 3 min 20 sec.
SELECT id, org, count(aa) cnt
FROM (SELECT DISTINCT id, org, aa
FROM zzz_temp_nn, molfrelflat, (SELECT DISTINCT m.prot aa, nvl
(org, 0) org, molf tid FROM molfprot m, (SELECT DISTINCT prot, org FROM
protorgs WHERE trust >= 0 AND decode(org, 0, 0, 1) = 1) o WHERE m.prot
= o.prot(+))
WHERE qid = -4 AND id = molfgrp AND molfmbr = tid)
GROUP BY id, org
no rows selected
Elapsed: 00:03:20.41
Execution plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 39 | 29 (7)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 39 | 29 (7)| 00:00:01 |
| 2 | VIEW | | 1 | 39 | 28 (4)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 133 | 28 (4)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 133 | 27 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 128 | 26 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 123 | 25 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 118 | 24 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 113 | 23 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 102 | 21 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 91 | 19 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 80 | 17 (0)| 00:00:01 |
| 12 | NESTED LOOPS OUTER | | 1 | 69 | 15 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 54 | 12 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 38 | 4 (0)| 00:00:01 |
|* 15 | TABLE ACCESS FULL | ZZZ_TEMP_NN | 1 | 26 | 2 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | UNITRELFLAT_UI_UNITG_UNITM | 3 | 114 | 2 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID| UNITRELS | 1 | 16 | 8 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | UNITRELS_I_UNITG | 15 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | PROTORGS | 1 | 15 | 3 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | PROTORGS_UI_PROT_ORG_TIS_LOC | 1 | | 2 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 1 | 11 | 2 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 1 | 11 | 2 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 1 | 11 | 2 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 1 | 11 | 2 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 1 | 5 | 1 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | KND_UNITS_PK | 1 | | 0 (0)| 00:00:01 |
|* 27 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 1 | 5 | 1 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | KND_UNITS_PK | 1 | | 0 (0)| 00:00:01 |
|* 29 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 1 | 5 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | KND_UNITS_PK | 1 | | 0 (0)| 00:00:01 |
|* 31 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 1 | 5 | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | KND_UNITS_PK | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
15 - filter("QID"=(-4))
16 - access("ID"="R"."UNITG")
17 - filter("R"."TYPE"=0)
18 - access("R"."UNITM"="R"."UNITG")
19 - filter("TRUST"(+)>=0)
20 - access("R"."UNITM"="PROT"(+))
filter(DECODE("ORG"(+),0,0,1)=1)
21 - access("R"."UNITG"="UG"."ID")
22 - access("R"."UNITM"="UM"."ID")
23 - access("R"."UNITM"="UM"."ID")
24 - access("R"."UNITG"="UG"."ID")
25 - filter("KG"."TREE"=1)
26 - access("UG"."TYPE"="KG"."ID")
27 - filter("KM"."TREE"=0)
28 - access("UM"."TYPE"="KM"."ID")
29 - filter("KG"."TREE"=1)
30 - access("UG"."TYPE"="KG"."ID")
31 - filter("KM"."TREE"=1)
32 - access("UM"."TYPE"="KM"."ID")
molfrelflat, molfprot - are views.
Molfrelflat:
SELECT r.unitg as molfgrp, r.unitm as molfmbr, r.dist, r.spl
FROM unitrelflat r, units ug, knd_units kg, units um, knd_units km
WHERE r.unitg = ug.id and ug.type = kg.id and kg.tree = 1 and
r.unitm = um.id and um.type = km.id and km.tree = 1
Molfprot:
SELECT r.unitg as molf, r.unitm as prot
FROM unitrels r, units ug, knd_units kg, units um, knd_units km
WHERE r.type = 0 and
r.unitg = ug.id and ug.type = kg.id and kg.tree = 1 and
r.unitm = um.id and um.type = km.id and km.tree = 0
SELECT table_name,num_rows,last_analyzed
FROM user_tables
WHERE table_name in ('UNITRELS','UNITRELFLAT','KND_UNITS','UNITS');Which way to disassemble a query? Thanks in advance.
Best regards, Pavel.
Why E-Rows not equal to A-Rows after gather stats on index?
SQL> exec dbms_stats.gather_index_stats(user,'UNITRELFLAT_UI_UNITG_UNITM');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_index_stats(user,'UNITRELS_I_UNITG');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_index_stats(user,'PROTORGS_UI_PROT_ORG_TIS_LOC');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_index_stats(user,'UNITS_UI_ID_TYPE');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_index_stats(user,'KND_UNITS_PK');
PL/SQL procedure successfully completed.
SELECT /*+ gather_plan_statistics */id, org, count(aa) cnt
FROM (SELECT DISTINCT id, org, aa
FROM zzz_temp_nn, molfrelflat, (SELECT DISTINCT m.prot aa, nvl
(org, 0) org, molf tid FROM molfprot m, (SELECT DISTINCT prot, org FROM
protorgs WHERE trust >= 0 and decode(org,0,0,1)=1) o WHERE m.prot
= o.prot(+))
WHERE qid = 1 AND id = molfgrp AND molfmbr = tid)
8 GROUP BY id, org;
ID ORG CNT
-4 8 18921
-4 0 6
-4 1 16229
-4 9 13744
SQL> select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID d63q3xdmxnun3, child number 0
SELECT /*+ gather_plan_statistics */id, org, count(aa) cnt FROM (SELECT DISTINCT id, org, aa FROM zzz_temp_nn, molfrelflat, (SELECT DISTINCT
m.prot aa, nvl (org, 0) org, molf tid FROM molfprot m, (SELECT DISTINCT prot, org FROM protorgs WHERE trust >= 0 and decode(org,0,0,1)=1) o WHERE
m.prot = o.prot(+)) WHERE qid = 1 AND id = molfgrp AND molfmbr = tid) GROUP BY id, org
Plan hash value: 4002351125
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
| 1 | HASH GROUP BY | | 1 | 1 | 4 |00:00:59.57 | 49M| 1049K| 1049K| 445K (0)|
| 2 | VIEW | | 1 | 1 | 48900 |00:00:59.58 | 49M| | | |
| 3 | HASH UNIQUE | | 1 | 1 | 48900 |00:00:59.53 | 49M| 2745K| 1417K| 2700K (0)|
| 4 | NESTED LOOPS | | 1 | 1 | 3955K|00:04:17.09 | 49M| | | |
| 5 | NESTED LOOPS | | 1 | 1 | 3965K|00:03:53.96 | 45M| | | |
| 6 | NESTED LOOPS | | 1 | 1 | 3965K|00:03:26.20 | 41M| | | |
| 7 | NESTED LOOPS | | 1 | 1 | 3965K|00:02:54.48 | 37M| | | |
| 8 | NESTED LOOPS | | 1 | 1 | 3967K|00:02:30.76 | 33M| | | |
| 9 | NESTED LOOPS | | 1 | 1 | 3967K|00:01:59.02 | 25M| | | |
| 10 | NESTED LOOPS | | 1 | 1 | 3967K|00:01:27.28 | 17M| | | |
| 11 | NESTED LOOPS | | 1 | 1 | 3967K|00:00:55.54 | 10M| | | |
| 12 | NESTED LOOPS OUTER | | 1 | 1 | 3967K|00:00:19.84 | 2107K| | | |
| 13 | NESTED LOOPS | | 1 | 1 | 168K|00:00:01.35 | 196K| | | |
| 14 | NESTED LOOPS | | 1 | 3 | 58463 |00:00:00.06 | 490 | | | |
|* 15 | TABLE ACCESS FULL | ZZZ_TEMP_NN | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 16 | INDEX RANGE SCAN | UNITRELFLAT_UI_UNITG_UNITM | 1 | 3 | 58463 |00:00:00.01 | 487 | | | |
|* 17 | TABLE ACCESS BY INDEX ROWID| UNITRELS | 58463 | 1 | 168K|00:00:01.62 | 196K| | | |
|* 18 | INDEX RANGE SCAN | UNITRELS_I_UNITG | 58463 | 15 | 168K|00:00:00.58 | 118K| | | |
|* 19 | TABLE ACCESS BY INDEX ROWID | PROTORGS | 168K| 1 | 3956K|00:00:22.46 | 1911K| | | |
|* 20 | INDEX RANGE SCAN | PROTORGS_UI_PROT_ORG_TIS_LOC | 168K| 1 | 3956K|00:00:05.81 | 353K| | | |
|* 21 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 3967K| 1 | 3967K|00:00:30.50 | 7935K| | | |
|* 22 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 3967K| 1 | 3967K|00:00:25.61 | 7947K| | | |
|* 23 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 3967K| 1 | 3967K|00:00:24.71 | 7947K| | | |
|* 24 | INDEX RANGE SCAN | UNITS_UI_ID_TYPE | 3967K| 1 | 3967K|00:00:28.33 | 7947K| | | |
|* 25 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 3967K| 1 | 3965K|00:00:29.12 | 3967K| | | |
|* 26 | INDEX UNIQUE SCAN | KND_UNITS_PK | 3967K| 1 | 3967K|00:00:10.57 | 470 | | | |
|* 27 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 3965K| 1 | 3965K|00:00:23.86 | 3965K| | | |
|* 28 | INDEX UNIQUE SCAN | KND_UNITS_PK | 3965K| 1 | 3965K|00:00:09.29 | 470 | | | |
|* 29 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 3965K| 1 | 3965K|00:00:22.90 | 3965K| | | |
|* 30 | INDEX UNIQUE SCAN | KND_UNITS_PK | 3965K| 1 | 3965K|00:00:09.06 | 470 | | | |
|* 31 | TABLE ACCESS BY INDEX ROWID | KND_UNITS | 3965K| 1 | 3955K|00:00:22.74 | 3965K| | | |
|* 32 | INDEX UNIQUE SCAN | KND_UNITS_PK | 3965K| 1 | 3965K|00:00:09.22 | 470 | | | |
Predicate Information (identified by operation id):
15 - filter("QID"=1)
16 - access("ID"="R"."UNITG")
17 - filter("R"."TYPE"=0)
18 - access("R"."UNITM"="R"."UNITG")
19 - filter("TRUST">=0)
20 - access("R"."UNITM"="PROT")
filter(DECODE("ORG",0,0,1)=1)
21 - access("R"."UNITG"="UG"."ID")
22 - access("R"."UNITG"="UG"."ID")
23 - access("R"."UNITM"="UM"."ID")
24 - access("R"."UNITM"="UM"."ID")
25 - filter("KM"."TREE"=1)
26 - access("UM"."TYPE"="KM"."ID")
27 - filter("KG"."TREE"=1)
28 - access("UG"."TYPE"="KG"."ID")
29 - filter("KG"."TREE"=1)
30 - access("UG"."TYPE"="KG"."ID")
31 - filter("KM"."TREE"=0)
32 - access("UM"."TYPE"="KM"."ID")
Note
-----
Similar Messages
-
Unable to generate an execution plan for query
Hi,
I created 4 dimension and two measures ,but while Iam trying to create a presentation bean thru' jdeveloper it is throwing an error "unable to Create olap cursor.
My cubes as well as all of my dimensions are getting validated.
Can anybody help me in resolving thisHi Yann,
You OLAP metadata may be corrupted. Can you please run the bi_checkconfig utility, which can be found here:
http://otn.oracle.com/products/bib/htdocs/tech_notes/bi_checkconfig_tn.html
Hope this helps,
Katia -
How do i see query EXECUTION PLAN
Dear Experts ,
I'm using Toad, PL/SQL developer and working on very big query but its response is very slow could u please guide any one HOW I SEE EXECUTION PLAN of query to optimize further.
Faheem Latif
NetSol Technologies Limited Pakistan.
www.netsoltek.com, www.leasesoft.bizDear ,
Thank's for reply but it is showing this error.
"ORA-02404: specified plan table not found"
Faheem Latif
NetSol Technologies Limited Pakistan.
www.netsoltek.com, www.leasesoft.biz -
Query optimization - Query is taking long time even there is no table scan in execution plan
Hi All,
The below query execution is taking very long time even there are all required indexes present.
Also in execution plan there is no table scan. I did a lot of research but i am unable to find a solution.
Please help, this is required very urgently. Thanks in advance. :)
WITH cte
AS (
SELECT Acc_ex1_3
FROM Acc_ex1
INNER JOIN Acc_ex5 ON (
Acc_ex1.Acc_ex1_Id = Acc_ex5.Acc_ex5_Id
AND Acc_ex1.OwnerID = Acc_ex5.OwnerID
WHERE (
cast(Acc_ex5.Acc_ex5_92 AS DATETIME) >= '12/31/2010 18:30:00'
AND cast(Acc_ex5.Acc_ex5_92 AS DATETIME) < '01/31/2014 18:30:00'
SELECT DISTINCT R.ReportsTo AS directReportingUserId
,UC.UserName AS EmpName
,UC.EmployeeCode AS EmpCode
,UEx1.Use_ex1_1 AS PortfolioCode
SELECT TOP 1 TerritoryName
FROM UserTerritoryLevelView
WHERE displayOrder = 6
AND UserId = R.ReportsTo
) AS BranchName
,GroupsNotContacted AS groupLastContact
,GroupCount AS groupTotal
FROM ReportingMembers R
INNER JOIN TeamMembers T ON (
T.OwnerID = R.OwnerID
AND T.MemberID = R.ReportsTo
AND T.ReportsTo = 1
INNER JOIN UserContact UC ON (
UC.CompanyID = R.OwnerID
AND UC.UserID = R.ReportsTo
INNER JOIN Use_ex1 UEx1 ON (
UEx1.OwnerId = R.OwnerID
AND UEx1.Use_ex1_Id = R.ReportsTo
INNER JOIN (
SELECT Accounts.AssignedTo
,count(DISTINCT Acc_ex1_3) AS GroupCount
FROM Accounts
INNER JOIN Acc_ex1 ON (
Accounts.AccountID = Acc_ex1.Acc_ex1_Id
AND Acc_ex1.Acc_ex1_3 > '0'
AND Accounts.OwnerID = 109
GROUP BY Accounts.AssignedTo
) TotalGroups ON (TotalGroups.AssignedTo = R.ReportsTo)
INNER JOIN (
SELECT Accounts.AssignedTo
,count(DISTINCT Acc_ex1_3) AS GroupsNotContacted
FROM Accounts
INNER JOIN Acc_ex1 ON (
Accounts.AccountID = Acc_ex1.Acc_ex1_Id
AND Acc_ex1.OwnerID = Accounts.OwnerID
AND Acc_ex1.Acc_ex1_3 > '0'
INNER JOIN Acc_ex5 ON (
Accounts.AccountID = Acc_ex5.Acc_ex5_Id
AND Acc_ex5.OwnerID = Accounts.OwnerID
WHERE Accounts.OwnerID = 109
AND Acc_ex1.Acc_ex1_3 NOT IN (
SELECT Acc_ex1_3
FROM cte
GROUP BY Accounts.AssignedTo
) TotalGroupsNotContacted ON (TotalGroupsNotContacted.AssignedTo = R.ReportsTo)
WHERE R.OwnerID = 109
Please mark it as an answer/helpful if you find it as useful. Thanks, Satya Prakash JugranHi All,
Thanks for the replies.
I have optimized that query to make it run in few seconds.
Here is my final query.
select ReportsTo as directReportingUserId,
UserName AS EmpName,
EmployeeCode AS EmpCode,
Use_ex1_1 AS PortfolioCode,
BranchName,
GroupInfo.groupTotal,
GroupInfo.groupLastContact,
case when exists
(select 1 from ReportingMembers RM
where RM.ReportsTo = UserInfo.ReportsTo
and RM.MemberID <> UserInfo.ReportsTo
) then 0 else UserInfo.ReportsTo end as memberid1,
(select code from Regions where ownerid=109 and name=UserInfo.BranchName) as BranchCode,
ROW_NUMBER() OVER (ORDER BY directReportingUserId) AS ROWNUMBER
FROM
(select distinct R.ReportsTo, UC.UserName, UC.EmployeeCode,UEx1.Use_ex1_1,
(select top 1 TerritoryName
from UserTerritoryLevelView
where displayOrder = 6
and UserId = R.ReportsTo) as BranchName,
Case when R.ReportsTo = Accounts.AssignedTo then Accounts.AssignedTo else 0 end as memberid1
from ReportingMembers R
INNER JOIN TeamMembers T ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo AND T.ReportsTo = 1)
inner join UserContact UC on (UC.CompanyID = R.OwnerID and UC.UserID = R.ReportsTo )
inner join Use_ex1 UEx1 on (UEx1.OwnerId = R.OwnerID and UEx1.Use_ex1_Id = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
union
select distinct R.ReportsTo, UC.UserName, UC.EmployeeCode,UEx1.Use_ex1_1,
(select top 1 TerritoryName
from UserTerritoryLevelView
where displayOrder = 6
and UserId = R.ReportsTo) as BranchName,
Case when R.ReportsTo = Accounts.AssignedTo then Accounts.AssignedTo else 0 end as memberid1
from ReportingMembers R
--INNER JOIN TeamMembers T ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo)
inner join UserContact UC on (UC.CompanyID = R.OwnerID and UC.UserID = R.ReportsTo)
inner join Use_ex1 UEx1 on (UEx1.OwnerId = R.OwnerID and UEx1.Use_ex1_Id = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
where R.MemberID = 1
) UserInfo
inner join
select directReportingUserId, sum(Groups) as groupTotal, SUM(GroupsNotContacted) as groupLastContact
from
select distinct R.ReportsTo as directReportingUserId, Acc_ex1_3 as GroupName, 1 as Groups,
case when Acc_ex5.Acc_ex5_92 between GETDATE()-365*10 and GETDATE() then 1 else 0 end as GroupsNotContacted
FROM ReportingMembers R
INNER JOIN TeamMembers T
ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo AND T.ReportsTo = 1)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
inner join Acc_ex1 on (Acc_ex1.OwnerID = 109 and Acc_ex1.Acc_ex1_Id = Accounts.AccountID and Acc_ex1.Acc_ex1_3 > '0')
inner join Acc_ex5 on (Acc_ex5.OwnerID = 109 and Acc_ex5.Acc_ex5_Id = Accounts.AccountID )
--where TerritoryID in ( select ChildRegionID RegionID from RegionWithSubRegions where OwnerID =109 and RegionID = 729)
union
select distinct R.ReportsTo as directReportingUserId, Acc_ex1_3 as GroupName, 1 as Groups,
case when Acc_ex5.Acc_ex5_92 between GETDATE()-365*10 and GETDATE() then 1 else 0 end as GroupsNotContacted
FROM ReportingMembers R
INNER JOIN TeamMembers T
ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
inner join Acc_ex1 on (Acc_ex1.OwnerID = 109 and Acc_ex1.Acc_ex1_Id = Accounts.AccountID and Acc_ex1.Acc_ex1_3 > '0')
inner join Acc_ex5 on (Acc_ex5.OwnerID = 109 and Acc_ex5.Acc_ex5_Id = Accounts.AccountID )
--where TerritoryID in ( select ChildRegionID RegionID from RegionWithSubRegions where OwnerID =109 and RegionID = 729)
where R.MemberID = 1
) GroupWiseInfo
group by directReportingUserId
) GroupInfo
on UserInfo.ReportsTo = GroupInfo.directReportingUserId
Please mark it as an answer/helpful if you find it as useful. Thanks, Satya Prakash Jugran -
Effect of RLS policy (VPD) on execution plan of a query
Hi
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Regards,
Amardeep SidhuAmardeep Sidhu wrote:
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format. -
SQL query with Bind variable with slower execution plan
I have a 'normal' sql select-insert statement (not using bind variable) and it yields the following execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=148)
1 0 HASH JOIN (Cost=7 Card=1 Bytes=148)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=4 Card=1 Bytes=100)
3 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=3 Card=1)
4 1 INDEX (FAST FULL SCAN) OF 'TABLEB_IDX_003' (NON-UNIQUE)
(Cost=2 Card=135 Bytes=6480)
Statistics
0 recursive calls
18 db block gets
15558 consistent gets
47 physical reads
9896 redo size
423 bytes sent via SQL*Net to client
1095 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
I have the same query but instead running using bind variable (I test it with both oracle form and SQL*plus), it takes considerably longer with a different execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=407 Card=1 Bytes=148)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=3 Card=1 Bytes=100)
2 1 NESTED LOOPS (Cost=407 Card=1 Bytes=148)
3 2 INDEX (FAST FULL SCAN) OF TABLEB_IDX_003' (NON-UNIQUE) (Cost=2 Card=135 Bytes=6480)
4 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=2 Card=1)
Statistics
0 recursive calls
12 db block gets
3003199 consistent gets
54 physical reads
9448 redo size
423 bytes sent via SQL*Net to client
1258 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
TABLEA has around 3million record while TABLEB has 300 records. Is there anyway I can improve the speed of the sql query with bind variable? I have DBA Access to the database
Regards
IvanMany thanks for your reply.
I have run the statistic already for the both tableA and tableB as well all the indexes associated with both table (using dbms_stats, I am on 9i db ) but not the indexed columns.
for table I use:-
begin
dbms_stats.gather_table_stats(ownname=> 'IVAN', tabname=> 'TABLEA', partname=> NULL);
end;
for index I use:-
begin
dbms_stats.gather_index_stats(ownname=> 'IVAN', indname=> 'TABLEB_IDX_003', partname=> NULL);
end;
Is it possible to show me a sample of how to collect statisc for INDEX columns stats?
regards
Ivan -
Same query at same time, but different execution plans from two schemas
Hi!
We just had some performance problems in our production system and I would like to ask for some advice from you.
We had a select-query that was run from USER1 on SCHEMA1, and it ran a table scan on a huge table.
Using session browser in TOAD I copied the Sql-statement, logged on SCHEMA1 and ran the same query. I got a different execution plan where I avoided the table scan.
So my question is:
How is it possible that the same query get different execution plans when running in two different schemas at the same time.
Some more information:
The user USER1 runs "alter session set current_schema=SCHEMA1;" when it logs on. Besides that it doesn't do anything so session parameter values are the same for USER1 and SCHEMA1.
SCHEMA1 is the schema owning the tables.
ALL_ROWS is used for both USER1 and SCHEMA1
Our database:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
Anybody has some suggestions to why I experience different execution plan for the same query, run at the same time, but from different users?Thanks for clarification of the schema structure.
What happens if instead of setting the current session schema to SCHEMA1, if you simply add the schema name to alle tables, views and other objects inside your select statement?
As in select * from schema1.dual;I know that this is not what you want eventually, but it might help to find any misleading objects.
Furthermore it is not clear what you meant with: "avoided a table scan".
Did you avoid a full table scan (FTS) or was the table completely removed from the execution plan?
Can you post both plans?
Edited by: Sven W. on Mar 30, 2010 5:27 PM -
How to capture the execution plan for a query
HI All,
Can anyone please help me in finding out the command to capture the execution plan for a query.
Execution plan for select * from EMP where <Condtions>
it is getting executed successfully but i need to get the proper execution plan for the same.
Thanks971830 wrote:
i want to know where execution plan gets generated??
in PMON of server process or in shared pool??
i know that optimixer create execution plan..It is stored in Library Cache (present inside Shared Pool ).
select * from v$sql_plan;An absolute beautiful white paper :
Refer this -- www.sagelogix.com/sagelogix/SearchResults/SAGE015052
Also -- http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/XPVSP/Default.aspx
HTH
Ranit B. -
Oracle 10g Diff in execution plan query with binding var Vs without
We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM -
Query Rewrite (QSM-01263) and Views in Execution Plan
Hello!
I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
Do you have any ideas how to get my query rewrite enabled work?
Thanks!Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.
-
Tool to find the execution plan of a SQL query
Hi,
I new to Oracle. I come from the SQL Server world.
I would like to know what tool(s) should I use to identify the execution plan for a SQL statement and to see if a query is missing indices.
Thanks,
PaulUse SQL*PLUS.
SQL> select dummy from dual;
D
X
SQL> set autotrace on explain
SQL> r
1* select dummy from dual
D
X
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=2)
1 0 TABLE ACCESS (FULL) OF 'DUAL' (TABLE) (Cost=2 Card=1 Bytes
=2)
SQL> set autot off
SQL> explain plan for select dummy from dual;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1157671242
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |
8 rows selected.
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options
SQL> -
Same Query returning different result (Different execution plan)
Hi all,
To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
The query :
SELECT *
FROM schema.table@database a
WHERE column1 IN ('3')
AND column2 = '101'
AND EXISTS
(SELECT null
FROM schema.table2 c
WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
Rows Row Source Operation
0 NESTED LOOPS (cr=31 r=0 w=0 time=4894659 us)
4323 SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
4336 TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
0 REMOTE (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
Rows Row Source Operation
3702 HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
22556 REMOTE (cr=0 r=0 w=0 time=401176 us)
4336 TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
It'is a bug or i have missed somthing ?
PS: The two table are no subject to insert or update statement.
Oracle version : 9.2.0.2.0
System version : HP-UX v1
Thanks.H.Mahmoud wrote:
Oracle version : 9.2.0.2.0
System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version) -
Hi,
I have a question about reading query execution plans. I don't understand what is meant by "Hash join" in a plan step. I understand "Nested_Loops" and "Merge_Join", but after looking at different documentations, I am still not clear about "Hash_Join". Please don't give links to Oracle documentation, because I have seen a lot of it, but it is still not clear. I also don't fully understand what is meant by a "Hash Table", what are all these "Hashesssssss"???
Please explain in your own words, if possible, and with the help of some example.
Thanks in Advance.,user566817 wrote:
Can any one else answer my question? I would be highly thankful.Hash joins are one of the 3 techniques used by Oracle to join to sets of data.
As a brief, and very very crude overview
Generally after applying the filter to one data source, the join key is hashed into a memory table (as described by link sb provided). The second data set areas filtered and it's join key is also hashed, but the hash is used to find matches in the memory table created by the first data source. Assuming no hash chaining, found matches are joins; if hassh chaining exists, the chain needs to be traversed to verify joins.
This, of course, has a lot of holes which would be filled in by the documentation and by external links that you do not seem to want to use.
(Remember: School papers need to cite references. Teachers these days DO check.) -
Query Execution Plans Change between 2 servers even when we have same data.
Hi Friends,
Currently One of the Query which normally takes 15 seconds but it started taking 160 seconds.So same query was executed on the secondary site and the query returned in 15 seconds which is expected.Raised a call with ORacle and they are still investigating since 27th Sept.
Oracle version=11.2.0.2
OS=Solaris 10.
Issue DB execution plan
select * From tibex_openinghomemktok as of scn 17032999332 where meid='ME1'
call count cpu elapsed disk query current rows
Parse 1 0.12 0.12 0 0 0 0
Execute 1 161.20 161.21 55 1539719 206 0
Fetch 6 0.05 0.05 190 386 1 464
total 8 161.37 161.38 245 1540105 207 464
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 191
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
464 464 464 VIEW TIBEX_OPENINGHOMEMKTOK (cr=1540105 pr=245 pw=191 time=161246176 us cost=149 size=291 card=1)
464 464 464 TEMP TABLE TRANSFORMATION (cr=1540105 pr=245 pw=191 time=161245860 us)
0 0 0 LOAD AS SELECT (cr=27 pr=0 pw=1 time=24101 us)
13 13 13 HASH JOIN (cr=27 pr=0 pw=0 time=13149 us cost=35 size=1408 card=8)
1 1 1 TABLE ACCESS FULL TIBEX_TRADINGMETHODENUM (cr=2 pr=0 pw=0 time=83 us cost=5 size=14 card=1)
235 235 235 HASH JOIN (cr=25 pr=0 pw=0 time=12612 us cost=30 size=22356 card=138)
235 235 235 NESTED LOOPS OUTER (cr=21 pr=0 pw=0 time=11568 us cost=22 size=16560 card=138)
235 235 235 HASH JOIN (cr=20 pr=0 pw=0 time=10831 us cost=22 size=10074 card=138)
40 40 40 HASH JOIN (cr=18 pr=0 pw=0 time=8119 us cost=17 size=2200 card=40)
40 40 40 HASH JOIN OUTER (cr=12 pr=0 pw=0 time=5920 us cost=13 size=1320 card=40)
40 40 40 NESTED LOOPS (cr=10 pr=0 pw=0 time=4155 us cost=3 size=800 card=40)
80 80 80 VIEW index$_join$_018 (cr=6 pr=0 pw=0 time=4245 us cost=3 size=1040 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=3057 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=169 us cost=1 size=1040 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=4 pr=0 pw=0 time=152 us cost=0 size=7 card=1)(object id 1354685)
0 0 0 VIEW (cr=2 pr=0 pw=0 time=316 us cost=10 size=143 card=11)
0 0 0 HASH JOIN (cr=2 pr=0 pw=0 time=315 us cost=8 size=352 card=11)
0 0 0 MERGE JOIN (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
83 83 83 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=113 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
0 0 0 VIEW index$_join$_023 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
0 0 0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
80 80 80 VIEW index$_join$_024 (cr=6 pr=0 pw=0 time=1121 us cost=3 size=1760 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=1040 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=66 us cost=1 size=1760 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=57 us cost=1 size=1760 card=80)(object id 1354895)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=229 us cost=5 size=4950 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=384 us cost=0 size=47 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=135 us cost=0 size=0 card=1)(object id 1354925)
330 330 330 TABLE ACCESS FULL TIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=61 us cost=7 size=13860 card=330)
0 0 0 LOAD AS SELECT (cr=1539692 pr=55 pw=190 time=161190726 us)
12435 12435 12435 NESTED LOOPS (cr=1539692 pr=55 pw=0 time=158262964 us cost=109 size=284 card=1)
12435 12435 12435 FILTER (cr=1539688 pr=55 pw=0 time=158208902 us)
497400 497400 497400 NESTED LOOPS OUTER (cr=1539688 pr=55 pw=0 time=212847780 us cost=109 size=280 card=1)
497400 497400 497400 NESTED LOOPS (cr=544888 pr=55 pw=0 time=60349504 us cost=108 size=267 card=1)
497400 497400 497400 MERGE JOIN CARTESIAN (cr=47484 pr=55 pw=0 time=57182690 us cost=107 size=254 card=1)
12435 12435 12435 NESTED LOOPS (cr=47483 pr=55 pw=0 time=2368168 us cost=106 size=247 card=1)
13877 13877 13877 NESTED LOOPS (cr=33602 pr=55 pw=0 time=5930848 us cost=105 size=233 card=1)
1473 1473 1473 NESTED LOOPS (cr=212 pr=2 pw=0 time=9371 us cost=35 size=390 card=3)
13 13 13 HASH JOIN (cr=193 pr=1 pw=0 time=8029 us cost=34 size=116 card=1)
13 13 13 NESTED LOOPS (cr=191 pr=1 pw=0 time=7255 us cost=31 size=95 card=1)
338 338 338 HASH JOIN (cr=187 pr=1 pw=0 time=6329 us cost=31 size=2821 card=31)
13 13 13 VIEW VW_NSO_1 (cr=184 pr=1 pw=0 time=5958 us cost=26 size=26 card=1)
13 13 13 SORT GROUP BY (cr=184 pr=1 pw=0 time=5954 us cost=26 size=115 card=1)
65 65 65 NESTED LOOPS ANTI (cr=184 pr=1 pw=0 time=5898 us cost=25 size=115 card=1)
78 78 78 NESTED LOOPS (cr=102 pr=1 pw=0 time=6140 us cost=24 size=101 card=1)
78 78 78 NESTED LOOPS OUTER (cr=20 pr=1 pw=0 time=5341 us cost=23 size=94 card=1)
78 78 78 HASH JOIN (cr=19 pr=1 pw=0 time=5077 us cost=23 size=55 card=1)
13 13 13 HASH JOIN (cr=17 pr=1 pw=0 time=4056 us cost=17 size=352 card=8)
40 40 40 NESTED LOOPS (cr=13 pr=0 pw=0 time=3300 us cost=15 size=1480 card=40)
40 40 40 HASH JOIN OUTER (cr=9 pr=0 pw=0 time=2928 us cost=15 size=1320 card=40)
40 40 40 HASH JOIN (cr=7 pr=0 pw=0 time=1976 us cost=5 size=800 card=40)
40 40 40 INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=120 us cost=1 size=280 card=40)(object id 1354685)
80 80 80 VIEW index$_join$_044 (cr=6 pr=0 pw=0 time=1251 us cost=3 size=1040 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=1249 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=135 us cost=1 size=1040 card=80)(object id 1354895)
0 0 0 VIEW (cr=2 pr=0 pw=0 time=295 us cost=10 size=143 card=11)
0 0 0 HASH JOIN (cr=2 pr=0 pw=0 time=293 us cost=8 size=352 card=11)
0 0 0 MERGE JOIN (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
83 83 83 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=116 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 135473
9)
0 0 0 VIEW index$_join$_049 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
0 0 0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
78 78 78 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
13 13 13 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
78 78 78 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
13 13 13 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
275 275 275 MERGE JOIN OUTER (cr=3 pr=0 pw=0 time=892 us cost=5 size=17875 card=275)
275 275 275 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=401 us cost=2 size=4950 card=275)
275 275 275 INDEX FULL SCAN XPKTIBEX_CYCLEPERIODMAP (cr=1 pr=0 pw=0 time=115 us cost=1 size=0 card=275)(object id 1354681)
0 0 0 SORT JOIN (cr=1 pr=0 pw=0 time=207 us cost=3 size=47 card=1)
0 0 0 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=17 us cost=2 size=47 card=1)
13 13 13 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=349 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=2 pr=0 pw=0 time=52 us cost=2 size=336 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=2 pr=0 pw=0 time=49 us cost=2 size=1216 card=16)
1473 1473 1473 INDEX RANGE SCAN XPKTIBEX_INSTRUMENTBOARDMAP (cr=19 pr=1 pw=0 time=1378 us cost=1 size=504 card=36)(object id 1354759)
13877 13877 13877 TABLE ACCESS BY INDEX ROWID TIBEX_INSTRUMENTADMIN (cr=33390 pr=53 pw=0 time=2023879 us cost=27 size=103 card=1)
44576 44576 44576 INDEX RANGE SCAN SYS_C001331991 (cr=1277 pr=53 pw=0 time=43026 us cost=1 size=0 card=35)(object id 1354964)
12435 12435 12435 TABLE ACCESS BY INDEX ROWID TIBEX_INSTRACTIONENUM (cr=13881 pr=0 pw=0 time=81117 us cost=1 size=14 card=1)
13877 13877 13877 INDEX UNIQUE SCAN XPKTIBEX_INSTRACTIONENUM (cr=4 pr=0 pw=0 time=32628 us cost=0 size=0 card=1)(object id 1354753)
497400 497400 497400 BUFFER SORT (cr=1 pr=0 pw=0 time=323076 us cost=106 size=280 card=40)
40 40 40 INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=61 us cost=1 size=280 card=40)(object id 1354685)
497400 497400 497400 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=497404 pr=0 pw=0 time=2609562 us cost=1 size=13 card=1)
497400 497400 497400 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=1019970 us cost=0 size=0 card=1)(object id 1354895)
0 0 0 VIEW PUSHED PREDICATE (cr=994800 pr=0 pw=0 time=151415026 us cost=1 size=13 card=1)
0 0 0 HASH JOIN (cr=994800 pr=0 pw=0 time=150806856 us cost=7 size=32 card=1)
0 0 0 MERGE JOIN (cr=994800 pr=0 pw=0 time=19714460 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=994800 pr=0 pw=0 time=18729534 us cost=2 size=26 card=2)
41284200 41284200 41284200 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=497400 pr=0 pw=0 time=16264606 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=2 size=26 card=2)
0 0 0 INDEX RANGE SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=2)(object id 1354894)
12435 12435 12435 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=33106 us cost=0 size=4 card=1)(object id 1354899)
464 464 464 HASH JOIN SEMI (cr=386 pr=190 pw=0 time=30227 us cost=6 size=331 card=1)
5684 5684 5684 VIEW (cr=194 pr=190 pw=0 time=8864 us cost=2 size=582 card=2)
12435 12435 12435 TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=194 pr=190 pw=0 time=9137 us cost=2 size=272 card=2)
1267 1267 1267 VIEW VW_NSO_2 (cr=192 pr=0 pw=0 time=13710 us cost=3 size=80 card=2)
1267 1267 1267 HASH GROUP BY (cr=192 pr=0 pw=0 time=13074 us cost=3 size=38 card=2)
12435 12435 12435 VIEW (cr=192 pr=0 pw=0 time=11843 us cost=2 size=38 card=2)
12435 12435 12435 TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=192 pr=0 pw=0 time=5751 us cost=2 size=272 card=2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
Disk file operations I/O 1 0.00 0.00
direct path write temp 2 0.00 0.00
direct path sync 1 0.00 0.00
db file sequential read 55 0.00 0.00
SQL*Net message to client 6 0.00 0.00
db file scattered read 2 0.00 0.00
SQL*Net message from client 6 0.00 0.00Regards
NMHi,
Execution Plan after generating stats on TIBEX_TRADINGCYCLE.
Execution Plan
Plan hash value: 1209012613
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 291 | 130 (7)| 00:00:02 |
| 1 | VIEW | TIBEX_OPENINGHOMEMKTOK | 1 | 291 | 130 (7)| 00:00:02 |
| 2 | TEMP TABLE TRANSFORMATION | | | | | |
| 3 | LOAD AS SELECT | SYS_TEMP_0FD9D662B_FB42A6E1 | | | | |
|* 4 | HASH JOIN | | 8 | 1392 | 27 (12)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | TIBEX_TRADINGMETHODENUM | 1 | 14 | 5 (0)| 00:00:01 |
|* 6 | HASH JOIN | | 138 | 22080 | 21 (10)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 138 | 16284 | 14 (15)| 00:00:01 |
|* 8 | HASH JOIN | | 138 | 9798 | 14 (15)| 00:00:01 |
|* 9 | HASH JOIN | | 40 | 2120 | 8 (13)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 40 | 1240 | 5 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 40 | 800 | 3 (34)| 00:00:01 |
| 12 | VIEW | index$_join$_018 | 80 | 1040 | 3 (34)| 00:00:01 |
|* 13 | HASH JOIN | | | | | |
| 14 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 15 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 1 | 7 | 0 (0)| 00:00:01 |
| 17 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 18 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 19 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID | TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 21 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|* 22 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 23 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
| 26 | VIEW | index$_join$_024 | 80 | 1760 | 3 (34)| 00:00:01 |
|* 27 | HASH JOIN | | | | | |
| 28 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1760 | 1 (0)| 00:00:01 |
| 29 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1760 | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS FULL | TIBEX_CYCLEPERIODMAP | 275 | 4950 | 5 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 47 | 0 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
| 33 | TABLE ACCESS FULL | TIBEX_TRADINGPERIOD | 330 | 13860 | 7 (0)| 00:00:01 |
| 34 | LOAD AS SELECT | SYS_TEMP_0FD9D662C_FB42A6E1 | | | | |
| 35 | NESTED LOOPS | | 1 | 282 | 98 (5)| 00:00:02 |
|* 36 | FILTER | | | | | |
| 37 | NESTED LOOPS OUTER | | 1 | 278 | 98 (5)| 00:00:02 |
| 38 | NESTED LOOPS | | 1 | 267 | 97 (5)| 00:00:02 |
| 39 | MERGE JOIN CARTESIAN | | 1 | 254 | 96 (5)| 00:00:02 |
| 40 | NESTED LOOPS | | | | | |
| 41 | NESTED LOOPS | | 1 | 247 | 95 (5)| 00:00:02 |
| 42 | NESTED LOOPS | | 1 | 233 | 94 (5)| 00:00:02 |
| 43 | NESTED LOOPS | | 3 | 390 | 24 (17)| 00:00:01 |
|* 44 | HASH JOIN | | 1 | 116 | 23 (18)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 95 | 21 (20)| 00:00:01 |
| 46 | NESTED LOOPS OUTER | | 31 | 2821 | 21 (20)| 00:00:01 |
| 47 | NESTED LOOPS | | 31 | 1364 | 21 (20)| 00:00:01 |
| 48 | VIEW | VW_NSO_1 | 1 | 26 | 18 (17)| 00:00:01 |
| 49 | SORT GROUP BY | | 1 | 113 | 18 (17)| 00:00:01 |
| 50 | NESTED LOOPS ANTI | | 1 | 113 | 17 (12)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 99 | 16 (13)| 00:00:01 |
| 52 | NESTED LOOPS OUTER | | 1 | 92 | 15 (14)| 00:00:01 |
|* 53 | HASH JOIN | | 1 | 53 | 15 (14)| 00:00:01 |
|* 54 | HASH JOIN | | 8 | 336 | 9 (12)| 00:00:01 |
| 55 | NESTED LOOPS | | 40 | 1400 | 7 (15)| 00:00:01 |
| 56 | NESTED LOOPS OUTER | | 40 | 1240 | 7 (15)| 00:00:01 |
|* 57 | HASH JOIN | | 40 | 800 | 4 (25)| 00:00:01 |
|* 58 | INDEX RANGE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 40 | 280 | 1 (0)| 00:00:01 |
| 59 | VIEW | index$_join$_044 | 80 | 1040 | 3 (34)| 00:00:01 |
|* 60 | HASH JOIN | | | | | |
| 61 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 62 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 63 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 64 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 65 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|* 66 | TABLE ACCESS BY INDEX ROWID| TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 67 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|* 68 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 69 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|* 71 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
|* 72 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | 4 | 0 (0)| 00:00:01 |
| 73 | VIEW | | 16 | 112 | 2 (0)| 00:00:01 |
| 74 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662B_FB42A6E1 | 16 | 1216 | 2 (0)| 00:00:01 |
| 75 | TABLE ACCESS FULL | TIBEX_CYCLEPERIODMAP | 275 | 3025 | 5 (0)| 00:00:01 |
| 76 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 39 | 0 (0)| 00:00:01 |
|* 77 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
| 78 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGPERIOD | 1 | 7 | 1 (0)| 00:00:01 |
|* 79 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGPERIOD | 1 | | 0 (0)| 00:00:01 |
|* 80 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGMETHODENUM | 1 | 14 | 1 (0)| 00:00:01 |
|* 81 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGMETHODENUM | 1 | | 0 (0)| 00:00:01 |
| 82 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAP | 31 | 558 | 2 (0)| 00:00:01 |
|* 83 | INDEX SKIP SCAN | XPKTIBEX_CYCLEPERIODMAP | 31 | | 1 (0)| 00:00:01 |
| 84 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 47 | 0 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
|* 86 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | 4 | 0 (0)| 00:00:01 |
| 87 | VIEW | | 16 | 336 | 2 (0)| 00:00:01 |
| 88 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662B_FB42A6E1 | 16 | 1216 | 2 (0)| 00:00:01 |
|* 89 | INDEX RANGE SCAN | XPKTIBEX_INSTRUMENTBOARDMAP | 36 | 504 | 1 (0)| 00:00:01 |
|* 90 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRUMENTADMIN | 1 | 103 | 27 (0)| 00:00:01 |
|* 91 | INDEX RANGE SCAN | SYS_C001331991 | 35 | | 1 (0)| 00:00:01 |
|* 92 | INDEX UNIQUE SCAN | XPKTIBEX_INSTRACTIONENUM | 1 | | 0 (0)| 00:00:01 |
|* 93 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRACTIONENUM | 1 | 14 | 1 (0)| 00:00:01 |
| 94 | BUFFER SORT | | 40 | 280 | 95 (5)| 00:00:02 |
|* 95 | INDEX RANGE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 40 | 280 | 1 (0)| 00:00:01 |
| 96 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 1 | 13 | 1 (0)| 00:00:01 |
|* 97 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | | 0 (0)| 00:00:01 |
| 98 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 99 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 100 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|*101 | TABLE ACCESS BY INDEX ROWID | TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 102 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|*103 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 104 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 105 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|*106 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
|*107 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGPERIOD | 1 | 4 | 0 (0)| 00:00:01 |
|*108 | HASH JOIN SEMI | | 1 | 331 | 6 (34)| 00:00:01 |
|*109 | VIEW | | 2 | 582 | 2 (0)| 00:00:01 |
| 110 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_FB42A6E1 | 2 | 272 | 2 (0)| 00:00:01 |
| 111 | VIEW | VW_NSO_2 | 2 | 80 | 3 (34)| 00:00:01 |
| 112 | HASH GROUP BY | | 2 | 38 | 3 (34)| 00:00:01 |
| 113 | VIEW | | 2 | 38 | 2 (0)| 00:00:01 |
| 114 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_FB42A6E1 | 2 | 272 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------------------------------ -
How to skip existing execution plan for a query
Hi,
I want to skip existng execution plan for a query which I am executing often. I dont want it to use the same execution plan everytime. Please let me know if any method is there skip the existing execution plan.
Thanks in advance.......
Edited by: 900105 on Dec 1, 2011 4:52 AMChange the query so it is syntactically different, but has the same semantics (meaning). That way CBO will reparse it and you might get a new execution plan.
One simple way to do that is to add a dummy predicate ( 45=45) to the where clause. The predicate must be changed every time the query is executed ( 46=46 , 47=47 ,… ).
Iordan Iotzov
http://iiotzov.wordpress.com/
Maybe you are looking for
-
IPhone 5s having weird issues...anyone have this too??
Hello(: So I've had the iPhone 5s ever since the release and around the first week I noticed it randomly restarted itself but everything was working properly so I let it slide by. However, ever since then my phone would freeze on what ever app/screen
-
Recorded new vocal into "varispeeded" project; get rid of artifacts?
Hi, Original bpm: 120. All tracks recorded in MIDI except my vocals. Bump bpm to 125 with varispeed. I like this tempo. Now, I record vocals with varispeed ON. They sound "warbley" and watery. I guess this was a big oops. Is there any way to get rid
-
On my iphone 5s, in "photos" when I touch to enlarge, random new photos are showing as old photos. For example, let's say I'm looking in an album at a photo of a dog I took today. If I touch to enlarge- that photo of a dog is suddenly a photo of a fa
-
How to fill BI cube with Web Dynpro ABAP Program UI
Hello, I am new in web dynpro ABAP and need zour help. How can i write aABAP web dynpro program, which allows the user to enter transactional data and saved in the real time infocube. I know that such a functionality exist in the integrated planning
-
I noticed that Nokia Suite is no longer listing Microsoft Apps as a 'Software Update'. I did not install it when it first came up, as I do not think I need it. Is this suite being phased out for the E7 since it is no longer listed as an update?