10g Explain Plan ?
First off I am mostly an end user, just write queries and execute them, I have done very little administration under Oracel databases, besides the 10g Express edition, I have never installed anything else form oracle.
My company recently upgraded from 9i to 10g, and I am noticing that the cost is almost double vs. the old 9i db, using the same exact query and I am also noticing some new things in the explain plan. I use TOAD for my connection to the database at work and to view Explain plans.
Here is one of the explain plans: I wanted to learn what some of this new terminology means, like what is: (I've replaced the real schemas with the word schema, and tables with Table).
What is PX ?
PX COORDINATOR ?
Plan
CREATE TABLE STATEMENT ALL_ROWSCost: 15,471 Bytes: 126,893,988 Cardinality: 2,440,269
9 LOAD AS SELECT Schema.Table
8 PX COORDINATOR
7 PX SEND QC (RANDOM) SYS.:TQ10001 Cost: 15,339 Bytes: 126,893,988 Cardinality: 2,440,269
6 SORT GROUP BY Cost: 15,339 Bytes: 126,893,988 Cardinality: 2,440,269
5 PX RECEIVE Cost: 15,339 Bytes: 126,893,988 Cardinality: 2,440,269
4 PX SEND HASH SYS.:TQ10000 Cost: 15,339 Bytes: 126,893,988 Cardinality: 2,440,269
3 SORT GROUP BY Cost: 15,339 Bytes: 126,893,988 Cardinality: 2,440,269
2 PX BLOCK ITERATOR Cost: 15,331 Bytes: 126,893,988 Cardinality: 2,440,269 Partition #: 8 Partitions accessed #1 - #16
1 TABLE ACCESS FULL TABLE schema.Table2 Cost: 15,331 Bytes: 126,893,988 Cardinality: 2,440,269 Partition #: 8 Partitions accessed #1 - #16
PX = Parallel eXecution: query is executed on multiple processors. This may result from parameter changes and/or new defaults.
Using Parallel Execution, one session (your original session) coordinates the various extra processes.
Sybrand Bakker
Senior Oracle DBA
Similar Messages
-
Please help to understand 10g explain plan
Hello
I am trying to optimize one query. I have taken explain plan of this query in 9i and 10g database both.
Explain plan for index scan is different in 9i and 10g. In 9i inedex was scaned with INDEX RANGE SCAN NON-UNIQUE and in 10g index is scanned with
INDEX RANGE SCAN.
Can anybody explain the difference of scanning an index in 9i and 10g? Cost in 9i was 74 and now in 10g it is 1134.
Thanks in advanceWell, if you tables structures and indexes are the same in both databases then that's unlikely to be an issue, however you need to check other factors such as whether statistics have been gathered for the data recently.
For helpful info on optimising queries and what to look out for read the following thread...
[When your query takes too long|http://forums.oracle.com/forums/thread.jspa?messageID=1812597#1812597] -
Diff in explain plan of 9i and 10g
I am beginner and just started my dba career. Please can you help me by giving me the differences between a explain plan executed in oracle 9i and 10g. Why is there variations in the cost,cardinality and bytes. Is it that 9is explain plan is executed in a different way when compared to 10g's. Please help me out regarding the same.
Are your generating it against same sets of rows or using different tables ? we would love to see more information and could you please your explain plan on the board ?
hare krishna
Alok -
Explain Plan for Materialized Views in 10g
I am verifying explain plan for few queries on 10g as compared to 9i I was wondering in Materialized Views queries MAT_VIEW ACCESS instead of TABLE ACCESS is it expected behaviour or am missing something?
Couldn't find information in 10g documentation
thanks in advanceI've put together a query for the v$sql_plan in 9iR2.
Depending on what you use, you can probably drop some columns (eg OTHER and partition columns) and you could drive it from the v$session by getting the hash_value from there for the sid you are interested in :
(select * from v$sql_plan where hash_value =
(select sql_hash_value from v$session where sid=:sid))
select level, optimizer, lpad('_',1*(level-1),'_')||operation operation,
options, object_owner||'.'||object_name obj_name, search_columns,
ltrim(to_char(cardinality,'999,999,999')) no_rows,
ltrim(to_char(bytes/1024,'999,999')) kbytes, cost tot_cost,
object_node link, id, parent_id, other_tag||':'||other other,
partition_start, partition_stop, cpu_cost, io_cost,
access_predicates, filter_predicates,
round(temp_space/(1024*1024),2) temp_space_mb
from (select * from v$sql_plan where hash_value = :hash_val)
start with id=0
connect by prior id = parent_id and prior child_number = child_number
order by child_number, id, position; -
Explain plan - lower cost but higher response time in 11g compared to 10g
Hello,
I have a strange scenario where 'm migrating a db from standalone Sun FS running 10g RDBMS to a 2-Node Sun/ASM 11g RAC env. The issue is with response time of queries -
In 11g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANALYZED NUM_ROWS
11-08-2012 18:21:12 3413956
Elapsed: 00:00:00.30
In 10g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANAL NUM_ROWS
07-NOV-12 3502160
Elapsed: 00:00:00.04If you look @ the response times, even a simple query on the dba_tables takes ~8 times. Any ideas what might be causing this? I have compared the XPlans and they are exactly the same, moreover, the cost is less in the 11g env compared to the 10g env, but still the response time is higher.
BTW - 'm running the queries directly on the server, so no network latency in play here.
Thanks in advance
aBBy.*11g Env:*
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1104 | 376K| 394 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1104 | 376K| 394 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1104 | 376K| 393 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1136 | | 15 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
*10g Env:*
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1137 | 373K| 389 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1137 | 373K| 389 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1137 | 373K| 388 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1137 | | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
The query used is:
explain plan for
select
NCP_DETAIL_ID ,
NCP_ID ,
STATUS_ID ,
FIBER_NODE ,
NODE_DESC ,
GL ,
FTA_ID ,
OLD_BUS_ID ,
VIRTUAL_NODE_IND ,
SERVICE_DELIVERY_TYPE ,
HHP_AUDIT_QTY ,
COMMUNITY_SERVED ,
CMTS_CARD_ID ,
OPTICAL_TRANSMITTER ,
OPTICAL_RECEIVER ,
LASER_GROUP_ID ,
UNIT_ID ,
DS_SLOT ,
DOWNSTREAM_PORT_ID ,
DS_PORT_OR_MOD_RF_CHAN ,
DOWNSTREAM_FREQ ,
DOWNSTREAM_MODULATION ,
UPSTREAM_PORT_ID ,
UPSTREAM_PORT ,
UPSTREAM_FREQ ,
UPSTREAM_MODULATION ,
UPSTREAM_WIDTH ,
UPSTREAM_LOGICAL_PORT ,
UPSTREAM_PHYSICAL_PORT ,
NCP_DETAIL_COMMENTS ,
ROW_CHANGE_IND ,
STATUS_DATE ,
STATUS_USER ,
MODEM_COUNT ,
NODE_ID ,
NODE_FIELD_ID ,
CREATE_USER ,
CREATE_DT ,
LAST_CHANGE_USER ,
LAST_CHANGE_DT ,
UNIT_ID_IP ,
US_SLOT ,
MOD_RF_CHAN_ID ,
DOWNSTREAM_LOGICAL_PORT ,
STATE
from markethealth.NCP_DETAIL_TAB
WHERE UNIT_ID = :B1
ORDER BY UNIT_ID, DS_SLOT, DS_PORT_OR_MOD_RF_CHAN, FIBER_NODE
This is the query used for Query 1.
Stats differences are:
1. Rownum differes by apprx - 90K more rows in 10g env
2. RAC env has 4 additional columns (excluded in the select statement for analysis purposes).
3. Gather Stats was performed with estimate_percent = 20 in 10g and estimate_percent = 50 in 11g. -
Explain plan, Oracle 10g, AWR, ASH etc etc
Hi,
I'm obviously not searching on the right terms but using one of the following : AWR, ASH, ADDM, isn't it possible to get the explain plan for a certain SQL_ID after the fact?
I was sure that using ash and specifying the SQL_ID that one could have the explain plan, but I don't have it in the ASH Report. We don't have Grid in place, only snapshots taken every hour.
cheers.Thankyou both for your very quick replies, just what I needed.
Edited by: mattyb on Mar 25, 2009 2:06 PM -
Problems with explain plan and statement
Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AMtobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
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/ -
Cpu time is not getting displayed in explain plan
Hi All,
I am trying to analyze one query using explain plan .like below
1) explain plan for
SELECT /*+ parallel(tsp,8) use_hash( tsp tp) */ count(1)
FROM router tp,
receiver tsp
WHERE tp.rs = tsp.rp
AND creater_date >=to_date('04032009000000','ddmmyyyyhh24miss')
and tsp.XVF is not null
and tp.XVF is not null
and tp.role_name='BR';
2)@$ORACLE_HOME/rdbms/admin/utlxpls.sql
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?
Pls help
Thanksam_73798 wrote:
I am trying to analyze one query using explain plan .like below
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?You need to mention your database version (4-digits, e.g. 9.2.0.8).
In Oracle 9i CPU costing is disabled by default, you need to gather WORKLOAD system statistics to enable the CPU costing.
In 10g CPU costing is enabled by default and uses default NOWORKLOAD system statistics if no WORKLOAD system statistics have been gathered. It can only be disabled by setting an undocumented parameter or by changing the OPTIMIZER_FEATURES_ENABLE parameter back to 9i compatibility.
You can check the status of your system statistics by running the following query in SQL*Plus:
column sname format a20
column pname format a20
column pval2 format a20
select
sname
, pname
, pval1
, pval2
from
sys.aux_stats$;Can you show us the actual (complete) output you get from "utlxpls.sql"? Use the \ tag to preserve formatting here:
\output
\will show asoutput
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/ -
Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)
Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE OWNER
SYNONYM APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME TABLE_OWNER TABLE_NAME DB_LINK
PO_LINES PO PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
C
8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 252 | 0 (0)|
|* 1 | FILTER | | | | |
| 2 | TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K| 106 (4)|
Predicate Information (identified by operation id):
1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE OWNER
TABLE POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneeshNext time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM -
Question regarding using of Explain Plan
Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
I am using Oracle 9i as back end .
Please tell me how can i use feature of Explain Plan Feature for the below query.
SELECT * FROM emp WHERE empno = 7369
Thanks in advance.[email protected] wrote:
Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
I am using Oracle 9i as back end .
Please tell me how can i use feature of Explain Plan Feature for the below query.
SELECT * FROM emp WHERE empno = 7369
Kiran,
Firstly , before anything else, I would suggest to change your handle to anything else and remove the email id from it. Its not good to have the id displayed in any public forum.
About the question, unfortunately, its not that easy to answer. To understand explain plan and how to use it, you need to understand that algorithm/mechanism, whatever you feel like saying, that generates it. Because, explain plan is just the outcome of that mechanism, a final product, its the result of some inputs given by you in the form of your query, predicates, joins and their types and that all bring up the explain plan. Explain plan is basically the constitution of some steps which are used /fixed by optimizer to run the query. I would suggest that you read this page from cover to cover to understand some of the steps and their meanings which are shown to you in the plan. I am giving 10g link as this is a more better version of optimizer than the previous ones and I would suggest you to do experiments on 10g only.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i21299
And I would suggest that you collect these following books and start reading them. I haven't yet found any thing better than these books.
[Cost Based Oracle Fundamentals (Jonathan Lewis)|http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Experts-Voice/dp/1590596366]
[Troubleshooting Oracle Performance(Christian Antognini )|http://www.amazon.com/Troubleshooting-Oracle-Performance-Christian-Antognini/dp/1590599179/ref=sr_1_1?ie=UTF8&s=books&qid=1240078634&sr=1-1]
[Effectuve Oracle By Design(Tom Kyte)|http://www.amazon.com/Effective-Oracle-Design-Osborne-ORACLE/dp/0072230657/ref=sr_1_1?ie=UTF8&s=books&qid=1240078698&sr=1-1]
It would be real long journey before the mazes of optimizer and explain would be clear so make sure you have patience as well.
HTH
Aman.... -
Just Question about Explain Plan.
Q- 1. Is it Possible to trace a current session query from other session without altering that session. If How can i do it. I can not do it with v$session becuase it will be different sessionid. Also i ndon't want to alter session.
Q-2 I have SQl statement gives different EXECUTION PLAN on 9R2 and 10g. Is it possible.
Can any one explain this pleasethank you smoradi and william for your response.
Sorry for Long Post
I tried to post it before also. i did not get the conculsion. This are the final results i got. So can any one Help me.
Following are the information
I have TKPROF result. can any one expalin me this what it means. Where are wait time.
I got the explain plan as unnder can any one explain me please i am still having problem solving this
can any one explain me how to improve the perfomance.
1.SS_SKU_STORE_WEEk is the biggest table around 12 million rows.
2. SS_SKU_STORE 50 thosand rows
3. ITEM 44 thousand
4.Rest all tables are small.
SQL> SELECT /*+ index( ss_sku_store SS_SKU_ST_PK ) */
2 TO_NUMBER( ss_sku_store.sku || ss_sku_store.store_num) rowkey,
3 ss_sku_store.sku psku,
4 ' ' || INITCAP( item.descrip ) description,
5 dept_id,
6 TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) subdepartment,
7 TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) ||'.'|| TO_CHAR( class_id ) class,
8 NVL( vendor_id, -1 ),
9 NVL( buyer_num, -1),
10 NVL( TRIM(pattern_cd), -1),
11 DECODE(Color_Cd, 0, -1, NVL( Color_Cd, -1)) Color_Cd,
12 NVL( size_cd, -1),
13 -1 list_id,
14 ss_sku.sku skuattribute,
15 ss_sku_store.store_num pstore,
16 INITCAP( store.name ) location,
17 store.state,
18 NVL( INITCAP( regional_vp), :cUNASSIGNED) regional_vp,
19 NVL( INITCAP( regional_merch_mgr), :cUNASSIGNED) regional_merch_mgr,
20 NVL( INITCAP( district_mgr), :cUNASSIGNED) district_mgr,
21 NVL( INITCAP( area_mgr), :cUNASSIGNED) area_mgr,
22 NVL( sq_footage, -1),
23 SUBSTR( '000' || fashion_attribute.seq, -3, 3 ) || NVL( store.fashion_att_cd, '' ) fashion_att_cd,
24 SUBSTR( '000' || cust_profile.seq, -3, 3 ) || NVL( store.cust_type_cd, '' ) cust_type_cd,
25 NVL( section_count, -1) section_count,
26 '000' corp_vol_grp_cd,
27 0 storegroup,
28 store.store_num storeattribute,
29 0 storesort,
30 submit_status,
31 DECODE( current_user, :pUserID, shipment_schedules.check_staged_sku(ss_sku_store.sku,-1), 1) lockedflag,
32 '' aggregatedrowkey,
33 '' AttributeDescription,
34 starting_on_hand onhand
35 FROM cust_profile,
36 fashion_attribute,
37 ( SELECT vendor_id,
38 sku
39 FROM item_vendor
40 WHERE sku IN ( SELECT sku
41 FROM ss_session_sku
42 WHERE user_key = :pUserKey)
43 AND primary_flag = :cTRUE ) primaryvendor,
44 ( SELECT SKU,
45 DECODE( status, 0, 0, DECODE( status, 1 ,0 ,1) ) AS submit_status
46 FROM ( SELECT /*+ full(ss_session_sku) use_nl(ss_session_sku,ss_sku_store_week) index(ss_sku_store_week SS_SKU_STR_WK_SKU )*/
47 SS_SKU_Store_Week.SKU,
48 MAX( NVL( ssk_week_status, 0 ) ) AS status
49 FROM ss_session_sku,
50 ss_sku_store_week
51 WHERE user_key = :pUserKey
52 AND ss_sku_store_week.sku = ss_session_sku.sku
53 GROUP BY ss_sku_store_week.sku )
54 ) sku_status,
55 ss_sku,
56 store,
57 ss_sku_store,
58 item
59 WHERE sku_status.sku = item.sku
60 AND sku_status.sku = ss_sku.sku
61 AND sku_status.sku = ss_sku_store.sku
62 AND sku_status.sku = primaryvendor.sku
63 AND sku_status.sku = sku_status.sku
64 AND ss_sku_store.store_num = store.store_num
65 AND store.cust_type_cd = cust_profile.cust_type_cd(+)
66 AND store.fashion_att_cd = fashion_attribute.fashion_att_cd(+)
67 ORDER BY ss_sku_store.sku,
68 ss_sku_store.store_num;
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=531 Card=3203 Bytes=948088)
1 0 SORT (GROUP BY) (Cost=531 Card=3203 Bytes=948088)
2 1 HASH JOIN (RIGHT OUTER) (Cost=323 Card=3203 Bytes=948088)
3 2 TABLE ACCESS (FULL) OF 'CUST_PROFILE' (TABLE) (Cost=2 Card=16 Bytes=304)
4 2 HASH JOIN (RIGHT OUTER) (Cost=321 Card=3203 Bytes=887231)
5 4 TABLE ACCESS (FULL) OF 'FASHION_ATTRIBUTE' (TABLE) (Cost=2 Card=9 Bytes=162)
6 4 HASH JOIN (Cost=318 Card=3203 Bytes=829577)
7 6 TABLE ACCESS (FULL) OF 'STORE' (TABLE) (Cost=15 Card=1289 Bytes=105698)
8 6 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'SS_SKU_STORE' (TABLE) (Cost=3 Card=707 Bytes=17675)
9 8 NESTED LOOPS (Cost=302 Card=3203 Bytes=566931)
10 9 HASH JOIN (Cost=287 Card=5 Bytes=760)
11 10 NESTED LOOPS (Cost=284 Card=5 Bytes=655)
12 11 NESTED LOOPS (Cost=273 Card=5 Bytes=270)
13 12 NESTED LOOPS (Cost=252 Card=86 Bytes=3784)
14 13 NESTED LOOPS (Cost=17 Card=13 Bytes=468)
15 14 SORT (UNIQUE) (Cost=1 Card=13 Bytes=130)
16 15 INDEX (RANGE SCAN) OF 'SS_SESS_SKU_PK' (INDEX (UNIQUE)) (Cost=1 Card=13 Bytes=130)
17 14 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_VENDOR' (TABLE) (Cost=3 Card=1 Bytes=26)
18 17 INDEX (RANGE SCAN) OF 'ITEM_VENDOR_ITEM_FK_IDX' (INDEX) (Cost=2 Card=1)
19 13 PARTITION HASH (ITERATOR) (Cost=65 Card=7 Bytes=56)
20 19 TABLE ACCESS (BY LOCAL INDEX ROWID)OF 'SS_SKU_STORE_WEEK' (TABLE) (Cost=65 Card=7 Bytes=56)
21 20 INDEX (RANGE SCAN) OF 'SS_SKU_STR_WK_SKU' (INDEX) (Cost=14 Card=6427)
22 12 TABLE ACCESS (FULL) OF 'SS_SESSION_SKU'(TABLE) (Cost=0 Card=1 Bytes=10)
23 11 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (TABLE) (Cost=2 Card=1 Bytes=77)
24 23 INDEX (UNIQUE SCAN) OF 'ITEM_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
25 10 TABLE ACCESS (FULL) OF 'SS_SKU' (TABLE) (Cost=3 Card=343 Bytes=7203)
26 9 PARTITION HASH (ITERATOR) (Cost=1 Card=211)
27 26 INDEX (RANGE SCAN) OF 'SS_SKU_ST_PK' (INDEX(UNIQUE)) (Cost=1 Card=211)
EXPLIAN PLAN AND DATA FROM TKPROF
all count cpu elapsed disk query current rows
Parse 2 0.00 0.01 0 0 0 0
Execute 2 1.35 1.30 0 0 0 0
Fetch 5 0.14 0.16 5 2497 0 111
total 9 1.49 1.49 5 2497 0 111
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 30 (MDSEADMIN)
Rows Row Source Operation
0 PX COORDINATOR FORCED SERIAL (cr=797 pr=2 pw=0 time=42745 us)
0 PX SEND QC (ORDER) :TQ10005 (cr=797 pr=2 pw=0 time=42711 us)
0 SORT ORDER BY (cr=797 pr=2 pw=0 time=42701 us)
0 PX RECEIVE (cr=797 pr=2 pw=0 time=42627 us)
0 PX SEND RANGE :TQ10004 (cr=797 pr=2 pw=0 time=42617 us)
0 BUFFER SORT (cr=797 pr=2 pw=0 time=42609 us)
0 NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42532 us)
0 NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42520 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42510 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42502 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42495 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42488 us)
0 HASH JOIN (cr=797 pr=2 pw=0 time=42480 us)
1 BUFFER SORT (cr=5 pr=1 pw=0 time=13357 us)
1 PX RECEIVE (cr=5 pr=1 pw=0 time=13300 us)
1 PX SEND HASH :TQ10001 (cr=5 pr=1 pw=0 time=13291 us)
1 TABLE ACCESS BY INDEX ROWID ITEM_VENDOR (cr=5 pr=1 pw=0 time=13280 us)
3 NESTED LOOPS (cr=4 pr=0 pw=0 time=423 us)
1 SORT UNIQUE (cr=1 pr=0 pw=0 time=189 us)
1 INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=86 us)(object id 25279)
1 INDEX RANGE SCAN ITEM_VENDOR_ITEM_FK_IDX (cr=3 pr=0 pw=0 time=53 us)(object id 24079)
0 PX RECEIVE (cr=792 pr=1 pw=0 time=28530 us)
0 PX SEND HASH :TQ10003 (cr=792 pr=1 pw=0 time=28524 us)
0 VIEW (cr=792 pr=1 pw=0 time=28517 us)
0 HASH GROUP BY (cr=792 pr=1 pw=0 time=28509 us)
0 PX RECEIVE (cr=792 pr=1 pw=0 time=28295 us)
0 PX SEND HASH :TQ10002 (cr=792 pr=1 pw=0 time=28290 us)
0 NESTED LOOPS (cr=792 pr=1 pw=0 time=28284 us)
1 BUFFER SORT (cr=1 pr=0 pw=0 time=139 us)
1 PX RECEIVE (cr=1 pr=0 pw=0 time=45 us)
1 PX SEND BROADCAST :TQ10000 (cr=1 pr=0 pw=0 time=40 us)
1 INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=34 us)(object id 25279)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28136 us)
0 TABLE ACCESS FULL SS_SKU_STORE_WEEK PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28084 us)
0 TABLE ACCESS BY INDEX ROWID ITEM (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN ITEM_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24055)
0 TABLE ACCESS BY INDEX ROWID SS_SKU (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN SS_SKU_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25300)
0 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS BY LOCAL INDEX ROWID SS_SKU_STORE PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
0 INDEX RANGE SCAN SS_SKU_ST_PK PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)(object id 25547)
0 TABLE ACCESS BY INDEX ROWID STORE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN STORE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25586)
0 TABLE ACCESS BY INDEX ROWID FASHION_ATTRIBUTE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN FASHION_ATTRIBUTE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24035)
0 TABLE ACCESS BY INDEX ROWID CUST_PROFILE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN CUST_PROFILE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24036)
ALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 43 0.10 0.11 0 1 0 0
Execute 861 0.38 0.45 357 622 46 621
Fetch 845 0.21 0.21 128 2626 2 892
total 1749 0.69 0.78 485 3249 48 1513
Misses in library cache during parse: 21
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 60 0.00 0.00
SQL*Net message from client 39 0.00 0.16
db file scattered read 82 0.01 0.05
db file sequential read 185 0.01 0.05
log file sync 1 0.00 0.00
191 user SQL statements in session.
23 internal SQL statements in session.
214 SQL statements in session.
37 statements EXPLAINed in this session.Thank you for your help in advance
Message was edited by:
devmiral -
Hi,
I have explain plan a sql using Enterprise manager. What does the cost indicates, if a query is having a cost of 119 and after tuning its cost is 16 what does it indicate. What is the relationship between time taken by a query to run and its cost.
Regards
RajHi, Raj.
<What does the cost indicate.
In theory, the cost indicates how long a query should take if actually run. Small number means fast, bug number means slow. Its just an arbitrary number computed to indicate how long a query should take to run.
In practice, the cost has little meaning especially in 10g. Its becoming common enough for a high cost to actually run faster than a low cost that our DBA group pretty much ignores the cost.
Remember that the cost is computed before the query is actually run, against computed statistics and available system resources. The cost is an guess, and like all guesses is subject to reality checks.
Message was edited by:
riedelme -
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - ProductionExplain plan
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 7134K| 1238M| | 448K (2)| 01:29:39 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 7134K| 1238M| | 448K (2)| 01:29:39 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 7134K| 1238M| 2858M| 448K (2)| 01:29:39 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,02 | P->P | HASH |
|* 6 | HASH JOIN BUFFERED | | 7134K| 1238M| 1873M| 408K (2)| 01:21:42 | | | Q1,02 | PCWP | |
| 7 | PX RECEIVE | | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,02 | PCWP | |
| 8 | PX SEND HASH | :TQ10000 | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,00 | P->P | HASH |
| 9 | PX BLOCK ITERATOR | | 137M| 13G| | 97898 (3)| 00:19:35 | 1 | 4 | Q1,00 | PCWC | |
|* 10 | TABLE ACCESS FULL | ORII | 137M| 13G| | 97898 (3)| 00:19:35 | 189 | 192 | Q1,00 | PCWP | |
| 11 | PX RECEIVE | | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 12 | PX SEND HASH | :TQ10001 | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,01 | P->P | HASH |
|* 13 | TABLE ACCESS BY GLOBAL INDEX ROWID| MII | 466 | 28426 | | 5 (0)| 00:00:01 | ROWID | ROWID | Q1,01 | PCWC | |
| 14 | NESTED LOOPS | | 177M| 13G| | 119K (1)| 00:23:58 | | | Q1,01 | PCWP | |
| 15 | PX BLOCK ITERATOR | | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,01 | PCWC | |
|* 16 | TABLE ACCESS FULL | DI | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,01 | PCWP | |
|* 17 | INDEX RANGE SCAN | IDX_MII | 482 | | | 0 (0)| 00:00:01 | | | Q1,01 | PCWP | |
Predicate Information (identified by operation id):
6 - access("RNII"."LEGAL_ENTITY_ID"="MII"."LEGAL_ENTITY_ID" AND "RNII"."ORDER_ID"="MII"."DISTRIBUTOR_ORDER_ID" AND
"RNII"."SHIPMENT_ID"="MII"."DISTRIBUTOR_SHIPMENT_ID" AND "RNII"."ASIN"="MII"."ASIN")
10 - filter("RNII"."RNII_SOURCE_NAME"='distributor_shipment_item' AND "RNII"."SNAPSHOT_DAY"=TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"RNII"."LEGAL_ENTITY_ID"=101)
13 - filter("MII"."LEGAL_ENTITY_ID"=101)
16 - filter("DI"."GL_DATE">=TO_DATE('2009-12-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "DI"."INVOICE_STATUS"='4' AND "DI"."LEGAL_ENTITY_ID"=101 AND
"DI"."GL_DATE"<TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
17 - access("MII"."INVOICE_ID"="DI"."INVOICE_ID")Below are my questions:
Q1-Which operation should start first. Is that Nested Loop between di and mii tables or creating HASH table for rnii. When i monitored SQL execution in V$SQL_WORKAREA_ACTIVE, it was doing HASH JOIN operation (Operation ID=6) first. Query started executing with 16 parallel slaves (DOP for di=1,mii=1 and rnii=8 at table level). 8 slaves were doing HASH JOIN while remaining 8 were sitting idle. I want to understand why slaves were sitting idle and not doing NL? Each slave has used 1.59 GB (total ~12.5GB) on TEMP, which goes with CBO's assumption to use 13 GB TEMP.
Once HASH JOIN (operation 6) is done, i have seen that 4 slaves were scanning mii table using 'db file sequential wait''. Which made me realize that RNII table was the driving and NL's join row source were acting as probing table. I am not sure whether my thinking is right or not? This query took 9 min to retrun 4.2 Million rows.
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 217 1 NOT WAIT 1 8 8
- p004 (Slave) 1 442 1 NOT WAIT 1 8 8
- p003 (Slave) 1 482 1 NOT WAIT 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 493 1 NOT WAIT 1 8 8
- p007 (Slave) 1 353 1 NOT WAIT 1 8 8
- p006 (Slave) 1 477 1 NOT WAIT 1 8 8
- p002 (Slave) 1 313 1 NOT WAIT 1 8 8
- p015 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 432 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 333 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 275 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 328 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8
SID SQL_HASH_VALUE QCSID OPERATION_ID TYPE POLICY WSIZE_MB EXP_SIZE_MB ACT_SIZE_MB MAX_SIZE_MB PASSES TEMP
328 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596
333 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
275 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596
432 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
510 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
306 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
418 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
476 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596Index on mii table is a GLOBAL non-partitioned index. Which made me think, why scanning of mii table were going in parallel with 'db file sequential wait'?
When i use NO_SWAP_JOIN_INPUTS(rnii) hint in query, i got below Explain plan:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 7134K| 1238M| | 448K (2)| 01:29:38 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 7134K| 1238M| | 448K (2)| 01:29:38 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 7134K| 1238M| 2858M| 448K (2)| 01:29:38 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,02 | P->P | HASH |
|* 6 | HASH JOIN BUFFERED | | 7134K| 1238M| 1948M| 408K (2)| 01:21:42 | | | Q1,02 | PCWP | |
| 7 | PX RECEIVE | | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 8 | PX SEND HASH | :TQ10000 | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,00 | P->P | HASH |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| MATCHED_INVOICE_ITEMS | 466 | 28426 | | 5 (0)| 00:00:01 | ROWID | ROWID | Q1,00 | PCWC | |
| 10 | NESTED LOOPS | | 177M| 13G| | 119K (1)| 00:23:58 | | | Q1,00 | PCWP | |
| 11 | PX BLOCK ITERATOR | | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,00 | PCWC | |
|* 12 | TABLE ACCESS FULL | DISTRIBUTOR_INVOICES | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,00 | PCWP | |
|* 13 | INDEX RANGE SCAN | I_MII_INVOICE_ID_ITEM_ID | 482 | | | 0 (0)| 00:00:01 | | | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,01 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 137M| 13G| | 97898 (3)| 00:19:35 | 1 | 4 | Q1,01 | PCWC | |
|* 17 | TABLE ACCESS FULL | O_RECEIVED_NOT_INVOICED_ITEMS | 137M| 13G| | 97898 (3)| 00:19:35 | 189 | 192 | Q1,01 | PCWP | |
Predicate Information (identified by operation id):
6 - access("RNII"."LEGAL_ENTITY_ID"="MII"."LEGAL_ENTITY_ID" AND "RNII"."ORDER_ID"="MII"."DISTRIBUTOR_ORDER_ID" AND
"RNII"."SHIPMENT_ID"="MII"."DISTRIBUTOR_SHIPMENT_ID" AND "RNII"."ASIN"="MII"."ASIN")
9 - filter("MII"."LEGAL_ENTITY_ID"=101)
12 - filter("DI"."GL_DATE">=TO_DATE('2009-12-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "DI"."INVOICE_STATUS"='4' AND "DI"."LEGAL_ENTITY_ID"=101 AND
"DI"."GL_DATE"<TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
13 - access("MII"."INVOICE_ID"="DI"."INVOICE_ID")
17 - filter("RNII"."RNII_SOURCE_NAME"='distributor_shipment_item' AND "RNII"."SNAPSHOT_DAY"=TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"RNII"."LEGAL_ENTITY_ID"=101)When i use above hint, query took 5 min only. During its execution, i have monitored that NL HASH JOIN (rnii) were happening in parallel using 8 slaves. Below is snippet of that:
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 275 1 WAIT db file sequential read 1 8 8
- p004 (Slave) 1 328 1 NOT WAIT 1 8 8
- p003 (Slave) 1 432 1 WAIT db file sequential read 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 477 1 WAIT db file parallel read 1 8 8
- p007 (Slave) 1 493 1 NOT WAIT 1 8 8
- p006 (Slave) 1 482 1 WAIT db file sequential read 1 8 8
- p002 (Slave) 1 333 1 WAIT db file parallel read 1 8 8
- p015 (Slave) 2 442 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 353 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 217 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 313 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
SID SQL_HASH_VALUE QCSID OPERATION_ID TYPE POLICY WSIZE_MB EXP_SIZE_MB ACT_SIZE_MB MAX_SIZE_MB PASSES TEMP
510 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
442 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
306 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
217 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
418 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
313 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
353 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
476 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
I believe 'db file parallel read' is due to TABLE PRE-FETCH (mii). My P_A_T is 4 GB.
I wanted to understand what factor should i consider to decide which table should be the driving and which should be the probe?
Thanks beforehand.OraDBA02 wrote:
1) Why 8 slaves were sitting idle while other 8 slaves were busy building HASH table from rnii in first execution plan?I don't see why do you think that 8 slaves were idle and 8 were busy. This output:
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 217 1 NOT WAIT 1 8 8
- p004 (Slave) 1 442 1 NOT WAIT 1 8 8
- p003 (Slave) 1 482 1 NOT WAIT 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 493 1 NOT WAIT 1 8 8
- p007 (Slave) 1 353 1 NOT WAIT 1 8 8
- p006 (Slave) 1 477 1 NOT WAIT 1 8 8
- p002 (Slave) 1 313 1 NOT WAIT 1 8 8
- p015 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 432 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 333 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 275 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 328 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8tells nothing about idleness, since this is just a snapshot.
2) If you look at both execution plans everything (row source,bytes,IN-OUT,TEMP columns) is same,except the Join order.
In first execution plan, join order is something like HASH (rnii, NL (di,mii)) while in second, it is HASH ((NL(di,mii),rnii).Read this blog post.
I think, long elapsed time of first plan is due to IDLE status of 8 slaves while HASH table is getting build up.Don't think, just get the execution profile using extended SQL trace.
3) Third question is regarding Index access in PARALLEL. (?). If you look at second plan, there are 2 px doing 'db file sequential read' on mii table and 2 px were doing 'db file parallel read'. The later is TABLE PRE-FETCH. I wanted to understand, how come index access (index on mii) got parallelised ? Is that Index leaf block scan in parallel or Table block access (from index rowid) in parallel ?Each slave performs IRS - it scans a part of driving table and performs NL join as usual for that part. That's it. -
Hello,
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
I have this issue:
On the sited above database first I execute a SELECT query, no matter what is it, with EXPLAIN PLAN FOR:
EXPLAIN PLAN FOR SELECT <some query comes here>This executes successfully.
Next, I do this to see the explain plan:
SELECT *
FROM TABLE (dbms_xplan.display());This generates the following error, which I read from the column "PLAN_TABLE_OUTPUT" of the result set:
ERROR: an uncaught error in function display has happened; please contact Oracle support
Please provide also a DMP file of the used plan table PLAN_TABLE
ORA-00904: "OTHER_TAG": invalid identifierI see that it is said to contact Oracle support, but unfortunately in this firm I am not in position to contact Oracle, when there is an issue.
Probably it is obvious to most of you, but since I receive this error for first time, I am wondering where the reason for the error could be.
The table PLAN_TABLE exists, which I know is needed to hold the output of an EXPLAIN PLAN statement.
Generally, in this database, when I try to see the explain plan for any query, the plan shows no values for niether parameter: Cost, CPU Cost, I/O Cost, Cardinality, whatever.
Could anyone presume, what could be changed in order the problem to be fixed.
What else .. the reason is not into the tool I am using, which is PL/SQL Developer, version 7.1.5, because for other databases there is no problem with EXPLAIN PLAN.
Thanks.You have an invalid PLAN_TABLE that has been created by some utility or has come from a script from a lower version.
See the script $ORACLE_HOME/rdbms/admin/catplan.sql for the correct 10.2.0.4 PLAN_TABLE (script executed by SYS AS SYSDBA)
Alternatively, use $ORACLE_HOME/rdbms/admin/utlxplan.sql to create a private PLAN_TABLE
Hemant K Chitale -
Hi All,
I am using oracle 10g and running in sql*plus.
I am getting one error when running explain plan for one query, if I am running the query in sql*plus then it is working fine.
Query:- SELECT sp.store_cd wr_store_cd, l.store_cd, l.loc_cd, l.loc_tp_cd,
sp.pd_cd, MIN(sp.priority), MIN(sp.ck_showroom)
FROM store$pri sp, loc l
WHERE l.store_cd BETWEEN NVL(sp.beg_store_cd,' ') AND sp.end_store_cd
AND l.loc_cd BETWEEN NVL(sp.beg_loc_cd,' ') AND sp.end_loc_cd
AND l.pick = 'Y'
GROUP BY sp.store_cd, sp.pd_cd, l.store_cd, l.loc_cd, l.loc_tp_cd
ORDER BY wr_store_cd, pd_cd, MIN(priority), l.store_cd;
Syntax:- Explain plan for (SELECT sp.store_cd wr_store_cd, l.store_cd, l.loc_cd, l.loc_tp_cd,
sp.pd_cd, MIN(sp.priority), MIN(sp.ck_showroom)
FROM store$pri sp, loc l
WHERE l.store_cd BETWEEN NVL(sp.beg_store_cd,' ') AND sp.end_store_cd
AND l.loc_cd BETWEEN NVL(sp.beg_loc_cd,' ') AND sp.end_loc_cd
AND l.pick = 'Y'
GROUP BY sp.store_cd, sp.pd_cd, l.store_cd, l.loc_cd, l.loc_tp_cd
ORDER BY wr_store_cd, pd_cd, MIN(priority), l.store_cd);
I am getting the error :-
ORDER BY wr_store_cd, pd_cd, MIN(priority), l.store_cd)
ERROR at line 8:
ORA-00907: missing right parenthesis;
Any Idea.
Regards
SUNI'm able to reproduce your situation like this:
SQL> explain plan
2 for
3 ( select d.deptno
4 , d.dname
5 , count(e.empno)
6 from emp e
7 , dept d
8 where e.deptno (+) = d.deptno
9 group by d.deptno
10 , d.dname
11 order by count(e.empno) desc
12 )
13 /
order by count(e.empno) desc
FOUT in regel 11:
.ORA-00907: missing right parenthesisAnd it seems to be because of the brackets inside the order by clause:
SQL> explain plan
2 for
3 ( select d.deptno
4 , d.dname
5 , count(e.empno)
6 from emp e
7 , dept d
8 where e.deptno (+) = d.deptno
9 group by d.deptno
10 , d.dname
11 -- order by count(e.empno) desc
12 )
13 /
Uitleg is gegeven.But you really do not need the brackets around your SQL statement in an explain plan. So I would just remove these:
SQL> explain plan
2 for
3 select d.deptno
4 , d.dname
5 , count(e.empno)
6 from emp e
7 , dept d
8 where e.deptno (+) = d.deptno
9 group by d.deptno
10 , d.dname
11 order by count(e.empno) desc
12 /
Uitleg is gegeven.Although normally speaking, brackets don't impose problems:
SQL> explain plan for select * from emp
2 /
Uitleg is gegeven.
SQL> explain plan for (select * from emp)
2 /
Uitleg is gegeven.Hope this helps.
Regards,
Rob.
Maybe you are looking for
-
Hi I have created MRP group with following control parameters Planning horizon 20 days Creation indicator -- PR in opening period Opening period in material master 10 days I have requirement on 3.04. 2012 andi put planning date in Md01 6.03.2012 ( 3
-
June 3 2013 update install problem
I am having installation problems with the latest CS6 update released June 3 2013. I have tried multiple times to instal the update and the installer goes through most of the install process and then gives me a message saying I should check the erro
-
Mini ipad not sync with itunes
I have windows 7 64 bit, itunes 11.2 and ios 7.1.1. On May 21, 2014, I updated both my ipad 2 and mini ipad and it went into recovery mode. I uninstalled all the programs required by apple (itunes, apple software update, apple mobile device support
-
Hello , We have got a requirement to report on an keyfigure which extraccts data from an R/3 table field which holds descriptions captured in a transaction which changes everyweek ,Pls suggest me on how to report on this keyfigure ???
-
Ipad2 touch screen has frozen and none of the apps will open. I can't do a shut down to reboot?
My Ipad2 touch screen has frozen and none of the apps will open. I can't do a shut down to reboot?