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.

Similar Messages

How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?

1. How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?
When multiple tables are involved , and the actual number of rows returned is more than what the explain plan tells. How can I find out what change is needed in the stat plan ?
2. Does rowsource statistics gives some kind of understanding of Extended stats ?

You can get Row Source Statistics only *after* the SQL has been executed. An Explain Plan midway cannot give you row source statistics.
To get row source statistics either set STATISTICS_LEVEL='ALL' in the session that executes theSQL OR use the Hint "gather_plan_statistics" in the SQL being executed.
Then use dbms_xplan.display_cursor
Hemant K Chitale

Oem explain plan produced doesn't correspond to explain plan with tkprof

Hello all,
I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
Then I did a trace file and ran it throught tkprof.
When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
As anybody had these kind of results?
Shall I have more confidence in TKprof then OEM?
It is very important to me since I am being chalanged by an external DBA.

I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
Regards,
Martin
www.ora-solutions.net

How to explain plan with bind variable

I want to explain plan for query which contains bind variables. I try to execute the query "explain plan for <query>" using PreparedStatement. If I set the bind variable using setXxx method, I get "ORA-01006: bind variable does not exist" error, if I don't bind, I get "java.sql.SQLException: Missing IN or OUT parameter at index:: 1". First error seems to be generated by JDBC driver, the second by the database. Problem is, that database does not require the bind variables to be bound, but the drivers does. Is there any way to do it?
I use JDBC 10.1.0.5.0, database is Oracle9i Enterprise Edition Release 9.2.0.6.0.
Thanks in advance,
Viliam

hope this helps;
SQL> set pagesize 25
SQL> set linesize 141
SQL> explain plan for
2 select ename from emp where ename = :x ;
Explained.
SQL> SELECT * FROM table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 6 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1 | 6 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("ENAME"=:X)
13 rows selected.
http://psoug.org/reference/explain_plan.html
http://psoug.org/reference/dbms_xplan.html

Please explain plan with 'BITMAP CONVERSION TO ROWIDS'

Hi,
in my 9.2.0.8 I've got plan like :
Plan
SELECT STATEMENT CHOOSECost: 26,104
     7 TABLE ACCESS BY INDEX ROWID UMOWY Cost: 26,105 Bytes: 41 Cardinality: 1
          6 BITMAP CONVERSION TO ROWIDS
               5 BITMAP AND
                    2 BITMAP CONVERSION FROM ROWIDS
                         1 INDEX RANGE SCAN UMW_PRD_KPD_KOD Cost: 406 Cardinality: 111,930
                    4 BITMAP CONVERSION FROM ROWIDS
                         3 INDEX RANGE SCAN UMW_PRD_KPR_KOD Cost: 13,191 Cardinality: 111,930 as far as I know Oracle is trying to combine two indexes , so if I create multicolumn index the plan should be better right ?
Generally all bitmap conversions related to b-tree indexes are trying to combine multiple indexes to deal with or/ index combine operations right ?
And finally what about AND_EQUAL hint is that kind of alternative for that bitmap conversion steps ?
Regards
Greg

