Error with Explain Plan
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
Similar Messages
-
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/ -
Errors with Integrated Planning authorizations
Dear experts,
We are working with Integration Planning, and when we try to create or
modify whatever object (by the modeler or the wizard) we receive an error message like this:
"You have no authorization for Multiprovider XXXX"
Not only Multiprovider, but InfoCube....whatever object.
The curious thing is that we have with the user we are working a SAP ALL.
With the T-CODE bps0 we can do everything, but with T-CODE rsplan is
impossible.
Weve checked in the T-CODE su53 and everything is OK.
Weve checked in the T-CODE rsecadmin and nothing there.
Weve checked as well in the T-CODE st01, followed the actions with the
trace and all the return codes are 0.
Does anyone know what happens?
Thanks in advance
CeciliaHello Cecilia,
if you keep a carott in front of a donkey he will run faster... this is the same what I mean if I talked from experts: Men like to be the hero and instead of carott you need to need to laud him as an expert, he will reply faster
Lets come back to authorization: I am not sure whether RSECADMIN is a newer version of RSSM. Reason: In RSSM you can activate authorization check for a cube or MP but in RSECADMIN you administrate authorization for an user.
I am not sure, but I think that your problem is related to this issue. If not, there are very strange problems with the web authroization, its true: What we have done is to copy an exisiting BW user and assign him the same authorization like in web. Reason: To create a new user in the web does not work in all cases. We had very much problems with SP7, since we have SP10 we dont have those problems.
regards
Eckhard -
The goal is to obtain the overall system statistics and explain plans for the entire system.
1. The only tool that I can think of is "StatsPack".
2. With AWR there are 2 issues:-
a. It is not free
b. It does not give Explain plan output.
3. We can use 10046 / 10053 Trace's however it wont give you as comphrehensive an output as statspack, you would also have to enable trace for each individual application while its running, grab the trace file, look at the report.
4. We can also use outlines to store the explain plan this was primarily for Oracle version 10g.
5. The last option we have is sql managed baselines. This is good , however it does not tell me conclusively how my system was executing a sql lets say 10 days back. It wont accept the new sql unless we promote it. Still there is no guarantee that the underlying sql plan will not change.
So far statspack with level 6 appears to be the only solution.Personally I'd spend the money and get AWR.
The problem with StatsPack is that when you run it, after an issue, it is too late to capture anything of value. With AWR snapshots are taken as often as you wish, 24 hours a day, and then when someone tells you there was a problem at 4:15 in the morning ... you have something to work with. -
Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
i.e.
Explain Plan for : Select * from emp a;
and Explain for : Select * from emp b;
Will remain same always, or it will differ?
Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
Thanks in Advance.
Regards,
Sudipta.user13513014 wrote:
Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
i.e.
Explain Plan for : Select * from emp a;
and Explain for : Select * from emp b;
Will remain same always, or it will differ? By simply switching alias, the optimizer is unlikely to develop a new plan.
Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
Thanks in Advance.
Regards,
Sudipta.There is no way you can actally see the parsing of SQL. It is done internally by oracle in a process caled Hard Parse or Soft Parse. A Hard Parse is where the optimizer must go through all the steps of parsing from the beggining, where as a soft parse, oracle uses the cached results from a hard parsed query that is in the shared pool.
How the optimizer works is a subject of ample documentation and several books. As a general over view, here are the general steps at parsing an SQL:
1. Optimizer evaluates your statement, checks it for grammar errors, grants to objects, etc.
2. Statement Transformation: Optimizer evaluates your statement for possible optimization regarding rewrite, in cases you have view or correlated subqueries.
3. Choice of optimizer goals.
4. Choice of acccess paths.
5. Choice of Join Orders.
Suggest you try a google search, it will give you a lot of material, or check the Oracle Database Performance Tuning Guide 11.2, which is free by oracle. -
I am trying to use TOAD to find the query performance. When I clicked on explain plan tab i get an error message: ORA-02404: specified plan table not found.
Can some one please tell me how to proceed from here so that I can check the explain plan for this tableI don't know how TOAD works with EXPLAIN PLAN, but mybe it is if you have PLAN_TABLE created in your database and granted all on it to public.
SQL> @<ORACLE_HOME>/rdbms/admin/utlxplan.sql
SQL> create public synonym plan_table for plan_table
SQL> grant all on plan_table to public
I don't know if you're looking for somethinkg like that ... -
Oracle not using its own explain plan
When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
2 /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
2 INTO
3 dt_test_bvpeek
4 SELECT
5 rownum,
6 CASE
7 WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
8 1
9 ELSE
10 MOD(rownum, 5)
11 END
12 END
13 FROM
14 dual
15 CONNECT BY
16 LEVEL <= 100000
17 /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
2 /
COUNT(*) COL1
80000 1
20000 4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
2 /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 78728 | 538K| 82 (52)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 | 538K| 82 (52)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 4
8 /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 21027 | 143K| 74 (21)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK | 21027 | 143K| 74 (21)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | DT_TEST_BVPEEK_I1 | 21077 | | 29 (28)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
2 /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David -
Hi,
While executing the query i am getting the following error,
SQL> explain plan for
2 select * from user_objects;
select * from user_objects
ERROR at line 2:
ORA-01039: insufficient privileges on underlying objects of the view
But same query works in other schema. Is there any privilege has to be granted.Hi,
The user_objects view references some objects owned by SYS. It looks like you do not have enough object or system privileges on these objects. -
Hi
I need some help with explain plan...tried some documents but didnt get the clarity...here is the query...
explain plan for
select ename,dname,grade
from emp,dept,salgrade
where emp.deptno=dept.deptno
and emp.sal between salgrade.losal and salgrade.hisal;
and here is the explain plan for this query..
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | NESTED LOOPS | | | | |
| 2 | NESTED LOOPS | | | | |
| 3 | TABLE ACCESS FULL | SALGRADE | | | |
|* 4 | TABLE ACCESS FULL | EMP | | | |
| 5 | TABLE ACCESS BY INDEX ROWID| DEPT | | | |
|* 6 | INDEX UNIQUE SCAN | PK_DEPT | | | |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
4 - filter("EMP"."SAL"<="SALGRADE"."HISAL" AND "EMP"."SAL">="SALGRADE"
."LOSAL")
6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
Note: rule based optimization
21 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
[i suppose it will remove all the spaces....so sorry .... :-( ]
now i have some questions regarding this like...
1. wat does these * mean with 4 and 6
2. how we come to know that which part got executed first and others after that.....as we draw a tree to represent all the steps....
3. wat is this Predicate Information
4. wat info is given at the last titled "Execution Plan"
please help
thanks
SidhuSidhu,
1. wat does these * mean with 4 and 6It means that predicates are applied during this step. You'll see that there is a 4 and a 6 in the predicate informatiion, to specify the actual predicates being applied. The star is to indicate the presence of a predicate.
2. how we come to know that which part got executed
first and others after that.....as we draw a tree to
represent all the steps....This example is taken from an AskTom thread. In this thread he described in great detail how such a tree should be read. I cannot do it better.
3. wat is this Predicate InformationThe filters that are applied to restrict the result set.
4. wat info is given at the last titled "Execution
Plan"You were probably autotracing the 'select * from table(dbms_xplan.display)' itself. So this section is not relevant.
Regards,
Rob. -
Interpreting explain plans oracle 11gr2
Hi,
We are using oracle 11.2.0.3 and plan on evaluating a series of explain plans to determine index/partitioning strategy for a large fact table +a ssociarted dimensions in data warehouse.
Whilst we plan on running a selection of these to get actaul times, wish to evalaute many more eplain plans to guage efficiency of data model.
In terms of interpreting we are going on basis of the lower the row count/cpu cost the better the performance should be.
Plan on using autotrace for these as well.
Any downsides to this /shoudl we look out for anything esle with explain plan.
Is autotrace suffciient in this repsect.
Have also found the time in execution plan can often bear no resembalnce to actaul execution plan.
Any other tips on interpreting explain plans woudl eb appreacited.
Whilst I understand the real times will only come thorugh running the queries want to do prep work with explain plans before run them all.
Thanks
Edited by: user5716448 on 02-Mar-2013 08:26Don't rely on the cost to tell you how efficient a SQL is. It is based on estimates that are not always correct. Its best use is to tell if something has changed when doing SQL variations - it can and does happen that a lower cost version will use more resources as per AUTOTRACE than a higher-cost version of the SQL.
Also make absoutely sure that the tuned SQL returns the same results as the original :)
Using AUTOTRACE was a good decision. It will provide run-time metrics for your SQL as well as automatically generate execution plans. It does not list CPU usage, which is avialable from V$SQL. Lower resources listed by AUTOTRACE should accompany faster run times in general. -
Guys,
I've a query with explain plan as below:
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 12 | 792 | 1172 | | |
| 1 | SORT GROUP BY | | 12 | 792 | 1172 | | |
| 2 | HASH JOIN | | 12 | 792 | 1159 | | |
| 3 | MERGE JOIN CARTESIAN | | 206 | 2884 | 34 | | |
| 4 | VIEW | VW_NSO_1 | 1 | 10 | 20 | | |
| 5 | SORT UNIQUE | | 1 | 35 | 20 | | |
| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| PROD | 1 | 35 | 7 | 65 | 65 |
PLAN_TABLE_OUTPUT
| 7 | INDEX RANGE SCAN | PROD_PK | 7 | | 3 | 65 | 65 |
| 8 | BUFFER SORT | | 206 | 824 | 34 | | |
| 9 | VIEW | VW_NSO_2 | 206 | 824 | 15 | | |
| 10 | SORT UNIQUE | | 206 | 3914 | 15 | | |
| 11 | INDEX FAST FULL SCAN | GEO | 295 | 5605 | 1 | 22 | 22 |
| 12 | PARTITION RANGE INLIST | | | | |KEY(I) |KEY(I) |
| 13 | TABLE ACCESS BY LOCAL INDEX ROWID | FP_FSRVOL_FB | 36641 | 1860K| 1124 |KEY(I) |KEY(I) |
| 14 | INDEX RANGE SCAN | FP_FSRVOL_FB_IDX1 | 6595 | | 1009 |KEY(I) |KEY(I) |
And with little modifications to the query, the explain plan looks below:
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 63 | 3528 | 1140 | | |
| 1 | SORT GROUP BY | | 63 | 3528 | 1140 | | |
| 2 | HASH JOIN | | 63 | 3528 | 1127 | | |
| 3 | MERGE JOIN CARTESIAN | | 206 | 2884 | 34 | | |
| 4 | VIEW | VW_NSO_1 | 1 | 10 | 20 | | |
| 5 | SORT UNIQUE | | 1 | 35 | 20 | | |
| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| PROD | 1 | 35 | 7 | 65 | 65 |
PLAN_TABLE_OUTPUT
| 7 | INDEX RANGE SCAN | PROD_PK | 7 | | 3 | 65 | 65 |
| 8 | BUFFER SORT | | 206 | 824 | 34 | | |
| 9 | VIEW | VW_NSO_2 | 206 | 824 | 15 | | |
| 10 | SORT UNIQUE | | 206 | 3914 | 15 | | |
| 11 | INDEX FAST FULL SCAN | GEO | 295 | 5605 | 1 | 22 | 22 |
| 12 | PARTITION RANGE ALL | | | | | 1 | 506 |
| 13 | TABLE ACCESS BY LOCAL INDEX ROWID | FP_FSRVOL_FB | 183K| 7539K| 1092 | 1 | 506 |
| 14 | INDEX RANGE SCAN | FP_FSRVOL_FB_DUE_PERD | 33086 | | 594 | 1 | 506 |I've seen PSTOP=PSTART = KEY,but KEY(I) looks strange to me.
Could someone explain the same?
And I need your advice regarding which of the above plans is acceptable..
Regards,
BhagatThis is from the Oracle documentation:
Index Column
If the IN list column EMPNO is an index column but not a partition column, then the plan is as follows (the IN list operator appears above the table operation but below the partition operation):
OPERATION OPTIONS OBJECT_NAME PARTITION_START PARTITION_STOP
SELECT STATEMENT
PARTITION CONCATENATED KEY(INLIST) KEY(INLIST)
INLIST ITERATOR CONCATENATED
TABLE ACCESS BY ROWID EMP KEY(INLIST) KEY(INLIST)
INDEX RANGE SCAN EMP_EMPNO KEY(INLIST) KEY(INLIST)
The KEY(INLIST) designation for the partition start and stop keys specifies that an IN list predicate appears on the index start/stop keys.
/[pre]
I'll assume the changes involve either removing an IN list or changing the query so that it decides that a full scan is better than using a INLIST ITERATOR to scan through the list. It's difficult to say which is better without knowing how many values are in the IN list and how big the table is that the values are taken from. The IN LIST iterator seems to result in less rows being processed so in theory could be quicker... The best way is to try it. -
Hi Team,
How to generate the explain plain for the below query.
SQL> explain plan for
2 SELECT NVL(:B1 , REQUISITION_LINE_ID), NVL(:B4 , CANCEL_FLAG), NVL(:B12 , CANCEL_DATE), NVL(:B11 , CANCEL_REASON), NVL(:B10 , CLOSED_CODE), NVL(:B9 , CLOSED_REASON), NVL(:B8 , CLOSED_DATE), DECODE(:B4 ,'Y',NULL,CONTRACTOR_STATUS), :B7 , :B6 , :B5 , DECODE(:B4 , 'Y', DECODE(SOURCE_TYPE_CODE,'INVENTORY', OE_ORDER_IMPORT_INTEROP_PUB.GET_CANCELLED_QTY( :B3 , TO_CHAR(:B2 ), NVL(TO_CHAR(:B1 ), REQUISITION_LINE_ID)), QUANTITY - QUANTITY_DELIVERED), QUANTITY_CANCELLED) FROM PO_REQUISITION_LINES WHERE REQUISITION_HEADER_ID = :B2 AND REQUISITION_LINE_ID = NVL(:B1 , REQUISITION_LINE_ID) AND NVL(CANCEL_FLAG, 'N') IN ('N', 'I') AND NVL(CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED';
SELECT NVL(:B1 , REQUISITION_LINE_ID), NVL(:B4 , CANCEL_FLAG), NVL(:B12 , CANCEL_DATE), NVL(:B11 , CANCEL_REASON), NVL(:B10 , CLOSED_CODE), NVL(:B9 , CLOSED_REASON), NVL(:B8 , CLOSED_DATE), DECODE(:B4 ,'Y',NULL,CONTRACTOR_STATUS), :B7 , :B6 , :B5 , DECODE(:B4 , 'Y', DECODE(SOURCE_TYPE_CODE,'INVENTORY', OE_ORDER_IMPORT_INTEROP_PUB.GET_CANCELLED_QTY( :B3 , TO_CHAR(:B2 ), NVL(TO_CHAR(:B1 ), REQUISITION_LINE_ID)), QUANTITY - QUANTITY_DELIVERED), QUANTITY_CANCELLED) FROM PO_REQUISITION_LINES WHERE REQUISITION_HEADER_ID = :B2 AND REQUISITION_LINE_ID = NVL(:B1 , REQUISITION_LINE_ID) AND NVL(CANCEL_FLAG, 'N') IN ('N', 'I') AND NVL(CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED'
ERROR at line 2:
ORA-00942: table or view does not existNow when I ran the command as APPS user got the below error
SQL> EXPLAIN PLAN FOR
2 SELECT NVL(:B1 , REQUISITION_LINE_ID), NVL(:B4 , CANCEL_FLAG), NVL(:B12 , CANCEL_DATE), NVL(:B11 , CANCEL_REASON), NVL(:B10 , CLOSED_CODE), NVL(:B9 , CLOSED_REASON), NVL(:B8 , CLOSED_DATE), DECODE(:B4 ,'Y',NULL,CONTRACTOR_STATUS), :B7 , :B6 , :B5 , DECODE(:B4 , 'Y', DECODE(SOURCE_TYPE_CODE,'INVENTORY', OE_ORDER_IMPORT_INTEROP_PUB.GET_CANCELLED_QTY( :B3 , TO_CHAR(:B2 ), NVL(TO_CHAR(:B1 ), REQUISITION_LINE_ID)), QUANTITY - QUANTITY_DELIVERED), QUANTITY_CANCELLED) FROM PO_REQUISITION_LINES WHERE REQUISITION_HEADER_ID = :B2 AND REQUISITION_LINE_ID = NVL(:B1 , REQUISITION_LINE_ID) AND NVL(CANCEL_FLAG, 'N') IN ('N', 'I') AND NVL(CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED';
SELECT NVL(:B1 , REQUISITION_LINE_ID), NVL(:B4 , CANCEL_FLAG), NVL(:B12 , CANCEL_DATE), NVL(:B11 , CANCEL_REASON), NVL(:B10 , CLOSED_CODE), NVL(:B9 , CLOSED_REASON), NVL(:B8 , CLOSED_DATE), DECODE(:B4 ,'Y',NULL,CONTRACTOR_STATUS), :B7 , :B6 , :B5 , DECODE(:B4 , 'Y', DECODE(SOURCE_TYPE_CODE,'INVENTORY', OE_ORDER_IMPORT_INTEROP_PUB.GET_CANCELLED_QTY( :B3 , TO_CHAR(:B2 ), NVL(TO_CHAR(:B1 ), REQUISITION_LINE_ID)), QUANTITY - QUANTITY_DELIVERED), QUANTITY_CANCELLED) FROM PO_REQUISITION_LINES WHERE REQUISITION_HEADER_ID = :B2 AND REQUISITION_LINE_ID = NVL(:B1 , REQUISITION_LINE_ID) AND NVL(CANCEL_FLAG, 'N') IN ('N', 'I') AND NVL(CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED'
ERROR at line 2:
ORA-00600: internal error code, arguments: [12337], [], [], [], [], [], [], [], -
Hi when i run this in toad for explain plan its showing an error ORA_22905
hi when i run this query in toad for explain plan its showing an error ORA_22905 cannot accesss rows from an non nested table item can anyone help me out
SELECT
DISTINCT SERVICE_TBL.SERVICE_ID , SERVICE_TBL.CON_TYPE, SERVICE_TBL.S_DESC || '(' || SERVICE_TBL.CON_TYPE || ')' AS SERVICE_DESC ,SERVICE_TBL.CON_STAT
FROM
TABLE(:B1 )SERVICE_TBL
WHERE
CON_NUM = :B2
thanksNote the name of this forum is SQL Developer *(Not for general SQL/PLSQL questions)* (so for issues with the SQL Developer tool). Please post these questions under the dedicated SQL And PL/SQL forum.
Regards,
K. -
Explain Plan not working with 919, was working with 804
Hi,
Explain Plan (F6) was working cprrectly with Raptor 804 and is not working any more on 919. This is the same query exactly (select * from mytable). The server is 9.2.0.5.0. The result with 919 is "Invalid Column Name".
Regards
EricI get this too.
The plan table structure is
CREATE TABLE "ELX"."PLAN_TABLE"
( "STATEMENT_ID" VARCHAR2(30),
"TIMESTAMP" DATE,
"REMARKS" VARCHAR2(80),
"OPERATION" VARCHAR2(30),
"OPTIONS" VARCHAR2(30),
"OBJECT_NODE" VARCHAR2(128),
"OBJECT_OWNER" VARCHAR2(30),
"OBJECT_NAME" VARCHAR2(30),
"OBJECT_INSTANCE" NUMBER,
"OBJECT_TYPE" VARCHAR2(30),
"OPTIMIZER" VARCHAR2(255),
"SEARCH_COLUMNS" NUMBER,
"ID" NUMBER,
"PARENT_ID" NUMBER,
"POSITION" NUMBER,
"COST" NUMBER,
"CARDINALITY" NUMBER,
"BYTES" NUMBER,
"OTHER_TAG" VARCHAR2(255),
"PARTITION_START" VARCHAR2(255),
"PARTITION_STOP" VARCHAR2(255),
"PARTITION_ID" NUMBER,
"OTHER" LONG,
"DISTRIBUTION" VARCHAR2(30)And raptor seems to be issuing this
PARSING IN CURSOR #2 len=82 dep=0 uid=80 oct=50 lid=80 tim=3808125826 hv=1796199517 ad='17ebc98c'
EXPLAIN PLAN SET STATEMENT_ID ='4363' INTO PLAN_TABLE FOR select * from collection
END OF STMT
PARSE #2:c=0,e=742,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3808125815
BINDS #2:
=====================
PARSE ERROR #3:len=480 dep=1 uid=80 oct=2 lid=80 tim=3808128369 err=904
insert into "PLAN_TABLE" (statement_id, timestamp, operation, options,object_node, object_owner, object_name, object_instance, object_type,search_columns, id, parent_id, position, other,optimizer, cost, cardinality, bytes, other_tag, partition_start, partition_stop, partition_id, distribution, cpu_cost, io_cost, temp_space, access_predicates, filter_predicates ) values(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,:20,:21,:22,:23,:24,:25,:26,:27)
=====================cpu_cost, io_cost, temp_space, access_predicates, filter_predicates seem to be invalid
Message was edited by:
smitjb -
EXPLAIN PLAN with pluggable mapping
Dear Folks,
I have a mapping with a pluggable mapping included. When I try to get the EXPLAIN PLAN TREE I receive an error: 'ORA-00904: "FULLPACKAGENAME"."CONSTANT_0_SITUATION_1":invalid identifier'.
The EXPLAIN PLAN REPORT says in the first line: Error: cannot fetch last explain plan from PLAN_TABLE
When I search for 'CONSTANT_0_SITUATION_1' I can find things like:
(SELECT
"WH_JOIN_GSMNMBR_PORTINGDATA"."GSS_VOI_ID" "FACT1_ID",
"WH_JOIN_GSMNMBR_PORTINGDATA"."BEGINDATE" "FACT1_BEGINDATE",
"WH_JOIN_GSMNMBR_PORTINGDATA"."ENDDATE" "FACT1_ENDDATE",
"INGRP2"."FACT1_MIN_BEGINDATE" "FACT1_MIN_BEGINDATE",
"INGRP2"."FACT1_MAX_ENDDATE" "FACT1_MAX_ENDDATE",
FULLPACKAGENAME."CONSTANT_0_SITUATION_1" "SITUATION_1"
What is 'FULLPACKAGENAME'???
I can validate my mapping and this is OK. I checked the pluggable mapping again and again, all seems to be right. I can run the mapping and it works. Just need to tune it.
I'm working with OWB 11.1 on a 10.2.g DB
Can please someone help me?
Greetings
S.Hi,
if you generate the sql in the mapping editor, the sql may not run directly. FULLPACKAGENAME will be replaced my the mapping name during deployment. The constants you define in the mapping will be pl/sql-variables of that package.
To make the sql work, you have to replace the FULLPACKAGENAME.xxx expressions with correct values manually.
Do you have the most recent patch installed? In owb 10gr2 the values from the constants as well as the default values of the mappings are set correctly from version 10.2.0.3 on.
Regards,
Carsten.
Maybe you are looking for
-
Namespace Creation for file to idoc scenario
Hi , while creating new namespace in integration repository for file-> XI-> idoc scenario ( that is data is to be pushed from a file to R/3 using idoc ) we have to enter the connection data viz: system :.......
-
Hi there, I've installed the URM Adapter for the first time, I want to Registering an External URM Source so I followed the instructions in the installation guide. The problem is that I'm a bit confused, I was wondering if someone can shed a light on
-
I've deleted the navigarion toolbar and I want it re-installed
I had the 'ask' toolbar and I disabled it, now I've lost the navigation toolbar, and I want it back, I've no idea how to do it, can someone help me please, as I would like the 'File, Tools, etc back, that way I an delete by browsing history to be del
-
Seeks algorithms for downloading file from WWW
I have a big question for how many different ways for me to download file from WWW. Can someone list those methods and the "Java offical" classes/libraries that needed? Also which is the BEST and most EFFICIENCY? Here are some methods: 1a. Download f
-
Joining 2 universes with varying levels of hierarchies
Hello, I have universe A which has dimensions whaich are at certail level say level 3, while I also have universe B which has dimensions at another level say level 5. Now I want to join Universe A and B to form universe C. Is it possible to join th