Gather_plan_statistics hint ignored
Hi,
I am facing a situation when my gather_plan_statistics hint gets occasionally ignored. ALTER SESSION SET STATISTICS_LEVEL = ALL doesn't help either. I suspect that this may be one of Toad irregularities. I was given advice to run the query in sqlplus to make rowsource stats work. However, there is a problem: I don't know how to suppress the output.
My concern is that if I don't suppress it, the timing information in the plan will be wrong (because of terminal output being slow).
I googled and I found suggestion to use set autotrace traceonly. However, it doesn't work because the user doesn't have proper privileges for that (I have to run query under a user that only has access to the application tables, and then use another user to query v$sql, v$sql_statistics etc.).
So my questions are:
1) am I right to be concerned about slow terminal output screwing up timing information in the plan?
2) if yes, then how do I resolve the problem?
Version information: Oracle 10.2.0.5, Toad 11.0.
Best regards,
Nikolay
Hi,
sure I can, but it's not suppressing anything:
SQL> set termout off
SQL> select 1 from dual connect by level<=50;
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
50 rows selected.
SQL>Best regards,
Nikolay
Similar Messages
-
Dynamically apply gather_plan_statistics hint to a sql_id
Hello,
We have set statistics_level=typical in our production database. And we do not have GATHER_PLAN_STATISTICS hint in any of our queries either. The reason being it can be performance inhibitor in production.
Now I want to get ALLSTATS for a particular sql_id that is running in production no matter what session it's in. My question is whether there is any way I can dynamically apply GATHER_PLAN_STATISTICS hint to a specific sql_id just for a few minutes in production and get detailed information for a few executions and then turn it off after a while? It would be tantamount to setting a 10046 trace for a session for a while.
Does anyone know if and how to do this?
Also, is there any way to add MONITOR hint to a sql_id in similar fashion?
ThanksHi,
sure I can, but it's not suppressing anything:
SQL> set termout off
SQL> select 1 from dual connect by level<=50;
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
50 rows selected.
SQL>Best regards,
Nikolay -
Gather_plan_statistics hint result not visible
on my Oracle 11.2.0.1, I tried to use that hint as in example:
set autotrace on explain
select /*+ gather_plan_statistics */ 'x' from dual;
Execution Plan
Plan hash value: 272002086
| 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 |
--------------------------------------------------------------------------as you see, there's no additional columns (E-rows, A-rows), and I don't know why.
what could cause this?
regardsThis is just yet another limitation to autotrace. Use dbms_xplan and format the data how you need it.
SQL> select /*+ gather_plan_statistics */ 'x' from dual;
x
SQL> SELECT * FROM table(dbms_xplan.display_cursor(format=>'allstats'));
PLAN_TABLE_OUTPUT
SQL_ID gxug7sz6nhqc3, child number 0
select /*+ gather_plan_statistics */ 'x' from dual
Plan hash value: 1388734953
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time |
| 0 | SELECT STATEMENT | | 4 | | 4 |00:00:00.01 |
| 1 | FAST DUAL | | 4 | 1 | 4 |00:00:00.01 |
PLAN_TABLE_OUTPUT
13 rows selected.Read more about the parameters and usage here:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_xplan.htm -
Join hint ignored - very bad query plan results
I'm trying to get a query that's being generated by SSAS to perform acceptably. Because this query is (at least partially) generated by SSAS, I don't have complete control over the query text.
The problem - The query looks roughly like this:
select
-- a bunch of columns
from
T1 -- table with ~40,000,000 rows
inner loop join T2 on T2.t2id = T1.t2id -- table with ~16,000 rows
inner loop join T3 on T3.t3id = T1.t3id -- table with ~200,000 rows inner loop join T4 on T4.t4id = T1.t4id -- table with ~200,000 rows
left loop join T5 on T5.t3id = T1.t3id and T5.t6id = T4.t6id -- table with 0 rows
where
-- some uninteresting conditions
T1 is a Fact (or Measure) table, T2, T3 and T4 are Dimension tables, T5 and T6 are involved in the filtering of the query. Every row of T1 WILL match exactly one row in each of T1, T2 and T3.
You'll note that I've hinted all of the joins - according to the documentation, using join hints forces join order (which is consistent with the plan that's produced). There's no mention that join hints can be transparently ignored by the optimizer,
but that seems to be precisely what's happening.
In the plan that results, the join to T4 is done as a hash join, with T1*T2*T3 (40,000,000 rows) on the "top", so it ends up trying to build a hash table with 40,000,000 rows, resulting in very high tempdb activity and very poor performance (I
don't know how poor - I've never let it finish).
I can see part of the reason why it's making this join choice - the estimate of T1*T2*T3 is only 35,000 rows, even though T1 has 40,000,000 rows and the join will hit on every row.
Questions:
1. What can I do to the query or the database to improve the estimate on the join to T3?
2. What can I do to the query to force the optimizer to use a loop join like I asked?
Version is SQL Server 2008 R2 SP2 Developer Edition X64.
OS is Windows 2008 R2
Machine is dual-quad-hyper-threaded CPU with 96Gb of RAM and several Tb of disk spread over 8 spindles and SSDs.
I've seen this query perform well before - I've been tuning this query for going on 7 years now and I've never seen it perform this badly that I can recall. Not sure if it's something that's changed in SP2, or something about the distribution
of data in this particular database that's changed, but something's sure changed.
-cd Mark the best replies as answers!That would indicate that there are no foreign-key constraints, or if they, they are not trusted. (Assuming here that there WHERE clause includes no filter on T1.)
That, or the statistics on T1 are giving a completely wrong estimates for the number of NULL values in t2id and t3id.
Erland Sommarskog, SQL Server MVP, [email protected]
Thanks, Erland.
There are foreign key constraints, but they're NOCHECK. I've tried creating and updating statistics on various columns of the tables involved - I'll re-check that I've got up to date statistics on all of the columns involved in these joins.
What about the join-hint being ignored? Is there anything I can do, or has something changed here recently? Interestingly, when I run this query from SSMS, I get loop-joins all around, but when SSAS runs the query, the one join always comes out
a hash join. Before I added the hints, all joins were hash joins - the hints worked on all joins but the one.
-cd Mark the best replies as answers! -
Hi,
in my 9.2.0.8 I've got query like:
SELECT /*+ AND_EQUAL(l I_LOK_OPJ_FK I_LOK_DGR_FK) USE_NL(L) USE_NL(OPJ)*/ MAX(lok_audyt_dt)
FROM LIMITY_OKRESY l, OSOBA_PROGRAM_LOJAL opj, OSOBY oss
WHERE lok_opj_id = opj_id
AND opj_osb_id = osb_id
AND osb_audyt_st = '1'
AND opj_audyt_st = '1'
AND lok_audyt_st = '1'
and osb_audyt_st = opj_audyt_st
and osb_audyt_st = lok_audyt_st
and lok_dgr_id = 26
AND oss.osb_pesel = '33010511133'
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 57 | 75898 |
| 1 | SORT AGGREGATE | | 1 | 57 | |
| 2 | NESTED LOOPS | | 929 | 52953 | 75898 |
| 3 | NESTED LOOPS | | 900 | 34200 | 1198 |
| 4 | TABLE ACCESS BY INDEX ROWID| OSOBY | 92 | 2024 | 94 |
| 5 | INDEX RANGE SCAN | I_OSB_PESEL | 92 | | 3 |
| 6 | TABLE ACCESS BY INDEX ROWID| OSOBA_PROGRAM_LOJAL | 10 | 160 | 12 |
| 7 | INDEX RANGE SCAN | I_OPJ_SYNCHRO2 | 10 | | 3 |
| 8 | TABLE ACCESS BY INDEX ROWID | LIMITY_OKRESY | 1 | 19 | 75898 |
| 9 | AND-EQUAL | | | | |
| 10 | INDEX RANGE SCAN | I_LOK_OPJ_FK | 1363K| | 80 |
| 11 | INDEX RANGE SCAN | I_LOK_DGR_FK | 1363K| | 80 |
Note: cpu costing is off, PLAN_TABLE' is old version
explain plan for
SELECT /*+ AND_EQUAL(l I_LOK_OPJ_FK I_LOK_DGR_FK) */ MAX(lok_audyt_dt)
FROM LIMITY_OKRESY l, OSOBA_PROGRAM_LOJAL opj, OSOBY oss
WHERE lok_opj_id = opj_id
AND opj_osb_id = osb_id
AND osb_audyt_st = '1'
AND opj_audyt_st = '1'
AND lok_audyt_st = '1'
and osb_audyt_st = opj_audyt_st
and osb_audyt_st = lok_audyt_st
and lok_dgr_id = 26
AND oss.osb_pesel = '33010511133'
Explained.
SQL> select * from table(dbms_xplan.display());
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 57 | 1844 |
| 1 | SORT AGGREGATE | | 1 | 57 | |
| 2 | HASH JOIN | | 929 | 52953 | 1844 |
| 3 | TABLE ACCESS BY INDEX ROWID | OSOBA_PROGRAM_LOJAL | 10 | 160 | 12 |
| 4 | NESTED LOOPS | | 900 | 34200 | 1198 |
| 5 | TABLE ACCESS BY INDEX ROWID| OSOBY | 92 | 2024 | 94 |
| 6 | INDEX RANGE SCAN | I_OSB_PESEL | 92 | | 3 |
| 7 | INDEX RANGE SCAN | I_OPJ_SYNCHRO2 | 10 | | 3 |
| 8 | TABLE ACCESS BY INDEX ROWID | LIMITY_OKRESY | 1363K| 24M| 630 |
| 9 | INDEX RANGE SCAN | I_LOK_DGR_FK | 1363K| | 80 |
Note: cpu costing is off, PLAN_TABLE' is old versionThe first query which respects AND_EQUAL hint runns with 243 cr , the second one which somehow ignores the hint need about 40k cr to complete .
Why CBO is ignoring my and_equal hint I need that for performance .
Please advice.
Regards.
Greguser10388717 wrote:
Hi,
in my 9.2.0.8 I've got query like:
(snip)
Note: cpu costing is off, PLAN_TABLE' is old version
The first query which respects AND_EQUAL hint runns with 243 cr , the second one which somehow ignores the hint need about 40k cr to complete .
Why CBO is ignoring my and_equal hint I need that for performance .
Please advice.
Regards.
GregGreg,
I do not see anything that would explicitly prevent the AND_EQUAL hint from working, other than an automatic transformation of the SQL statement that only happened when the two nested loop hints were provided. Hints are directives - the optimizer must obey hints unless:
* The hint is invalid due to the wrong alias used in the hint
* The hint is malformed
* The hint is incompatible with another hint
* The query was transformed by the optimizer into a form that is incompatible with the hint before the optimizer applied the hint
* The hint, if followed, would cause the wrong results to be returned
See this article for more information:
http://hoopercharles.wordpress.com/2010/07/19/demonstration-of-oracle-ignoring-an-index-hint/
I would assume that bullet point #4 applies in this case. Examining a 10053 trace, as suggested by riedelme, might help. I believe that the 9i version of a 10053 trace will show how the query is being transformed as it is optimized, just like 10g and above.
Note that the AND_EQUAL hint is deprecated as of Oracle 10g. Jonathan Lewis' "Cost-Based Oracle Fundamentals" book contains a little bit of information about that hint and the AND EQUAL execution path:
http://books.google.com/books?id=TGSd3pkMx5IC&pg=PA457
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
DYNAMIC_SAMPLING Hint Ignored when CONCATENATION operation is used (10g)
Using 10g (10.2.0.3) I ran into an interesting scenario that really messed up query performance. I found that when the optimizer chose to use CONCATENATION it ignores the DYNAMIC_SAMPLING hint. Has anyone else suffered from this or know of a work-around for this.
We legitimately use the DYNAMIC_SAMPLING hint because have some correlated columns that are used in the WHERE clause and that is how we get the right cardinality.
The easiest way to test this is to use this pattern in your WHERE clause:
WHERE
text_column like 'A%'
or text_column like 'B%'
and any_corrleated_column = <some value>
That pattern makes the query eligible for the CONCATENATION operation. To force it for testing purposes you have to use the USE_CONCAT hint.
Our specific data had to do with healthcare. Specifically looking at a specific diagnosis code for a given patient type (inpatient, emergency, observation, etc.)
The diagnosis code was heavily correlated with the patient type so initial cardinality estimates were off. The DYNAMIC_SAMPLING hint fixed that until the optimizer chose to use CONCATENATION in which case it drastically underestimated the cardinality and used nested loops where it should not have and query performance was hurt.
Of course the work-around is to use the NO_MERGE hint, but I really don't like using hints that "force" specific access paths because at some point the data may change such that a merge would be appropriate.
Has anyone tried this on 11g and is the DYNAMIC_SAMPLING preserved?Dion, Thanks for your reply.
We have a lot of analysts who execute their queries directly (OLAP) and that is a conscious choice and we accept the lack of control with performance and tuning individual queries with hints..
I mention that because in my mind if Oracle is the one that transforms the query from a single table query to use a CONCATENATION operation it should pass on the DYNAMIC_SAMPLING hint to each of the factored queries.
I agree, there is a lot that could be done with hints, but I really try to avoid hints that lock Oracle into a specific execution path. What I like about DYNAMIC_SAMPLING is I can tell Oracle to challenge its assumptions because I know there are heavily correlated columns in the query.
When Oracle then samples the data it still has all of the options available to it as far as valid access paths and join types. That is a hint that I will not necessarily have to revisit. Now I could use extended statistics with 11g and that should yield the same effect and maybe I'll just have to wait for us to upgrade to 11g. I really don't want to propagate a lot of hints that I have to think about on every version upgrade.
Again, thanks for adding to this discussion. -
[JDev 9.0.3/JClient] ViewObject/Entity attribute: Display Hint ignored?
I have a small problem with the ability to hide ViewObject/Entity attributes in generated JClient Forms. Hope somebody might know a bit more of this issue.
When setting the "Display Hint" to "Hide" on an attribute (of either the Entity or ViewObject), the appropriate JLabel and JTextField (or whatever Swing control is used to edit the value) will not be hidden, neither at designtime nor runtime.
I'm not (yet ;)) an expert when it comes to JClient, but it seems to me that when I tell an attribute of a ViewObject to be hidden, I would expect that the visible property of the appropriate Swing controls be set to false. [ setVisible(false); ]
In some other thread [ http://forums.oracle.com/forums/message.jsp?id=1342592 ] I read that the problem might be related to setting the control hint AFTER the JClient Form was generated. However, in that same thread someone else suggested that the control hint is processed at runtime. So, I've tried both approaches: first setting the control hint, then generating the JClient Form and first generating the JClient form, then setting the control hint. Neither approach worked.
However, I did notice that after I set the control hints, the JClient Form wizard allowed me to hide 'hidden' attributes (which indeed were the attributes which I had specified to be hidden). So that worked ok. But even though I unchecked the hidden attributes box, the end result was still the same: a Form with all attributes on it. Running the project revealed that the controls were not hidden at runtime either.
Am I pherhaps missing something? Or else could this be a bug?
(As the subject indicates, I'm using JDeveloper 9.0.3 Production Release.)Alright, consider this scenario:
I have a ViewObject with some attributes and in particular the attribute 'X'. In the database table column X is NOT NULL and so attribute X automatically is Mandatory. (This is correctly generated by the BC4J wizard.)
Next, I manually specify that attribute X is invisible (Display Hint). This should cause any bound Swing controls to become invisible when simply browsing the database. However, when inserting a new record, all controls associated with attribute X should become visible (since X is a Mandatory attribute). After the new record has been committed, the appropriate Swing controls become invisible again.
I suppose that this behavior could be the same for non Mandatory attributes, but that's (somewhat) less important.
In case you want a 2nd form in which existing records can be edited (including column X), attribute X should nolonger be invisible. Then the Swing controls bound to attribute X should be removed from the browse form and the 'insert capabilities' of that particular form should be removed as well. The new 2nd should be used for editing/inserting, while the 1st one is for browsing only.
I realise that this scenario may contain a couple of flaws, but it's to give you an indication of what I'd like to be able to do with the existing wizards and attribute editors.
Enjoy :) -
ear friends,
my query is like below.
if you people see i have used Hint in the first query but still my tbl_bank_statement showing Full Table Scan.
pls. help if i want remove FTS on table what should i modify in below query.
SELECT /* index(tbl_bank_statement indx_policyno) +*/t1.policy_no AS policy_no, t1.request_no AS request_no,t1.ecs_mandate_status AS ecsmandatestatus ,t1.ecs_micr_code AS ecsmicrcode,t1.createddate ,t1.userid,t1.ecs_account_no,
t1.ecs_micr_code,t1.Ecs_Factoring_House,t1.ecs_startdate,t1.ecs_enddate,REJECTIONREASON AS rejectionreason,
t1.ecs_first_account_holder_name,t1.ecs_second_account_holder_name,t1.ecs_mandate_ref_no,t1.ecs_trd_party_premium_payment
,t1.ecs_reln_btn_owner_payor,t1.ecs_account_type,NULL AS REQUESTDATE
FROM tbl_bank_statement t1
Where not exists( SELECT t3.serreqid FROM m_ps_otherdetails t3,t_ps_serreq_log ps
Where t3.policyno = t1.policy_no
and t3.serreqid =ps.serreqid
and ps.serreqtypeid in (37,38,39)
and t3.ECS_Mandate_status = ''4'')
UNION
SELECT t2.policyno AS policy_no,t2.serreqid AS request_no,t2.ecs_mandate_status AS ecsmandatestatus,t2.ecs_micr_code AS ecsmicrcode,t2.createddate,t2.createdby AS userid,t2.ecs_account_no,
t2.ecs_micr_code,t2.Ecs_Factoring_House,t2.ecs_startdate,t2.ecs_enddate,reqlog.rejectionreason,
2.ecs_first_account_holder_name,t2.ecs_second_account_holder_name,t2.ecs_mandate_ref_no,t2.ecs_trd_party_premium_payment,
t2.ecs_reln_btn_owner_payor,t2.ecs_account_type, reqlog.REQUESTDATE AS REQUESTDATE
FROM m_ps_otherdetails t2Hints are directives. The only time I've EVER seen a hint ignored is if it creates a situation where it would invalidate the results, or there's a bug in the oracle code itself.
It will very much not ignore an index hint if it thinks a FTS is 'cheaper'.
mkr02@ORA11GMK> create table t as select level lvl from dual connect by level < 100000
2 /
Table created.
Elapsed: 00:00:01.53
mkr02@ORA11GMK> alter table t modify lvl not null
2 /
Table altered.
Elapsed: 00:00:00.83
mkr02@ORA11GMK> create index idx on t(lvl)
2 /
Index created.
Elapsed: 00:00:00.43
mkr02@ORA11GMK> explain plan for select lvl from t
2 /
Explained.
Elapsed: 00:00:00.25
mkr02@ORA11GMK> @xplan
PLAN_TABLE_OUTPUT
Plan hash value: 1601196873
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 108K| 1380K| 47 (3)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T | 108K| 1380K| 47 (3)| 00:00:01 |
Note
- dynamic sampling used for this statement (level=2)
12 rows selected.
Elapsed: 00:00:01.05
mkr02@ORA11GMK> explain plan for
2 select /*+ index(t idx) */ lvl from t
3 /
Explained.
Elapsed: 00:00:00.02
mkr02@ORA11GMK> @xplan
PLAN_TABLE_OUTPUT
Plan hash value: 2099009386
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 108K| 1380K| 237 (1)| 00:00:03 |
| 1 | INDEX FULL SCAN | IDX | 108K| 1380K| 237 (1)| 00:00:03 |
Note
- dynamic sampling used for this statement (level=2)
12 rows selected.
Elapsed: 00:00:00.06 -
HOW TO: Post a SQL statement tuning request - template posting
This post is not a question, but similar to Rob van Wijk's "When your query takes too long ..." post should help to improve the quality of the requests for SQL statement tuning here on OTN.
On the OTN forum very often tuning requests about single SQL statements are posted, but the information provided is rather limited, and therefore it's not that simple to provide a meaningful advice. Instead of writing the same requests for additional information over and over again I thought I put together a post that describes how a "useful" post for such a request should look like and what information it should cover.
I've also prepared very detailed step-by-step instructions how to obtain that information on my blog, which can be used to easily gather the required information. It also covers again the details how to post the information properly here, in particular how to use the \ tag to preserve formatting and get a fixed font output:
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
So again: This post here describes how a "useful" post should look like and what information it ideally covers. The blog post explains in detail how to obtain that information.
In the future, rather than requesting the same additional information and explaining how to obtain it, I'll simply refer to this HOW TO post and the corresponding blog post which describes in detail how to get that information.
*Very important:*
Use the \ tag to enclose any output that should have its formatting preserved as shown below.
So if you want to use fixed font formatting that preserves the spaces etc., do the following:
\ This preserves formatting
\And it will look like this:
This preserves formatting
. . .Your post should cover the following information:
1. The SQL and a short description of its purpose
2. The version of your database with 4-digits (e.g. 10.2.0.4)
3. Optimizer related parameters
4. The TIMING and AUTOTRACE output
5. The EXPLAIN PLAN output
6. The TKPROF output snippet that corresponds to your statement
7. If you're on 10g or later, the DBMS_XPLAN.DISPLAY_CURSOR output
The above mentioned blog post describes in detail how to obtain that information.
Your post should have a meaningful subject, e.g. "SQL statement tuning request", and the message body should look similar to the following:
*-- Start of template body --*
The following SQL statement has been identified to perform poorly. It currently takes up to 10 seconds to execute, but it's supposed to take a second at most.
This is the statement:
select
from
t_demo
where
type = 'VIEW'
order by
id;It should return data from a table in a specific order.
The version of the database is 11.1.0.7.
These are the parameters relevant to the optimizer:
SQL>
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL>
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 8
SQL>
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL>
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
SQL>
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL>
SQL> select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 01-30-2009 16:25
SYSSTATS_INFO DSTOP 01-30-2009 16:25
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN CPUSPEEDNW 494,397
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
SQL> explain plan for
2 -- put your statement here
3 select
4 *
5 from
6 t_demo
7 where
8 type = 'VIEW'
9 order by
10 id;
Explained.
Elapsed: 00:00:00.01
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1390505571
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 60 | 0 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T_DEMO | 1 | 60 | 0 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_DEMO | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TYPE"='VIEW')
14 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> rem Set the ARRAYSIZE according to your application
SQL> set autotrace traceonly arraysize 100
SQL> select
2 *
3 from
4 t_demo
5 where
6 type = 'VIEW'
7 order by
8 id;
149938 rows selected.
Elapsed: 00:00:02.21
Execution Plan
Plan hash value: 1390505571
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 60 | 0 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T_DEMO | 1 | 60 | 0 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_DEMO | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TYPE"='VIEW')
Statistics
0 recursive calls
0 db block gets
149101 consistent gets
800 physical reads
196 redo size
1077830 bytes sent via SQL*Net to client
16905 bytes received via SQL*Net from client
1501 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
149938 rows processed
SQL>
SQL> disconnect
Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsThe TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.7.0 - Production on Mo Feb 23 10:23:08 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: orcl11_ora_3376_mytrace1.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select
from
t_demo
where
type = 'VIEW'
order by
id
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1501 0.53 1.36 800 149101 0 149938
total 1503 0.53 1.36 800 149101 0 149938
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 88
Rows Row Source Operation
149938 TABLE ACCESS BY INDEX ROWID T_DEMO (cr=149101 pr=800 pw=0 time=60042 us cost=0 size=60 card=1)
149938 INDEX RANGE SCAN IDX_DEMO (cr=1881 pr=1 pw=0 time=0 us cost=0 size=0 card=1)(object id 74895)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1501 0.00 0.00
db file sequential read 800 0.05 0.80
SQL*Net message from client 1501 0.00 0.69
********************************************************************************The DBMS_XPLAN.DISPLAY_CURSOR output:
SQL> -- put your statement here
SQL> -- use the GATHER_PLAN_STATISTICS hint
SQL> -- if you're not using STATISTICS_LEVEL = ALL
SQL> select /*+ gather_plan_statistics */
2 *
3 from
4 t_demo
5 where
6 type = 'VIEW'
7 order by
8 id;
149938 rows selected.
Elapsed: 00:00:02.21
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID d4k5acu783vu8, child number 0
select /*+ gather_plan_statistics */ * from t_demo
where type = 'VIEW' order by id
Plan hash value: 1390505571
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 0 | SELECT STATEMENT | | 1 | | 149K|00:00:00.02 | 149K| 1183 |
| 1 | TABLE ACCESS BY INDEX ROWID| T_DEMO | 1 | 1 | 149K|00:00:00.02 | 149K| 1183 |
|* 2 | INDEX RANGE SCAN | IDX_DEMO | 1 | 1 | 149K|00:00:00.02 | 1880 | 383 |
Predicate Information (identified by operation id):
2 - access("TYPE"='VIEW')
20 rows selected.I'm looking forward for suggestions how to improve the performance of this statement.
*-- End of template body --*
I'm sure that if you follow these instructions and obtain the information described, post them using a proper formatting (don't forget about the \ tag) you'll receive meaningful advice very soon.
So, just to make sure you didn't miss this point:Use proper formatting!
If you think I missed something important in this sample post let me know so that I can improve it.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/Alex Nuijten wrote:
...you missed the proper formatting of the Autotrace section ;-)Alex,
can't reproduce, does it still look unformatted? Or are you simply kidding? :-)
Randolf
PS: Just noticed that it actually sometimes doesn't show the proper formatting although the code tags are there. Changing to the \ tag helped in this case, but it seems to be odd.
Edited by: Randolf Geist on Feb 23, 2009 11:28 AM
Odd behaviour of forum software -
Tuning The Query By Using Xplain Plan
Hi Guys,
This particular query is taking a long time in the production reported by The SPE team .
SELECT
CASE
WHEN TPJRCSHDRW1.CASH_DRAWER_ID = 5000555
THEN 1
WHEN TPTRJO1.OTHER_CASH_DRAWER_ID = 5000555
THEN 2
END TRADE_TYPE,
TPDECO1.DENOMINATION_COUNT_ID,
TPDECO1.DENOMINATION_CATEGORY,
TPDECO1.DENOMINATION_VALUE,
TPDECO1.DENOMINATION_COUNT,
TPDECO1.DENOMINATION_TYPE,
TPDECO1.DENOMINATION_NAME,
TPTRJO1.TRANSACTION_ID,
TPTRJO1.TOTAL_VALUE,
TPTRJO1.TOTAL_VALUE_CCODE,
TPTRJO1.JOURNAL_ENTRY_ID,
TPJRCSHDRW1.CASH_DRAWER_ID,
TPTRJO1.OTHER_CASH_DRAWER_ID
FROM TRANSACTION_JOURNAL TPTRJO1
INNER JOIN JOURNAL_CASH_DRAWER TPJRCSHDRW1
ON TPTRJO1.JOURNAL_ENTRY_ID = TPJRCSHDRW1.JOURNAL_ENTRY_ID
LEFT OUTER JOIN DENOMINATION_COUNT TPDECO1
ON TPDECO1.JOURNAL_ENTRY_ID = TPJRCSHDRW1.JOURNAL_ENTRY_ID
WHERE ((TPJRCSHDRW1.CASH_DRAWER_ID = 5000555)
OR (TPTRJO1.OTHER_CASH_DRAWER_ID = 5000555))
AND (TPTRJO1.TRANSACTION_ID IN (563,590,1362,605,562,589,604))
AND (TPTRJO1.STATUS NOT IN ('I','V','R'))
AND ((TPTRJO1.REVERSED_BY) IS NULL) AND (TPJRCSHDRW1.CASH_DRAWER_DATE >= to_date('2009-07-24','yyyy-mm-dd') )
AND (TPTRJO1.TOTAL_VALUE <> 0)
AND ((TPTRJO1.OFFSET_ID) IS NULL);
When I am analysing the query by xplain_plan , I am getting this plan
Plan hash value: 3371088438
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 36557 | 3391K| 1445 (1)| 00:00:18 |
| 1 | CONCATENATION | | | | | |
| 2 | NESTED LOOPS OUTER | | 1 | 95 | 3 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 63 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TRANSACTION_JOURNAL | 1 | 40 | 1 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | I26_TRANSACTION_JOURNAL | 1 | | 1 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID| JOURNAL_CASH_DRAWER | 1 | 23 | 1 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | PKC_JOURNAL_CASH_D | 1 | | 1 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | DENOMINATION_COUNT | 12 | 384 | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PKC_DENOMINATION_COUNT | 20 | | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 36556 | 3391K| 1442 (1)| 00:00:18 |
| 11 | NESTED LOOPS | | 1817 | 111K| 715 (0)| 00:00:09 |
| 12 | TABLE ACCESS BY INDEX ROWID| JOURNAL_CASH_DRAWER | 1817 | 41791 | 351 (0)| 00:00:05 |
|* 13 | INDEX RANGE SCAN | SPE099_JOURNALCASHDRWR | 1817 | | 7 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID| TRANSACTION_JOURNAL | 1 | 40 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | PKC_TRANSACTION_JOURNAL | 1 | | 1 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | DENOMINATION_COUNT | 20 | 640 | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | PKC_DENOMINATION_COUNT | 20 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("TPTRJO1"."TOTAL_VALUE"<>0 AND "TPTRJO1"."REVERSED_BY" IS NULL AND
"TPTRJO1"."OFFSET_ID" IS NULL)
5 - access("TPTRJO1"."OTHER_CASH_DRAWER_ID"=5000555)
filter("TPTRJO1"."STATUS"<>U'I' AND "TPTRJO1"."STATUS"<>U'V' AND "TPTRJO1"."STATUS"<>U'R'
AND ("TPTRJO1"."TRANSACTION_ID"=562 OR "TPTRJO1"."TRANSACTION_ID"=563 OR
"TPTRJO1"."TRANSACTION_ID"=589 OR "TPTRJO1"."TRANSACTION_ID"=590 OR
"TPTRJO1"."TRANSACTION_ID"=604 OR "TPTRJO1"."TRANSACTION_ID"=605 OR
"TPTRJO1"."TRANSACTION_ID"=1362))
6 - filter("TPJRCSHDRW1"."DRAWER_SEQ" IS NOT NULL)
7 - access("TPTRJO1"."JOURNAL_ENTRY_ID"="TPJRCSHDRW1"."JOURNAL_ENTRY_ID" AND
"TPJRCSHDRW1"."CASH_DRAWER_DATE">=TO_DATE(' 2009-07-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("TPJRCSHDRW1"."CASH_DRAWER_DATE">=TO_DATE(' 2009-07-24 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'))
9 - access("TPDECO1"."JOURNAL_ENTRY_ID"(+)="TPJRCSHDRW1"."JOURNAL_ENTRY_ID")
13 - access("TPJRCSHDRW1"."CASH_DRAWER_ID"=5000555 AND
"TPJRCSHDRW1"."CASH_DRAWER_DATE">=TO_DATE(' 2009-07-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("TPJRCSHDRW1"."DRAWER_SEQ" IS NOT NULL)
14 - filter("TPTRJO1"."STATUS"<>U'I' AND "TPTRJO1"."STATUS"<>U'V' AND "TPTRJO1"."STATUS"<>U'R'
AND ("TPTRJO1"."TRANSACTION_ID"=562 OR "TPTRJO1"."TRANSACTION_ID"=563 OR
"TPTRJO1"."TRANSACTION_ID"=589 OR "TPTRJO1"."TRANSACTION_ID"=590 OR
"TPTRJO1"."TRANSACTION_ID"=604 OR "TPTRJO1"."TRANSACTION_ID"=605 OR
"TPTRJO1"."TRANSACTION_ID"=1362) AND "TPTRJO1"."TOTAL_VALUE"<>0 AND "TPTRJO1"."REVERSED_BY" IS
NULL AND "TPTRJO1"."OFFSET_ID" IS NULL AND LNNVL("TPTRJO1"."OTHER_CASH_DRAWER_ID"=5000555))
15 - access("TPTRJO1"."JOURNAL_ENTRY_ID"="TPJRCSHDRW1"."JOURNAL_ENTRY_ID")
17 - access("TPDECO1"."JOURNAL_ENTRY_ID"(+)="TPJRCSHDRW1"."JOURNAL_ENTRY_ID")
--There is an index SPE099_JOURNALCASHDRWR which is on
CASH_DRAWER_ID
CASH_DRAWER_DATE
DRAWER_SEQ
But I am wondering why there is TABLE ACCESS BY INDEX ROWID| JOURNAL_CASH_DRAWER when this col is availabe in the indexed table .
Can anyone Please suggest what improvements can be done on this query.WIll change in the table order will have some performance boost.
Please suggest ..
Thanks
PrafullaCould you please execute your query reported here below (pay attention to the gather_plan_statistics hint)
select /*+ gather_plan_statistics */
case
when tpjrcshdrw1.cash_drawer_id = 5000555
then 1
when tptrjo1.other_cash_drawer_id = 5000555
then 2
end trade_type,
tpdeco1.denomination_count_id,
tpdeco1.denomination_category,
tpdeco1.denomination_value,
tpdeco1.denomination_count,
tpdeco1.denomination_type,
tpdeco1.denomination_name,
tptrjo1.transaction_id,
tptrjo1.total_value,
tptrjo1.total_value_ccode,
tptrjo1.journal_entry_id,
tpjrcshdrw1.cash_drawer_id,
tptrjo1.other_cash_drawer_id
from
transaction_journal tptrjo1
inner join journal_cash_drawer tpjrcshdrw1
on tptrjo1.journal_entry_id = tpjrcshdrw1.journal_entry_id
left outer join denomination_count tpdeco1
on tpdeco1.journal_entry_id = tpjrcshdrw1.journal_entry_id
where ((tpjrcshdrw1.cash_drawer_id = 5000555)
or (tptrjo1.other_cash_drawer_id = 5000555))
and (tptrjo1.transaction_id in (563,590,1362,605,562,589,604))
and (tptrjo1.status not in ('I','V','R'))
and ((tptrjo1.reversed_by) is null)
and (tpjrcshdrw1.cash_drawer_date >= to_date('2009-07-24','yyyy-mm-dd') )
and (tptrjo1.total_value 0)
and ((tptrjo1.offset_id) is null);and post the formatted explain plan you will get using
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));IS one of the following indexed columns NULLABLE?
CASH_DRAWER_ID
CASH_DRAWER_DATE
DRAWER_SEQ
Best Regards
Mohamed Houri
www.hourim.wordpress.com
Edited by: Mohamed Houri on 14-juin-2012 7:07 -
Hi Experts,
A query on our production box is running slow (takes almost 2 minutes to complete). Below is the query:
SELECT a.stage, a.instnum, a.reason1, b.stage AS cur_stage
FROM lot_tbl a, part_tbl b
WHERE a.lid = b.lid
AND (b.partid LIKE 'PH3253%'
OR b.partid LIKE 'PH3561%'
OR b.partid LIKE 'PH3631%'
OR b.partid LIKE 'PH3711%'
OR b.partid LIKE 'PH3721%')
AND b.lottype = 'PR'
AND a.triggertype = 'P'
AND a.action = 'H'
AND a.instnum >= b.curprcdcurinstnum
AND b.stageorder < '7970'
AND a.recflag <> 'D'
ORDER BY stage, reason1 ;Explain plan shows nested loops taking the bulk of the time as shown in the excerpt from the explain plan:
| 24 | NESTED LOOPS | | 11416 | 1036K|
6059 (1)| 00:01:13 |
|* 25 | TABLE ACCESS BY INDEX ROWID| MES_TBL_ACTL | 314 | 19782 |
168 (0)| 00:00:03 |
|* 26 | INDEX RANGE SCAN | MES_IDX_ACTL_PART | 1020 | |
4 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | MES_IDX_FUTA_LOT | 88 | |
1 (0)| 00:00:01 |When we analyzed this query using sqltrpt.sql (we have license for that), there was a sql profile recommendation with an slightly different explain plan (part of which is shown below):
| 24 | NESTED LOOPS | | 164 | 15252 |
188 (0)| 00:00:03 |
|* 25 | TABLE ACCESS BY INDEX ROWID| MES_TBL_ACTL | 314 | 19782 |
31 (0)| 00:00:01 |
|* 26 | INDEX SKIP SCAN | MES_IDX_ACTL_CLASS | 1 | |
31 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | MES_IDX_FUTA_LOT | 1 | |
1 (0)| 00:00:01 |Further details:
select num_rows,last_analyzed from dba_tables where table_name='lot_tbl';
NUM_ROWS LAST_ANALYZ
6850820 10-NOV-2011
select num_rows,last_analyzed from dba_tables where table_name='part_tbl';
NUM_ROWS LAST_ANALYZ
265360 10-NOV-2011
685260 18-OCT-2011The stats for the schemas are collected every week and there are not many changes to the above objects.
Can you please help in tuning the above query? I have tried passing various hints, but nothing seems to be working.
Also one observation is that the optimizer is returning the number of output rows as 26 in the explain plan where as aroung 5000 rows are fetched in reality. I can post full explain plans if desired.
Thanks and Regards,
Rajesh K.Hi Dom,
Please find the explain plan of the query run with the gather_plan_statistics hint :
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem |
1Mem | Used-Mem |
PLAN_TABLE_OUTPUT
| 1 | SORT ORDER BY | | 1 | 26 | 5145 |00:01:40.35 | 25453 | 14770 | 619K|
472K| 550K (0)|
| 2 | CONCATENATION | | 1 | | 5145 |00:00:58.86 | 25453 | 14770 | |
| |
|* 3 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 1 | 491 |00:00:39.98 | 2529 | 1330 | |
| |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 1 | 2 | 2609 |00:00:02.30 | 922 | 62 | |
| |
|* 5 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 1 | 34 | 262 |00:00:00.01 | 386 | 0 | |
| |
|* 6 | INDEX RANGE SCAN | PART_IDX_PART | 1 | 111 | 448 |00:00:00.01 | 7 | 0 | |
| |
|* 7 | INDEX RANGE SCAN | LOT_IDX_LOT | 262 | 88 | 2346 |00:00:00.60 | 536 | 62 | |
| |
PLAN_TABLE_OUTPUT
|* 8 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 1 | 592 |00:00:01.61 | 1912 | 1087 | |
| |
| 9 | NESTED LOOPS | | 1 | 2 | 2566 |00:00:00.61 | 549 | 29 | |
| |
|* 10 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 1 | 34 | 169 |00:00:00.01 | 197 | 0 | |
| |
|* 11 | INDEX RANGE SCAN | PART_IDX_PART | 1 | 111 | 246 |00:00:00.01 | 5 | 0 | |
PLAN_TABLE_OUTPUT
| |
|* 12 | INDEX RANGE SCAN | LOT_IDX_LOT | 169 | 88 | 2396 |00:00:00.21 | 352 | 29 | |
| |
|* 13 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 1 | 2573 |00:00:06.50 | 15411 | 9451 | |
| |
| 14 | NESTED LOOPS | | 1 | 2 | 23226 |00:00:05.62 | 3533 | 215 | |
| |
PLAN_TABLE_OUTPUT
|* 15 | TABLE ACCESS BY INDEX ROWID| PArt_TBL | 1 | 34 | 1114 |00:00:00.01 | 1213 | 0 | |
| |
|* 16 | INDEX RANGE SCAN | PART_IDX_PART | 1 | 111 | 1549 |00:00:00.01 | 18 | 0 | |
| |
|* 17 | INDEX RANGE SCAN | LOT_IDX_LOT | 1114 | 88 | 22111 |00:00:01.69 | 2320 | 215 | |
| |
|* 18 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 1 | 526 |00:00:00.65 | 1503 | 844 | |
| |
PLAN_TABLE_OUTPUT
| 19 | NESTED LOOPS | | 1 | 2 | 2458 |00:00:00.60 | 428 | 21 | |
| |
|* 20 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 1 | 34 | 113 |00:00:00.01 | 191 | 0 | |
| |
|* 21 | INDEX RANGE SCAN | PART_IDX_PART | 1 | 111 | 226 |00:00:00.01 | 5 | 0 | |
| |
|* 22 | INDEX RANGE SCAN | LOT_IDX_LOT | 113 | 88 | 2344 |00:00:00.19 | 237 | 21 | |
PLAN_TABLE_OUTPUT
| |
|* 23 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 1 | 963 |00:00:05.06 | 4098 | 2058 | |
| |
| 24 | NESTED LOOPS | | 1 | 18 | 5028 |00:00:03.01 | 1931 | 75 | |
| |
|* 25 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 1 | 314 | 495 |00:00:00.04 | 911 | 0 | |
| |
PLAN_TABLE_OUTPUT
|* 26 | INDEX RANGE SCAN | PART_IDX_PART | 1 | 1020 | 1088 |00:00:00.01 | 15 | 0 | |
| |
|* 27 | INDEX RANGE SCAN | LOT_IDX_LOT | 495 | 88 | 4532 |00:00:00.57 | 1020 | 75 | |
| |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
3 - filter(("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P' AND "A"."INSTNUM">="B"."CURPRCDCURINSTNUM"))
5 - filter(("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970'))
6 - access("B"."PARTID" LIKE 'PH3721%')
filter("B"."PARTID" LIKE 'PH3721%')
7 - access("A"."LOTID"="B"."LOTID")
8 - filter(("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P' AND "A"."INSTNUM">="B"."CURPRCDCURINSTNUM"))
10 - filter(("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970'))
11 - access("B"."PARTID" LIKE 'PH3711%')
filter(("B"."PARTID" LIKE 'PH3711%' AND LNNVL("B"."PARTID" LIKE 'PH3721%')))
PLAN_TABLE_OUTPUT
12 - access("A"."LOTID"="B"."LOTID")
13 - filter(("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P' AND "A"."INSTNUM">="B"."CURPRCDCURINSTNUM"))
15 - filter(("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970'))
16 - access("B"."PARTID" LIKE 'PH3631%')
filter(("B"."PARTID" LIKE 'PH3631%' AND LNNVL("B"."PARTID" LIKE 'PH3711%') AND LNNVL("B"."PARTID" LIKE 'PH3721%')))
17 - access("A"."LOTID"="B"."LOTID")
18 - filter(("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P' AND "A"."INSTNUM">="B"."CURPRCDCURINSTNUM"))
20 - filter(("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970'))
21 - access("B"."PARTID" LIKE 'PH3561%')
filter(("B"."PARTID" LIKE 'PH3561%' AND LNNVL("B"."PARTID" LIKE 'PH3631%') AND LNNVL("B"."PARTID" LIKE 'PH3711%') AND
LNNVL("B"."PARTID" LIKE 'PH3721%')))
PLAN_TABLE_OUTPUT
22 - access("A"."LOTID"="B"."LOTID")
23 - filter(("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P' AND "A"."INSTNUM">="B"."CURPRCDCURINSTNUM"))
25 - filter(("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970'))
26 - access("B"."PARTID" LIKE 'PH3253%')
filter(("B"."PARTID" LIKE 'PH3253%' AND LNNVL("B"."PARTID" LIKE 'PH3561%') AND LNNVL("B"."PARTID" LIKE 'PH3631%') AND
LNNVL("B"."PARTID" LIKE 'PH3711%') AND LNNVL("B"."PARTID" LIKE 'PH3721%')))
27 - access("A"."LOTID"="B"."LOTID")Running SQL Advisor (sqltrpt.sql) on this query is giving sql profile recommendation which shows the run time of this query as 12 secs:
Explain plan of the recommendation:
2- Using SQL Profile
Plan hash value: 1628846902
| Id | Operation | Name | Rows | Bytes |
Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2106 | 191K|
976 (1)| 00:00:12 |
| 1 | SORT ORDER BY | | 2106 | 191K|
976 (1)| 00:00:12 |
| 2 | CONCATENATION | | | |
| |
|* 3 | tABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 30 |
1 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1336 | 121K|
149 (0)| 00:00:02 |
|* 5 | TABLE ACCESS BY INDEX ROWID|PART_TBL | 260 | 16380 |
19 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | PART_IDX_PART | 111 | |
1 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | LOT_IDX_LOT | 1 | |
1 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID |LOT_TBL | 1 | 30 |
1 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 68 | 6324 |
84 (0)| 00:00:02 |
|* 10 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 130 | 8190 |
19 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | PART_IDX_PART | 111 | |
1 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | LOT_IDX_LOT | 1 | |
1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 30 |
1 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 520 | 48360 |
518 (0)| 00:00:07 |
|* 15 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 998 | 62874 |
19 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | PART_IDX_PART | 111 | |
1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | LOT_IDX_LOT | 1 | |
1 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 30 |
1 (0)| 00:00:01 |
| 19 | NESTED LOOPS | | 18 | 1674 |
36 (0)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 34 | 2142 |
19 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | PART_IDX_PART | 111 | |
1 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | LOT_IDX_LOT | 1 | |
1 (0)| 00:00:01 |
|* 23 | TABLE ACCESS BY INDEX ROWID | LOT_TBL | 1 | 30 |
1 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 164 | 15252 |
188 (0)| 00:00:03 |
|* 25 | TABLE ACCESS BY INDEX ROWID| PART_TBL | 314 | 19782 |
31 (0)| 00:00:01 |
|* 26 | INDEX SKIP SCAN | PART_IDX_CLASS | 1 | |
31 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | LOT_IDX_LOT | 1 | |
1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P
' AND
"A"."INSTNUM">="B"."CURPRCDCURINSTNUM")
5 - filter("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970')
6 - access("B"."PARTID" LIKE 'PH3721%')
filter("B"."PARTID" LIKE 'PH3721%')
7 - access("A"."LOTID"="B"."LOTID")
8 - filter("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P
' AND
"A"."INSTNUM">="B"."CURPRCDCURINSTNUM")
10 - filter("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970')
11 - access("B"."PARTID" LIKE 'PH3711%')
filter("B"."PARTID" LIKE 'PH3711%' AND LNNVL("B"."PARTID" LIKE 'PH3721%
12 - access("A"."LOTID"="B"."LOTID")
13 - filter("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P
' AND
"A"."INSTNUM">="B"."CURPRCDCURINSTNUM")
15 - filter("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970')
16 - access("B"."PARTID" LIKE 'PH3631%')
filter("B"."PARTID" LIKE 'PH3631%' AND LNNVL("B"."PARTID" LIKE 'PH3711%
') AND
LNNVL("B"."PARTID" LIKE 'PH3721%'))
17 - access("A"."LOTID"="B"."LOTID")
18 - filter("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P
' AND
"A"."INSTNUM">="B"."CURPRCDCURINSTNUM")
20 - filter("B"."LOTTYPE"='PR' AND "B"."STAGEORDER"<'7970')
21 - access("B"."PARTID" LIKE 'PH3561%')
filter("B"."PARTID" LIKE 'PH3561%' AND LNNVL("B"."PARTID" LIKE 'PH3631%
') AND
LNNVL("B"."PARTID" LIKE 'PH3711%') AND LNNVL("B"."PARTID" LIKE '
PH3721%'))
22 - access("A"."LOTID"="B"."LOTID")
23 - filter("A"."RECFLAG"<>'D' AND "A"."ACTION"='H' AND "A"."TRIGGERTYPE"='P
' AND
"A"."INSTNUM">="B"."CURPRCDCURINSTNUM")
25 - filter("B"."PARTID" LIKE 'PH3253%' AND "B"."STAGEORDER"<'7970' AND LNNV
L("B"."PARTID"
LIKE 'PH3721%') AND LNNVL("B"."PARTID" LIKE 'PH3711%') AND LNNVL
("B"."PARTID" LIKE 'PH3631%')
AND LNNVL("B"."PARTID" LIKE 'PH3561%'))
26 - access("B"."LOTTYPE"='PR')
filter("B"."LOTTYPE"='PR')
27 - access("A"."LOTID"="B"."LOTID")Notice that an index skip scan of PART_IDX_CLASS which is on columns: COMCLASS and LOTTYPE is being used, which reduces the nested loops expense. But forcing index skip scan of that index through hint, the optimizer is not considering the index and is giving the same execution plan as before.
Thanks and Regards,
Rajesh K. -
Hi,
(Sorry) DB version is 11.2.0.2
I was trying to tune a sql using advisory. Present cost of the query is around 2100K. Advisory says to accept profile and the cost of the query will be around 7000.
But when sql profile is accepted the execution path of the query started doing 'HASH JOIN RIGHT SEMI' and the temp usage is so so high.
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | | | 1219G| 7142 (100)| |
| 1 | LOAD TABLE CONVENTIONAL | | | | 1219G| | |Because the temp usage is so high the temp tablespace keep growing and growing. How do i optimize this query?
thanks,
baskar.l
Edited by: baskar.l on Feb 26, 2012 10:05 PMHi Baskar,
cost of a SQL statement is not a very informative quantity. It's an estimate of how much resources would be consumed during the query's execution, not the actual figure.
You should look at actual rowsource statistics, not at optimizer estimates. Use gather_plan_statistics hint and then display using
select * from table(dbms_xplan.display_cursor(<sql_id>, null, 'allstats last'));and post results here.
Best regards,
Nikolay -
Can some help me please below query has been running for a long time I am unable to fix it
SELECT lmt.tab, pr.tab6, pr.tab7,
pr.activity_id, pr.resource_id, lmt.tab2,
lmt.tab5, pr.txn_lmt_trans_id, pr.analysis_type,
pr.resource_type, pr.resource_category, pr.resource_sub_cat,
pr.trans_dt, cd.start_dt, cd.end_dt, pr.currency_cd, pr.rt_type,
pr.resource_quantity, pr.resource_amount, pr.foreign_amount,
pr.foreign_currency, 2, 'S', pr.resource_id_from,
hdr.contract_sign_dt, cd.retainage_id, cd.discount_id, 0, 0,
cd.limit_bi_cntrl_flg, hdr.ca_rqst_src, 0, hdr.currency_cd,
hdr.rt_type, 0, 0, pr.bi_distrib_status, pr.gl_distrib_status
FROM ps_c1 lmt, ps_c2 hdr, ps_c3 cd,
ps_c4 pr
WHERE lmt.tab = 836626
AND hdr.tab2 = lmt.tab2
AND cd.tab2 = lmt.tab2
AND cd.tab5 = lmt.tab5
AND cd.pricing_structure = 'RATE'
AND pr.tab6 = cd.tab6_pc
AND pr.tab2 = cd.tab2
AND pr.tab5 = cd.tab5
AND (pr.analysis_type IN ('BIL', 'OLT', 'PMR', 'ROL')
AND pr.bi_distrib_status <> 'I'
OR pr.analysis_type = 'REV'
AND pr.gl_distrib_status IN ('C', 'N'))
AND NOT pr.ca_fee_status IN ('2', '3', '4', '5')
AND 0 >= (SELECT count(*)
FROM ps_ca_lmt4_tao4 lmt4
WHERE lmt4.tab = 836626
AND lmt4.tab6 = pr.tab6
AND lmt4.tab7 = pr.tab7
AND lmt4.activity_id = pr.activity_id
AND lmt4.resource_id = pr.resource_id))
Below is the execution plan
ID PID Operation Name Rows Bytes Cost CPU Cost IO Cost Temp space IN-OUT PQ Dist PStart PStop
0 SELECT STATEMENT 2 598 99885 2G 99823
1 0 NESTED LOOPS
2 1 NESTED LOOPS 1 299 99885 2G 99823
3 2 NESTED LOOPS 1 264 99883 2G 99821
4 3 NESTED LOOPS 3 273 8 114779 8
5 4 INDEX RANGE SCAN ps_c1 6 138 1 8321 1
6 4 TABLE ACCESS BY INDEX ROWID ps_c3 1 68 2 17743 2
7 6 INDEX UNIQUE SCAN ps_c3 1 1 9021 1
8 3 TABLE ACCESS BY INDEX ROWID ps_c4 1 173 33292 671M 33271
9 8 INDEX RANGE SCAN ps_c4 55808 10139 320M 10129
10 9 INDEX UNIQUE SCAN PS_CA_LMT4_TAO4 1 46 0 1050 0
11 2 INDEX UNIQUE SCAN ps_c2 1 1 9021 1
12 1 TABLE ACCESS BY INDEX ROWID ps_c2 1 35 2 17413 2
Can someone please help its really kind of urgentcheck the cardinalities: the CBO expects to access only a few rows and uses a lot of NL joins - and that's probably not the best solution. You could start with a llok at the cardinality of step 5, the index range scan on ps_c1. The CBO expects only 6 rows - is this a good guess? Of course you could just create a plan with rowsource statistics (gather_plan_statistics hint) and compare E- and A-rows.
-
Explain plan : need advice in improving performance
Hi,
DB : 10.2.0.4
platform: Solaris
SGA: 8 G
one of my query is taking too much time, explain plan gives below output.
kindly advise what i can do to improve the performance
PLAN_TABLE_OUTPUT
Plan hash value: 430877948
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 8143 | 1081K| 31130 (1)| 00:06:14 |
|* 1 | FILTER | | | | | |
|* 2 | TABLE ACCESS BY INDEX ROWID| ID_TICKET_DETAILS | 8143 | 1081K| 494 (0)| 00:00:06 |
|* 3 | INDEX SKIP SCAN | TKT_IDX_21 | 1 | | 493 (0)| 00:00:06 |
|* 4 | TABLE ACCESS BY INDEX ROWID| ID_DELIVERY_DEBIT_SLIP_DETAIL | 1 | 34 | 3 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 2 | 124 | 7 (0)| 00:00:01 |
|* 6 | TABLE ACCESS FULL | ID_DELIVERY_DEBIT_SLIP_HEADER | 32243 | 881K| 2 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | DSD_DELIVERY_DEBIT_UKEY | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "ID_DELIVERY_DEBIT_SLIP_HEADER"
"ID_DELIVERY_DEBIT_SLIP_HEADER","ID_DELIVERY_DEBIT_SLIP_DETAIL" "ID_DELIVERY_DEBIT_SLIP_DETAIL" WHERE
"DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
"DSH_COMPANY"="DSD_COMPANY" AND "DSD_TICKET_NUMBER" IS NOT NULL AND
LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER") AND "DSH_DELIVERY_DEBIT"='DEBIT'))
2 - filter((:1 IS NULL OR "TICKET_AIRLINE"=:2) AND "TICKET_REFERENCE_2" IS NULL AND
"TICKET_RECEIPT_NUMBER" IS NULL AND "TICKET_CARD_RECEIPT_NUMBER" IS NULL AND
"TICKET_SYSTEM_DOC_NUMBER" IS NULL)
3 - access("TICKET_REFERENCE_1" IS NULL)
filter("TICKET_REFERENCE_1" IS NULL AND TO_NUMBER("TICKET_COMPANY")=1)
4 - filter("DSD_TICKET_NUMBER" IS NOT NULL AND LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER"))
6 - filter("DSH_DELIVERY_DEBIT"='DEBIT')
7 - access("DSH_COMPANY"="DSD_COMPANY" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
"DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER")
Note
- SQL profile "SYS_SQLPROF_014f902e2ea4c002" used for this statementsome comments:
it would be more simple to read the plan with indentatitions: you could use a fixed-width font
it's hard to tell much about the plan without seeing the corresponding query (though in this case the predicate section gives some information on the query - especially step 1)
the plan shows the use of a sql profile: so the CBO uses additional statistics to generate the plan
in step 3 there is an index skip scan: that's only a good idea if there are few distinct values for the leading column of the index and the selectivity of "TICKET_REFERENCE_1" IS NULL is good
in step 6 there is a Full Table Scan for the driving table of a nested loops join: the cost value for the scan is very small and so is the cost for the complete NL join - and that could be misleading
I would use the gather_plan_statistics hint to get a plan with rowsource statistics to check if the cardinalities the CBO works with are correct. If they are not you could try to disable the profile (or create a new profile; of course after checking who created the profile and for what reasons). With an accurate sql profile the CBO should have enough information to create an accurate plan in most cases.
Regards
Martin -
Any room for improvement for this query? Explain Plan attached.
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??
select sum(CONF
when (cd.actl_qty - cd.total_alloc_qty - lsd.Q < 0) then
0
else
cd.actl_qty - cd.total_alloc_qty - lsd.Q
end)
from (select sum(reqd_qty) as Q, ITEM_ID as ITEM
from SHIP_DTL SD
where exists (select 1
from CONF_dtl
where CONF_nbr = '1'
and ITEM_id = SD.ITEM_id)
group by ITEM_id) lsd,
CONF_dtl cd
where lsd.ITEM = cd.ITEM_id
and cd.CONF_nbr = '1'Total number of rows in the tables involved
select count(*) from CONF_DTL;
COUNT(*)
1785889
select count(*) from shp_dtl;
COUNT(*)
286675
Explain Plan
PLAN_TABLE_OUTPUT
Plan hash value: 2325658044
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 39 | 4 (25)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 39 | | |
| 2 | VIEW | | 1 | 39 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 1 | 117 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID | SHIP_DTL | 1 | 15 | 1 (0)| 00:00:01
| 5 | NESTED LOOPS | | 1 | 117 | 3 (0)| 00:00:01 |
| 6 | MERGE JOIN CARTESIAN | | 1 | 102 | 2 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | CONF_DTL | 1 | 70 | 1 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
| 9 | BUFFER SORT | | 1 | 32 | 1 (0)| 00:00:01 |
| 10 | SORT UNIQUE | | 1 | 32 | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| CONF_DTL | 1 | 32 | 1 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | SHIP_DTL_IND_6 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
8 - access("CD"."CONF_NBR"='1')
12 - access("CONF_NBR"='1')
13 - access("ITEM_ID"="SD"."ITEM_ID")
filter("ITEM_ID"="CD"."ITEM_ID")Citizen_2 wrote:
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??You say that the table stats are up-to-date, but is the following assumption of the optimizer correct:
select count(*)
from CONF_dtl
where CONF_nbr = '1';Does this query return a count of 1? I doubt that, but that's what Oracle estimates in the EXPLAIN PLAN output. Based on that assumption you get a cartesian join between the two CONF_DTL table instances, and the result - which is still expected to be one row at most - is then joined to the SHIP_DTL table using a NESTED LOOP.
If above assumption is incorrect, the number of rows generated by the cartesian join can be tremendous rendering the NESTED LOOP operation quite inefficient.
You can verify this by using the DBMS_XPLAN.DISPLAY_CURSOR function together with the GATHER_PLAN_STATISTICS hint, if you're already on 10g or later.
For more information regarding the DISPLAY_CURSOR function, see e.g. here: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
It will show you the actual cardinalities compared to the estimated cardinalities.
If the estimate of the optimizer is incorrect, you should find out why. There still might be some issues with the statistics, since this is most obvious reason for incorrect estimates.
Are your index statistics up-to-date?
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Maybe you are looking for
-
My Apple TV 2 is working great but-
I really want to add some radio stations to it. Apparently, the list of stations that comes up is on an Apple server and is static. But I question this because on my list of stations is an obscure radio station that I had found on my own and that I h
-
Brand new Yoga 2 11 - Super slow web browsing
We got a new Yoga 2 11 this morning, and the web browsing is excruciatingly slow, whether using IE, FireFox or Chrome. The only downloads or installs of any kind have been IE & FF. Based on searching this forum, I increased the minimum processor pow
-
I have a Macbook Pro 2.33. It recently starting making some noise. I suspected it was the fan. I went on youtube to see how to replace a fan. I found several videos on how to do that. I opened the laptop, powered it up and found that the fan on the r
-
I've been doing some reading on sessions and their uses (textbook and a little bit of searching on this newsgroup). I'm trying to get a feel for when it's appropriate to use sessions to maintain data and when it's not. According to the chapter I've r
-
Hi , I want to create a Invoice list for the invoices. When i create the invoice list , message the invoice is not relevant to invoice list is appearing. i have check "Billiing document type to Invoice list type" Also checked the VTFF copy control to