as far as I know Oracle is trying to combine two indexes , so if I create multicolumn index the plan should be better right ?Only you can really tell - but if this is supposed to be a "precision" query the optimizer thinks you don't have a good index into the target data. Don't forget to consider the benefits of compressed indexes if you do follow this route.
Generally all bitmap conversions related to b-tree indexes are trying to combine multiple indexes to deal with or/ index combine operations right ?Bitmap conversions when there are no real bitmap indexes involved are always about combining multiple b-tree index range scans to minimise the number of reads from the table.
And finally what about AND_EQUAL hint is that kind of alternative for that bitmap conversion steps ?AND_EQUAL was an older mechanism for combining index range scans to minimise visits to the table - it was restricted to a maximum of 5 indexes per table - the indexes had to be single column, non-unique, and the predicates had to be equality. The access method is deprecated in 10g. (See the following note, and the comments in particular, for more details: http://jonathanlewis.wordpress.com/2009/05/08/ioug-day-4/ )
Regards
Jonathan Lewis

Pluggable Mapping causing VLD 1600 validation error

We are using OWB client 11g R2 on windows. I am trying to use the pluggable mapping functionality to use for our reference data lookups, whereby we want to retrieve full descriptions in several languages from the reference data table. The standalone mapping takes in two parameters in the input signature, both NVARCHAR2, a reference type and reference code to perform the lookup. There is then a key lookup whose output (5 NVARCHAR2 values) goes to an expression which has a CASE statement to evaluate the results before passing them to the output signature.
The problem is when using the pluggable mapping in a normal mapping it does not validate, and I am getting the VLD-1600: Lookup Condition for Key Lookup REF_DATA_APEX is blank. error. The key lookup of course does have a Lookup Condition.
The mapping is a simple one, taking a source and mostly mapping directly to the target. It is set based only. I have one source attribute being passed to the pluggable mapping along with a constant, and the output is passed to an expression (which doesn't actually do anything, but without this I got API8003 error when connecting the output attributes to the target attributes).
Is there something I am missing in how to implement this feature ?

Hi,
I am having the same problem with pluggable mapping and lookup operator, when mapping is syncronized it gives error VLD1108. I believe it is a bug of OWB 11.2.0.2.
Did you manage to resolve it?
Thanks,
Alex

Will a explain plan consider a function in a select statement.

Hi gurus,
I have a question regarding explain plan.
I ran a query, which returns me explain plan with multiple CPU costs around 300K.
now i use a function, and the number of lines displayed in explain plan reduces from 12 to 8 lines.
What i dont understand is.. Is the explain plan considering the function in the select statement ?
ex.
explain plan for
select column1,
         column2,
         function(value1)
from case
where case_no = 1will a explain plan consider the functions in a select statement ?
Thank you.

What i dont understand is.. Is the explain plan considering the function in the select statement ?Maybe there are tweaks which reveal more information from the explain plan, but a straightforward way won't necessarily expose any function call:
SQL> create or replace function get_dname (i_deptno integer)
   return varchar2
as
   l_dname   dept.dname%type;
begin
   select   dname
     into   l_dname
     from   dept
    where   deptno = i_deptno;
   return l_dname;
end get_dname;
Function created.
SQL> explain plan
   for
      select   ename, deptno, get_dname (deptno) dname
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.
SQL> truncate table plan_table
Table truncated.
SQL> explain plan
   for
      select   ename, deptno
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.

Explain Plan in sqldevloper

Hi,
in sqldevloper 3.1.07 some users (system or those with DBA role) can generate an explain plan but not all users.
Is there any option or privilege to grant ?
Thank you.

F6 : in SQL Developer runs an AutoTrace,and actually runs the SQL and also displays timings and the explain plan.
F10. : explain plan
Read
http://www.thatjeffsmith.com/archive/2012/02/quick-tip-comparing-explain-plans-with-sql-developer/

Bitmap conversion explain plan

Hi friends,
I'm trying to understand the explain plan with queries in my oracle 9.2 database. I have read something about but it is difficult to me to understand why the optimizer uses "bitmap conversion [to rowids]", "bitmap and" and "bitmap conversion [from rowids]". I'm not sure if this is a good or a bad signal. Probably is just I always find bitmap conversion when I'm not happy with queries results timin.
I have not bitmap indexes created in my database, and perhaps is it suggesting me to create them?
Thanks for answers.

Hi agemaia,
Take a look to this link:
http://www.dba-oracle.com/t_bitmap_conversion_to_rowid.htm
I think this answers your question, quite simple. I will write any other useful link.

Weird explain plan on multi-level structured XmlType column

Hello,
am running an explain on the follwing query on 11.2.0.2:
SELECT
T1.EVENT_ID,
ACTION_SUB_ID,
PARAM_KEY,
PARAM_VALUE,
TO_DATE('2013-12-10', 'YYYY-MM-DD')
FROM T_C_RMP_MNTRNG_XML_FULL_IL ,
XMLTABLE('/monitoring' PASSING XML_CONTENT COLUMNS
EVENT_ID VARCHAR2(4000) PATH 'eventId',
ACTIONS XMLTYPE PATH 'action'
) T1,
XMLTABLE('/action' PASSING T1.ACTIONS COLUMNS
ACTION_SUB_ID NUMBER(10,0) PATH 'actionSubId',
PARAMS xmltype PATH 'param'
) T2,
XMLTABLE('/param' PASSING T2.params columns
PARAM_KEY VARCHAR2(4000) PATH 'key',
PARAM_VALUE VARCHAR2(1000) PATH 'value'
) T3
WHERE MESSAGE_ID = 4972102 ;
Although MESSAGE_ID is the primary key of T_C_RMP_MNTRNG_XML_FULL_IL and thus there is only one record matching the condition, I get an explain plan with huge costs, 500MB of data and an estimated 10 hour runtime:
PLAN_TABLE_OUTPUT
Plan hash value: 4011854835
| Id | Operation                      | Name                  | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                       |   223K|   489M| 3111K (1)| 10:22:17 |
|   1 | NESTED LOOPS                  |                       |       |       |            |          |
|   2 |   NESTED LOOPS                 |                       |   223K|   489M| 3111K (1)| 10:22:17 |
|   3 |    NESTED LOOPS                |                       |   140K|    11M| 1678   (1)| 00:00:21 |
|* 4 |     INDEX RANGE SCAN           | X1B                   |     1 |    53 |     3   (0)| 00:00:01 |
|   5 |     TABLE ACCESS BY INDEX ROWID| T_OR_MON_ACTION       |   140K| 4542K| 1675   (1)| 00:00:21 |
PLAN_TABLE_OUTPUT
|* 6 |      INDEX RANGE SCAN          | X3                    |   140K|       |     4 (25)| 00:00:01 |
|* 7 |    INDEX RANGE SCAN            | X4G                   | 4083 |       |    22   (0)| 00:00:01 |
|   8 |   TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION_PARAM |     2 | 4428 |    52   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("MESSAGE_ID"=4972102)
   6 - access("SYS_ALIAS_0"."NESTED_TABLE_ID"="T_C_RMP_MNTRNG_XML_FULL_IL"."SYS_NC0001200013$")
   7 - access("NESTED_TABLE_ID"="SYS_ALIAS_0"."SYS_NC0000500006$")
PLAN_TABLE_OUTPUT
Note
   - dynamic sampling used for this statement (level=2)
When I run the query, the result comes back within 0.3 seconds.
Why is the explain plan off like that?
Is this just the way it is, or is there something going wrong here?

This is my table create statement:
CREATE TABLE QQRCSBI0.T_C_RMP_MNTRNG_XML_FULL_IL (
MESSAGE_ID NUMBER(22,0) NOT NULL ENABLE,
XML_EVAL_ID NUMBER(22,0),
VIN7 VARCHAR2(7 BYTE),
FLEET_ID VARCHAR2(50 BYTE),
CSC_SW_VERSION VARCHAR2(100 BYTE),
RECEIVED DATE,
XML_CONTENT SYS.XMLTYPE ,
DWH_LM_TS_UTC DATE NOT NULL ENABLE,
CONSTRAINT PK_C_RMP_MNTRNG_XML_FULL_IL5 PRIMARY KEY (MESSAGE_ID)
) NOLOGGING TABLESPACE CATALOG
VARRAY "XML_CONTENT"."XMLDATA"."ACTION" STORE AS TABLE "T_OR_MON_ACTION" (
NOLOGGING TABLESPACE "CATALOG"
VARRAY "PARAM" STORE AS TABLE "T_OR_MON_ACTION_PARAM" (
NOLOGGING TABLESPACE "CATALOG"
) RETURN AS LOCATOR
) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://mydomain.com/csc_monitoring_session.xsd" ELEMENT "monitoring";
I set all default table names in the schema to blank and registered the schema with genTables=false.
I am still running into problems retrieving the 3rd level T_OR_MON_ACTION_PARAM data. The query just crashes after a while because it is running out of either TEMP space or UNDO space (it keeps changing). I'll take a step back to re-evaluate and post another thread about that in a bit I guess...
You said "SQL*Plus explain plan, goes most of the time bananas" - is there a difference in what client (SqlPlus or SqlDeveloper) I use to get the explain plan? I thought the plan was generated by the DB and the clients just display the result, and the only difference is the way the clients display the plan?!

Strange behavior of explain plan

Hello i don't know if this is the correct category for posting my issue.
I ma facing a strange behavior of the explain plan. What i mean!
I have a query which runs very fast and it is well optimized. the explain plan shows very good results in cost and execution time.
when i am running the query for a second or a third time is appearing a different explain plan with not such a good cost and execution time.
Could you please guide me what it might be wrong???
thanks a lot

HI i found the correct category
thanks

How to provide tuning solution from explain plan only

Dear all,
If I do not have any kind of access to the database and only have explain plan with me,how I can provideperformance or query tuning solutions from that??
Regards
Anirban

958657,
If I do not have any kind of access to the database and only have explain plan with me,how I can provide performance or query tuning solutions from that??
This is contradictory as you said you don't have access but you have explain plan. You wont get any explain plan until you connect to the database and run "Explain plan for" statement for the query. How do you get the "explain plan"? If it is provided by someone to you, you might request to get the "Execution Plan" for the query.
Keep in mind that "explain plan" and "execution plan " - these two are not same.
Explain plan is not enough for predicting elapsed/response time of a query as Explain plan is static Whereas Execution plan is dynamic and talks about query in execution.
Oracle provides following things for a query to diagnose its performance :
1. Static - Explain plan - Not enough
2. Dynamic: Execution plan - Run time Plan
3. awr/ statspack execution plan --Run time from the past - this is again dynamic execution plan of query runs in the past
Tuning recommendation is possible by comparing run time of the same query in the past and today's run time and based on further analysis.
Tuning Recommendation is not possible if you have only Explain plan.

Inaccurate EXPLAIN PLAN...!!!

This is frightening... I've been working on a nasty query on a poorly designed data model and checking my work by hitting the Explain Plan button in SQLDeveloper. I was scratching my head over tons of hash joins and such, when all of a sudden I had a query with five tables showing an explain plan with only three!
I'll try to post the screen shot if I can.
Is there something that can cause this, and how can I fix it? Maybe the plan table is out of date?

What's the status of the plan_table.
A new 10gR2 database creates it as a GLOBAL TEMPORARY TABLE, so there shouldn't be any risk of tripping over any other sessions.
Otherwise there's always the risk of two people (or less likely, one person and multiple sessions) doing an EXPLAIN at the same time and picking up the wrong one.
If you don't have a GLOBAL TEMPORARY TABLE (and can't turn it into one), go the old-fashioned route and use EXPLAIN PLAN FOR STATEMENT make_up_an_id SELECT....
And use that statement id when querying the explain plan

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 AM

tobiwan 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/

Explain plan for query with variables

Trying to Explain plan for some sql in sql*plus. The query has a variable in it. How do I do this ?
I did look into explain plan and dbms_xplan but could not find anything with variables

use sqlplus bind variables:
SQL> --define variable
SQL> var x varchar2
SQL> -- notice the colon prefixing the variable
SQL> explain plan for select * from customer where cid = :x;
Explained.
SQL> select * from table( dbms_xplan.display );
PLAN_TABLE_OUTPUT
Plan hash value: 1709312366
| Id | Operation                   | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |          |     1 |    67 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| CUSTOMER |     1 |    67 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | CID      |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("CID"=:X)
14 rows selected.the variable does not need to be set to explain the query, since explain does not actually execute.
Edited by: shoblock on Nov 6, 2008 4:51 PM

EXPLAIN PLAN with pluggable mapping

Similar Messages

Maybe you are looking for