Using proper hint..

Good day everyone.
I have just found that we can set the optimizer hint on Block level by using
SET_BLOCK_PROPERTY('BLOCKNAME', OPTIMIZER_HINT,'Hint_Name');
well, how we determine a proper 'Hint_Name' to set OPTIMIZER_HINT property?
Can we use optimizer hint at other 'place' than Block Level??
Thank you..
Regards..
Nia...

As a general rule, it should not be necessary in 99% to use any optimizer hint. Make sure that you have proper statistics and let the cost based optimizer do its job.
where I can find the query of a block??You can either use :SYSTEM.LAST_QUERY or GET_BLOCK_PROPERTY('MYBLOCK', LAST_QUERY);

Similar Messages

How do I use Sql hints in PreparedStatement?

Hi,
I am trying to use a sql query which uses Oracle hints to optimize the query. I am using the ojdbc drivers from Oracle. I am using the PreparedStatement (Java 1.4) to execute this query, but it returns an empty resultset. If I remove the hint, then the query works fine using the PreparedStatement. Does anyone know how to make sql hints work using preparedstatement. I tried it with Statement object and that works (ie. the hint works and returns rows as expected).
The query is as follows:
select /*+ ordered
use_nl(ri ma)
count(*),
ma.columnName
from table1 ri,
table2 ma
where ma.columnName2 = ri.columnName2
and ma.column3 = 1
and ri.column4 = 66
group by ma.columnName
I tried escaping the /*+ but that also didn't work. Any help would be appreciated.
Thanks in advance,
Parag

Must be an old database.
Presumably you tried it in sqlplus and it worked both ways. If not then nothing you do will make it work in java.
Other than that my quess would be that it has nothing to do with the select.
Some possibilities.
1. You are eating exceptions.
2. You are not running the code that you think you are.

Using Oracle Hints in Selects......

Hello,
Are there any after effects/side effects by using Oracle Hints in a SQL select ??? (hints such as Cache, NOCache, all_rows)
Can anyone let me know whether there are any good documentation or site on Oracel SQL hints..
thanks
Kanchi

Hi!
There is an exception, that I think is a bug in Oracle, but I4m not sure. If you use the PARALLEL HINT in a select that will be use in a Cursor, in order to insert the results in other table, and the results come in groups built following a group by sentence, there are possibilities that two childs (a child is a parallel process) take portions of this whole group, and built each one one group.
If the new table use certain number of columns as a primary key, this may cause an duplicated primary key trigger.
I4m going to write and document this case, in order to show it to oracle support.
I hope this help. Bye.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by kanchana Hettiarachchi ([email protected]):
Hello,
Are there any after effects/side effects by using Oracle Hints in a SQL select ??? (hints such as Cache, NOCache, all_rows)
Can anyone let me know whether there are any good documentation or site on Oracel SQL hints..
thanks
Kanchi<HR></BLOCKQUOTE>
null

How to use Oracle Hints in OBIEE

Hello guys
I have a report that is running forever and I have reviewed the explain plan over and over, which makes me think that the join between these 2 tables are slowing everything down --- The fact table has 10Billion records and the Dim has 10 Millions records. Even if the report has filters on various columns of the 2 tables, it is still taking forever. The explain is showing that its doing a nested loop join of these 2 tables which takes a lot of time.
I am thinking of using some Hint to force the query to scan the dimension table first (with the filter condition I defined, it will return 80 rows only from Dim table), and then use the result set of the scanning to go and look for matching records only in the fact table. Its should help speed up the query..
I'd like to know what kind of hints can help with that kind of operation, also how to define these kind of hints in OBIEE. Now I know that in Physical Layers, I can include hints in physical table property, but how to determine which table (fact or dim) to embed the join hints?
Need advice from anybody who have experience working with hints?
Much appreciation!

Just an update:
I have tried a couple of join operation hints like USE_NL and USE_HASH hints, it changes the join method but didn't help with performance at all.
The original SQL that OBIEE generates is: ----------Takes about 20 mins to return a dozen rows
select sum(T991020.LP Amount) as c1,
T991021.DAYOFWEEK as c2,
T991021.PU DATES as c3
from RD_Grant.PU_DATES T991021, Dimension -----Huge
PU_Grant.PU_FACTS_9 T991020 FACT ----Gigantic
where (T991020.COMPANY = T991021.COMPANY
and T991020.DATES = T991021.DATES
and T991020.DATES between "10/10/2009" and "31/10/2009"
and T991021.DAYOFWEEK = 'Sunday'
and T991021.DATES between '09/13/2009' and '11/03/2009')
group by T991021.PU DATES, T991021.DAYOFWEEK
Basically I am still thinking of finding a way to force the query to scan the dimension table first (with the filter condition I defined, it will return 80 rows only from Dim table), and then use the result set of the scanning to go and look for matching records only in the fact table. Its should help speed up the query..
Any suggestions?
Thanks
Edited by: user7276913 on Nov 5, 2009 7:07 PM
Edited by: user7276913 on Nov 5, 2009 7:22 PM

Use of hints in query performance

Hi
Please let me know actual usage of hints in query tunging, how do we write hints of increase performnace.
let me know below query will gives better performnce. if hints are not use query will degrade performance.
SELECT /*+ ORDERED INDEX (b, jl_br_balances_n1) USE_NL (j b)
USE_NL (glcc glf) USE_MERGE (gp gsb) */
b.application_id ,
b.set_of_books_id ,
b.personnel_id,
p.vendor_id Personnel,
p.segment1 PersonnelNumber,
p.vendor_name Name
FROM jl_br_journals j,
jl_br_balances b,
gl_code_combinations glcc,
fnd_flex_values_vl glf,
gl_periods gp,
gl_sets_of_books gsb,
po_vendors p

942919 wrote:
Please let me know actual usage of hints in query tunging, how do we write hints of increase performnace.The majority of hints would be used to diagnose a performance problem by identifying a better query plan and fixing the underlying reason that the optimizer did not select that plan automatically. Hints used in this way would be removed from the query after the cause of the performance problem was fixed.
http://docs.oracle.com/cd/E11882_01/server.112/e16638/hintsref.htm#i8327
Hints change the access paths and methods the optimizer chooses, so before using a hint, you need to understand what the optimizer does, what access methods are, when they are chosen, and what they are best used for.
To do that you need to read the Performance Tuning Guide
http://docs.oracle.com/cd/E11882_01/server.112/e16638/toc.htm
At a minimum reading and understanding these sections -
http://docs.oracle.com/cd/E11882_01/server.112/e16638/perf_overview.htm#i1006218
http://docs.oracle.com/cd/E11882_01/server.112/e16638/optimops.htm#i21299
http://docs.oracle.com/cd/E11882_01/server.112/e16638/ex_plan.htm#i19260
http://docs.oracle.com/cd/E11882_01/server.112/e16638/stats.htm#i13546
Then you should be able to use a hint safely.
let me know below query will gives better performnce. if hints are not use query will degrade performance.Not true, hints change the performance of queries they can make them slower as well as faster. Here is an example of an index hint slowing down a query
{message:id=1989089}

Is using Parallel Hint /*+PARALLEL */ good or bad?

Hi,
I am facing problem in using /*+ PARALLEL */ hint in SQL Query its taken long time to execute.
Is using PARALLEL Hint degrades performance?
The Table FCT_TABLE is having PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT ) clause.
We are using parallel hint as SELECT /*+ PARALLEL(FCT_TABLE 2)
Any help will be needful for me.
Thanks and Regards

user598986 wrote:
We have noticed the following from the Server:
1.The Disk I/O is showing 0 always during the time of Execution of the Query.
2.The I/O Adapter is showing 700%.What is the o/s and version? Do you use any virtualisation? What storage system do you use? What RAID levels, if any? And how did you monitor these results?
Note that the physical I/O layer is not part of the database layer. From the database layer you typically address I/O issues with
- logical design (e.g. normalise data so that there's a single copy of the data to maintain and thus less I/O)
- physical design (e.g. use partitioning, IOTs, clusters, indexes and so on to facilitate less I/O to process data)
- parallelise (use multiple processes to perform large I/O scans to address some of the inherited latency issues when doing I/O)
- reduce I/O (e.g. by truncating a table or partition instead of deleting it, using CTAS, design s/w that only needs to make a single pass through a data set, etc)
From the database app level you have no control over where the data is stored, how it is stored and cached. So, as PL/SQL or app developer, your primary concern should be the amount of I/O your data model and app needs - as that is something you can and do control. And not worry about the physical implementation of the I/O layer. As that should be the concern of the sys admin and DBA of that platform.

Why we are using No_Filtering hint?

Hi
can anyone tell me why we are using No_Filtering hint?
This query is Retriving extra rows when hints not applied.What is the reason.
Select /*+ No_Filtering */ *
from (select /*+ No_Filtering */
true_name, true_name_cmprsd, jurisname, entityids, ht,
max(ht) over(partition by true_name_cmprsd) ht_1
from (select /*+ No_Filtering */true_name, true_name_cmprsd,
LTRIM(SYS_CONNECT_BY_PATH(entity_id, '; '), '; ') AS EntityIds,
juris_short_name JurisName,
LEVEL HT
FROM (select /*+ No_Filtering */e.true_name, e.TRUE_NAME_CMPRSD, j.JURIS_SHORT_NAME, e.entity_id,
ROW_NUMBER() OVER(PARTITION BY TRUE_NAME_CMPRSD ORDER BY ENTITY_ID) AS curr,
ROW_NUMBER() OVER(PARTITION BY TRUE_NAME_CMPRSD ORDER BY ENTITY_ID) - 1 AS prev
from SIV_JURISDICTION j, arv_entity e
where e.ENTITY_STATUS_CD = 2002 and
e.DOM_JURIS_ID = j.JURIS_ID and juris_id = 8)
connect by prev = PRIOR curr AND true_name_cmprsd = PRIOR true_name_cmprsd
start with curr = 1)
WHERE ht > 1)
where ht = ht_1
order by upper(true_name)
Thanks in advance...

Because one of your developers or DBAs thought it would be neat to use an undocumented hint.Possibly, although Oracle support have recommended us use hints (such as NO_CONNECT_BY_FILTERING) on several occasions to work around bugs in CONNECT BY queries.
I also recall a specific recommendation to consider the NO_FILTERING hint in the Oracle error messages documentation when running out of temporary space in CONNECT BY queries, I'll see if I can find the link.
Not that I support the use of hints in production of course, just that there are some mitigating circumstances around CONNECT BY behaviour.

Explicitly using full hint

Hi
In some of codes, I see the DBA explicitly force the sql to perform a full table scan by using full hint. What should be the reason?
thanks

user8779435 wrote:
I know Anurag. But what could be the reason for DBA to believe on that ...By comparing the one with without full hint and one with full hint.
If he would be getting better response time or less consistent gets or any other stats that he fill is better for the plan.
Like sometime doing full table scan would make a query to do hash join rather than nested loop and it could be possible that full table scan with hash join is giving better stats then index scan with nested loop
Regards
Anurag

Unable to resolve single DNS name using root hints

Recently, we had reports that we could not internally resolve a certain .com domain name (discovered by undeliverable e-mails). A lookup using an external server (Google's in our case) resolves the .com name just fine.
Long ago, we had another DNS issue that lead us into implementing the following registry change:
https://support.microsoft.com/kb/968372?wa=wsignin1.0
1. Start Registry Editor (Regedit.exe).
2. Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
3. On the Edit menu, click
New, click DWORD (32-bit) Value , and then add the following value:
Value: MaxCacheTtl
Data Type: DWORD
Data value: 0x2A300 (172800 in decimal = 2 days)
That is the only DNS change that we have made. We are using root hints, but temporarily added Google DNS as a forwarder so that we are able to resolve this .com address.
As a test, I did remove that registry entry, restarted the DNS service and tested again to no avail.
Any starting points?

Hi,
According to your description, my understanding is that DNS server can’t resolve .com with its root hint.
Could you provide more information about the DNS architecture, such as numbers of DNS servers, their locations and relationships, system version, etc.
And please post the results of NSlookup test(use local DNS server, and then use Google's server to resolve name ) here.
Best Regards,
Eve Wang
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

How else can I get my password if I forgot it to log in? Besides just using the hint?

I have two user accounts on my macbook pro. One I use for mostly everything, and the other is just for editing videos and stuff. I haven't been on that second one in a while, and I just recently tried to log onto it and it is saying my password is incorrect. I know I am typing in the correct password. When I clicked on password hint, it said the brady bunch, and I know for a fact that isn't my hint. Does anyone know if there is any other way to find out what my password was? Does this mean someone hacked into that account and changed the password? Please help, thanks!

Mac OS X: Changing or resetting an account password

Accessing the records in ascending order using index hint

I am getting a problem in selecting the rows using the index hint which in i want to query in the ascending order.
for eg.
select /*+ index(temp_itr_header,tmp_itrhdr_1#IDX2) */ person_id
from temp_itr_header

Oracle knows that it doesn't have to resort data if it accessed individual rows from an index with the same sort order. In other words, adding the ORDER BY clause need not cause Oracle to do any extra work. Adding the ORDER BY does guarantee that the results will be sorted and will tend to cause Oracle to use the index, assuming it can avoid the sort that way. If you don't have an ORDER BY, Oracle is free to return rows in whatever order it would like regardless of your hint.
If you want to use the index hint, the syntax is
SELECT /*+ INDEX(temp_itr_header <<index name>>) */Note that you do not want to have a comma in your hint. Of course, if your statistics are accurate, you shouldn't need to resort to a hint here-- the CBO should pick the most efficient path.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

How To Use Control Hint Label In columnHeader?

Using JDeveloper 9.0.3 I created a uiXML-BC4J app.
I specified control hint Labels for each attribute in a view object whose source is a db table. The uix page browses the table using the view object. How do I get the column header to use the Control Hint Label? I'm currently hard coding column header text:
<columnHeader>
<bc4j:sortableHeader text="Product No" />
</columnHeader>
I would rather specify the control hint Label. How do I do that?
Thanks for your time.
Greg

By "in the page", I meant just as you're doing it now.
You could also externalize it to a Java ResourceBundle;
see the "Internationalization" chapter of the UIX
developer's guide.

Use of Hints in performance tuning

Hi
Please let me know actual usage of hints in query tunging, how do we write hints of increase performnace.
let me know below query will gives better performnce. if hints are not use query will degrade performance.
SELECT /*+ ORDERED INDEX (b, jl_br_balances_n1) USE_NL (j b)
USE_NL (glcc glf) USE_MERGE (gp gsb) */
b.application_id ,
b.set_of_books_id ,
b.personnel_id,
p.vendor_id Personnel,
p.segment1 PersonnelNumber,
p.vendor_name Name
FROM jl_br_journals j,
jl_br_balances b,
gl_code_combinations glcc,
fnd_flex_values_vl glf,
gl_periods gp,
gl_sets_of_books gsb,
po_vendors p

You'll likely have better luck posting this to an Oracle database forum, such as this one: PL/SQL
The forum you have posted this to is for Oracle Policy Automation.
Kind regards,
Davin.

Index is not used, although hint.

DBVersion: 10.2.0.3
CREATE TABLE "ESW"."DURCHLAUFZEIT_SONDER_AG"
   (     "AG" NUMBER(3,0) DEFAULT 0 NOT NULL ENABLE,
     "TAGE" NUMBER(5,0) DEFAULT 0 NOT NULL ENABLE,
     "ABTEILUNG" VARCHAR2(20 BYTE),
Content of this table
AG    TAGE ABTEILUNG
910     1     EAV
133     1     TG
743     2     TM
719     2     TM
706     2     TM
979     10     TMWhen I use a select like this no index on tabel "walze w2" is used:
select /*+ index(apl(arbeitsgang_nr))*/
       /*+ index(w2 WALZE_IND1)*/
        SUM (dsa.tage) tage,
         w2.walzen_nr walzen_nr,
        w2.walzen_ng walzen_ng
      from durchlaufzeit_sonder_ag dsa,
           auftrag_arbeitsplan apl,
           walze w2
      where apl.arbeitsgang_nr in
          ( select dsa1.ag ag
            from durchlaufzeit_sonder_ag dsa1
            where dsa1.abteilung = 'TM' )*and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
     w2.walzen_ng;
| Id | Operation                       | Name                           | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                |                                |    21 | 1155 | 4927 |
|   1 | SORT GROUP BY                  |                                |    21 | 1155 | 4927 |
|* 2 |   HASH JOIN                     |                                |    21 | 1155 | 4922 |
|   3 |    NESTED LOOPS                 |                                |   333 | 11655 | 4682 |
|   4 |     NESTED LOOPS                |                                | 16215 |   427K| 4682 |
|   5 |      TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG        |     4 |    40 |     2 |
|* 6 |       INDEX RANGE SCAN          | DURCHLAUFZEIT_SONDER_AG_INDEX1 |     4 |       |     1 |
|   7 |      TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN            | 4054 | 68918 | 1170 |
|* 8 |       INDEX RANGE SCAN          | AUFTRAG_ARBEITSPLAN_IND3       | 4054 |       |     7 |
|* 9 |     INDEX RANGE SCAN            | DURCHLAUFZEIT_SONDER_AG_INDEX2 |     1 |     8 |       |
| 10 |    *TABLE ACCESS FULL*            | WALZE                          | 75432 | 1473K|   239 |
--------------------------------------------------------------------------------------------------When I start the same sql with providing the select from tabel "durchlaufzeit_sonder_ag" by my own the index is used:
select /*+ index(apl(arbeitsgang_nr))*/
       /*+ index(w2 WALZE_IND1)*/
        SUM (dsa.tage) tage,
         w2.walzen_nr walzen_nr,
        w2.walzen_ng walzen_ng
      from durchlaufzeit_sonder_ag dsa,
           auftrag_arbeitsplan apl,
           walze w2
      where apl.arbeitsgang_nr in
                      ( 743, 719, 706, 979 )
and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
w2.walzen_ng;
| Id | Operation                        | Name                           | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                 |                                |     2 |    94 | 1161 |
|   1 | SORT GROUP BY                   |                                |     2 |    94 | 1161 |
|   2 |   TABLE ACCESS BY INDEX ROWID    | WALZE                          |     1 |    20 |     2 |
|   3 |    NESTED LOOPS                  |                                |     2 |    94 | 1156 |
|* 4 |     HASH JOIN                    |                                |    31 |   837 | 1094 |
|   5 |      INLIST ITERATOR             |                                |       |       |       |
|   6 |       TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG        |     3 |    30 |     2 |
|* 7 |        INDEX RANGE SCAN          | DURCHLAUFZEIT_SONDER_AG_INDEX2 |     3 |       |     1 |
|   8 |      INLIST ITERATOR             |                                |       |       |       |
|   9 |       TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN            | 2276 | 38692 | 1091 |
|* 10 |        INDEX RANGE SCAN          | AUFTRAG_ARBEITSPLAN_IND3       | 2276 |       |     8 |
|* 11 |     INDEX RANGE SCAN             | WALZE_IND1                     |     1 |       |     1 |
---------------------------------------------------------------------------------------------------I do not understand this. Why oracle do not use the index (provided in hint) when I select the values from table durchlaufzeit_sonder_ag, but when providing the values by my own, it uses the index?

As far as I am aware only the first hint comment within a given query block is considered.
So these would be valid (provided hint_one is correctly specified)...
SELECT /*+ hint_one hint_two */
       column_name
FROM   table_name;
SELECT /*+
       hint_one
       hint_two
       column_name
FROM   table_name;
SELECT /*+ hint_one
       hint_two */
       column_name
FROM   table_name;
SELECT --+ hint_one hint_two
       column_name
FROM   table_name;But this would not (irrespective of whether hint_one is correctly specified)...
SELECT /*+ hint_one */
       /*+ hint_two */
       column_name
FROM   table_name;Also I don't believe your specification of the INDEX hint is correct, a single set of parenthesis should be used and the table alias and index name should be separated by either a space or comma.
So these would be fine...
SELECT /*+ INDEX (table_alias index_name) */
       column_name
FROM   table_name;
SELECT /*+ INDEX (table_alias, index_name) */
       column_name
FROM   table_name;But this would not...
SELECT /*+ INDEX (table_alias (index_name)) */
       column_name
FROM   table_name;Also you should be aware that an INDEX hint will only be considered provided that a given join order supports it.

Using First_rows hints change the sql plan

Dear All,
I have a query with a first_rows hint and this causing it to used sub-optimal plan by choosing the wrong indexes.
Besides, its applied a conversion function to the where clause condition compared if the case if it is using the right plan.
Appreciate if you can throw some light on using the first_rows hint
Thanks
Rgds
Ung

Hi, attached is the two plans as well the 10053 for the two plans. As you can see, with the first_rows hint, the consistent gets is 9049 while without the hints is only 5 blocks.
Execution Plan
0
SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=4521 Card=3 Bytes=357)
1 0
TABLE ACCESS (BY INDEX ROWID) OF 'MHDISL' (Cost=4521 Card=3 Bytes=357)
2 1
INDEX (RANGE SCAN) OF 'MHDISL10' (NON-UNIQUE) (Cost=4520 Card=3)
Statistics
0 recursive calls
0 db block gets
9049 consistent gets
0 physical reads
0 redo size
2501 bytes sent via SQL*Net to client
656 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Execution Plan
0
SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=3 Bytes=357)
1 0
TABLE ACCESS (BY INDEX ROWID) OF 'MHDISL' (Cost=4 Card=3 Bytes=357)
2 1
INDEX (RANGE SCAN) OF 'MHDISL00' (UNIQUE) (Cost=3 Card=3)
Statistics
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
2501 bytes sent via SQL*Net to client
656 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
-------10053
/u01/app/oracle/admin/FMSB/udump/fmsb_ora_5484.trc
Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
ORACLE_HOME = /u01/app/oracle/product/9.2.0
System name: SunOS
Node name: ffmdb
Release: 5.8
Version: Generic_108528-22
Machine: sun4u
Instance name: FMSB
Redo thread mounted by this instance: 1
Oracle process number: 141
Unix process pid: 5484, image: oracle@ffmdb (TNS V1-V3)
*** 2009-01-20 15:21:54.490
*** SESSION ID:(201.51419) 2009-01-20 15:21:54.327
QUERY
seLECT /*+ first_Rows */* FROM MVXJDTA.MHDISL WHERE URCONO= 100
AND URDLIX=1000000001
ORDER BY URCONO,URDLIX,URRORC,URRIDN,URRIDL
*** SESSION ID:(201.51419) 2009-01-20 15:22:02.887
QUERY
DELETE FROM PLAN_TABLE WHERE STATEMENT_ID=:1
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
OPTIMIZERPERCENT_PARALLEL = 101
HASH_AREA_SIZE = 6144000
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 3072000
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
ALWAYSSTAR_TRANSFORMATION = FALSE
BTREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
COMPLEXVIEW_MERGING = TRUE
PUSHJOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
SYSTEMINDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 100
OPTIMIZER_DYNAMIC_SAMPLING = 1
OPTIMIZERDYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = FALSE
QUERY_REWRITE_INTEGRITY = ENFORCED
INDEXJOIN_ENABLED = TRUE
SORTELIMINATION_COST_RATIO = 0
OREXPAND_NVL_PREDICATE = TRUE
NEWINITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
OPTIMIZERMODE_FORCE = TRUE
OPTIMIZERUNDO_CHANGES = FALSE
UNNESTSUBQUERY = TRUE
PUSHJOIN_UNION_VIEW = TRUE
FASTFULL_SCAN_ENABLED = TRUE
OPTIMENHANCE_NNULL_DETECTION = TRUE
ORDEREDNESTED_LOOP = TRUE
NESTEDLOOP_FUDGE = 100
NOOR_EXPANSION = FALSE
QUERYCOST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
IMPROVEDROW_LENGTH_ENABLED = TRUE
USENOSEGMENT_INDEXES = FALSE
ENABLETYPE_DEP_SELECTIVITY = TRUE
IMPROVEDOUTERJOIN_CARD = TRUE
OPTIMIZERADJUST_FOR_NULLS = TRUE
OPTIMIZERCHOOSE_PERMUTATION = 0
USECOLUMN_STATS_FOR_FUNCTION = TRUE
SUBQUERYPRUNING_ENABLED = TRUE
SUBQUERYPRUNING_REDUCTION_FACTOR = 50
SUBQUERYPRUNING_COST_FACTOR = 20
LIKEWITH_BIND_AS_EQUALITY = FALSE
TABLESCAN_COST_PLUS_ONE = TRUE
SORTMERGEINEQUALITY_JOIN_OFF = FALSE
DEFAULTNON_EQUALITY_SEL_CHECK = TRUE
ONESIDECOLSTAT_FOR_EQUIJOINS = TRUE
OPTIMIZERCOST_MODEL = CHOOSE
GSETSALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 32
NEWSORT_COST_ESTIMATE = TRUE
GSANTI_SEMI_JOIN_ALLOWED = TRUE
CPUTO_IO = 0
PREDMOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: MHDISL Alias: MHDISL
TOTAL :: CDN: 1592807 NBLKS: 27904 AVG_ROW_LEN: 119
-- Index stats
INDEX NAME: MHDISL00 COL#: 1 2 3 4 5
TOTAL :: LVLS: 2 #LB: 8769 #DK: 1599266 LB/K: 1 DB/K: 1 CLUF: 356837
INDEX NAME: MHDISL10 COL#: 1 3 4 5 2
TOTAL :: LVLS: 2 #LB: 9036 #DK: 1608279 LB/K: 1 DB/K: 1 CLUF: 424881
INDEX NAME: MHDISL30 COL#: 1 2 3 4 16 5
TOTAL :: LVLS: 2 #LB: 9493 #DK: 1599279 LB/K: 1 DB/K: 1 CLUF: 356844
INDEX NAME: MHDISL40 COL#: 1 2 9 10 11 3 4 5
TOTAL :: LVLS: 2 #LB: 11082 #DK: 1599282 LB/K: 1 DB/K: 1 CLUF: 388975
OPTIMIZERPERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
Column: URCONO Col#: 1 Table: MHDISL Alias: MHDISL
NDV: 2 NULLS: 0 DENS: 5.0000e-01 LO: 100 HI: 999
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: URDLIX Col#: 2 Table: MHDISL Alias: MHDISL
NDV: 295495 NULLS: 0 DENS: 3.3842e-06 LO: 1000000001 HI: 930000
1938
NO HISTOGRAM: #BKT: 1 #VAL: 2
TABLE: MHDISL ORIG CDN: 1592807 ROUNDED CDN: 3 CMPTD CDN: 3
Access path: tsc Resc: 1702 Resp: 1702
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL00
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4521
IX_SEL: 5.0000e-01 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL30
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL40
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
BEST_CST: 4.00 PATH: 4 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: MHDISL[MHDISL]#0
Best so far: TABLE#: 0 CST: 4 CDN: 3 BYTES: 357
****** Recost for ORDER BY (using index) ************
SINGLE TABLE ACCESS PATH
TABLE: MHDISL ORIG CDN: 1592807 ROUNDED CDN: 3 CMPTD CDN: 3
Access path: tsc Resc: 1702 Resp: 1702
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4521
IX_SEL: 5.0000e-01 TB_SEL: 1.6921e-06
BEST_CST: 4521.00 PATH: 4 Degree: 1
Join order[1]: MHDISL[MHDISL]#0
Best so far: TABLE#: 0 CST: 4521 CDN: 3 BYTES: 357
SORT resource Sort statistics
Sort width: 7 Area size: 131072 Max Area size: 5242880
Degree: 1
Blocks to Sort: 1 Row size: 141 Rows: 3
Initial runs: 1 Merge passes: 1 IO Cost / pass: 2
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
Final - First Rows Plan:
JOIN ORDER: 1
CST: 4521 CDN: 3 RSC: 4521 RSP: 4521 BYTES: 357
IO-RSC: 4521 IO-RSP: 4521 CPU-RSC: 0 CPU-RSP: 0
First Rows Plan
QUERY
EXPLAIN PLAN SET STATEMENT_ID='PLUS114150' FOR seLECT /*+ first_Rows */* FROM MV
XJDTA.MHDISL WHERE URCONO= 100
AND URDLIX=1000000001
ORDER BY URCONO,URDLIX,URRORC,URRIDN,URRIDL
PLAN
Cost of plan: 4521
Operation...........Object name.....Options.........Id...Pid..
SELECT STATEMENT 0
TABLE ACCESS MHDISL BY INDEX ROWID 1
INDEX MHDISL10 RANGE SCAN 2 1
QUERY
SELECT ID ID_PLUS_EXP,PARENT_ID PARENT_ID_PLUS_EXP,LPAD(' ',2*(LEVEL-1))||OPERAT
ION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'',' ('||OPTIONS||')')||
DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')||DECODE(OBJECT_TYPE,NULL
,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,DECODE(OPTIMIZER,NULL,'',' Optimizer='|
|OPTIMIZER))||DECODE(COST,NULL,'',' (Cost='||COST||DECODE(CARDINALITY,NULL,'','
Card='||CARDINALITY)||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') PLAN_PLUS_EXP
,OBJECT_NODE OBJECT_NODE_PLUS_EXP FROM PLAN_TABLE START WITH ID=0 AND STATEMENT_
ID=:1 CONNECT BY PRIOR ID=PARENT_ID AND STATEMENT_ID=:1 ORDER BY ID,POSITION
QUERY
SELECT ID ID_PLUS_EXP,OTHER_TAG OTHER_TAG_PLUS_EXP,OTHER OTHER_PLUS_EXP FROM PLA
N_TABLE WHERE STATEMENT_ID=:1 AND OTHER_TAG IS NOT NULL ORDER BY ID
QUERY
DELETE FROM PLAN_TABLE WHERE STATEMENT_ID=:1
*** 2009-01-20 15:29:36.507
*** SESSION ID:(201.51419) 2009-01-20 15:29:36.507
QUERY
SELECT * FROM MVXJDTA.MHDISL WHERE URCONO= 100
AND URDLIX=1000000001
ORDER BY URCONO,URDLIX,URRORC,URRIDN,URRIDL
*** SESSION ID:(201.51419) 2009-01-20 15:29:38.307
QUERY
DELETE FROM PLAN_TABLE WHERE STATEMENT_ID=:1
PARAMETERS USED BY THE OPTIMIZER
OPTIMIZER_FEATURES_ENABLE = 9.2.0
OPTIMIZER_MODE/GOAL = Choose
OPTIMIZERPERCENT_PARALLEL = 101
HASH_AREA_SIZE = 6144000
HASH_JOIN_ENABLED = TRUE
HASH_MULTIBLOCK_IO_COUNT = 0
SORT_AREA_SIZE = 3072000
OPTIMIZER_SEARCH_LIMIT = 5
PARTITION_VIEW_ENABLED = FALSE
ALWAYSSTAR_TRANSFORMATION = FALSE
BTREE_BITMAP_PLANS = TRUE
STAR_TRANSFORMATION_ENABLED = FALSE
COMPLEXVIEW_MERGING = TRUE
PUSHJOIN_PREDICATE = TRUE
PARALLEL_BROADCAST_ENABLED = TRUE
OPTIMIZER_MAX_PERMUTATIONS = 2000
OPTIMIZER_INDEX_CACHING = 0
SYSTEMINDEX_CACHING = 0
OPTIMIZER_INDEX_COST_ADJ = 100
OPTIMIZER_DYNAMIC_SAMPLING = 1
OPTIMIZERDYN_SMP_BLKS = 32
QUERY_REWRITE_ENABLED = FALSE
QUERY_REWRITE_INTEGRITY = ENFORCED
INDEXJOIN_ENABLED = TRUE
SORTELIMINATION_COST_RATIO = 0
OREXPAND_NVL_PREDICATE = TRUE
NEWINITIAL_JOIN_ORDERS = TRUE
ALWAYS_ANTI_JOIN = CHOOSE
ALWAYS_SEMI_JOIN = CHOOSE
OPTIMIZERMODE_FORCE = TRUE
OPTIMIZERUNDO_CHANGES = FALSE
UNNESTSUBQUERY = TRUE
PUSHJOIN_UNION_VIEW = TRUE
FASTFULL_SCAN_ENABLED = TRUE
OPTIMENHANCE_NNULL_DETECTION = TRUE
ORDEREDNESTED_LOOP = TRUE
NESTEDLOOP_FUDGE = 100
NOOR_EXPANSION = FALSE
QUERYCOST_REWRITE = TRUE
QUERY_REWRITE_EXPRESSION = TRUE
IMPROVEDROW_LENGTH_ENABLED = TRUE
USENOSEGMENT_INDEXES = FALSE
ENABLETYPE_DEP_SELECTIVITY = TRUE
IMPROVEDOUTERJOIN_CARD = TRUE
OPTIMIZERADJUST_FOR_NULLS = TRUE
OPTIMIZERCHOOSE_PERMUTATION = 0
USECOLUMN_STATS_FOR_FUNCTION = TRUE
SUBQUERYPRUNING_ENABLED = TRUE
SUBQUERYPRUNING_REDUCTION_FACTOR = 50
SUBQUERYPRUNING_COST_FACTOR = 20
LIKEWITH_BIND_AS_EQUALITY = FALSE
TABLESCAN_COST_PLUS_ONE = TRUE
SORTMERGEINEQUALITY_JOIN_OFF = FALSE
DEFAULTNON_EQUALITY_SEL_CHECK = TRUE
ONESIDECOLSTAT_FOR_EQUIJOINS = TRUE
OPTIMIZERCOST_MODEL = CHOOSE
GSETSALWAYS_USE_TEMPTABLES = FALSE
DB_FILE_MULTIBLOCK_READ_COUNT = 32
NEWSORT_COST_ESTIMATE = TRUE
GSANTI_SEMI_JOIN_ALLOWED = TRUE
CPUTO_IO = 0
PREDMOVE_AROUND = TRUE
BASE STATISTICAL INFORMATION
Table stats Table: MHDISL Alias: MHDISL
TOTAL :: CDN: 1592807 NBLKS: 27904 AVG_ROW_LEN: 119
-- Index stats
INDEX NAME: MHDISL00 COL#: 1 2 3 4 5
TOTAL :: LVLS: 2 #LB: 8769 #DK: 1599266 LB/K: 1 DB/K: 1 CLUF: 356837
INDEX NAME: MHDISL10 COL#: 1 3 4 5 2
TOTAL :: LVLS: 2 #LB: 9036 #DK: 1608279 LB/K: 1 DB/K: 1 CLUF: 424881
INDEX NAME: MHDISL30 COL#: 1 2 3 4 16 5
TOTAL :: LVLS: 2 #LB: 9493 #DK: 1599279 LB/K: 1 DB/K: 1 CLUF: 356844
INDEX NAME: MHDISL40 COL#: 1 2 9 10 11 3 4 5
TOTAL :: LVLS: 2 #LB: 11082 #DK: 1599282 LB/K: 1 DB/K: 1 CLUF: 388975
OPTIMIZERPERCENT_PARALLEL = 0
SINGLE TABLE ACCESS PATH
Column: URCONO Col#: 1 Table: MHDISL Alias: MHDISL
NDV: 2 NULLS: 0 DENS: 5.0000e-01 LO: 100 HI: 999
NO HISTOGRAM: #BKT: 1 #VAL: 2
Column: URDLIX Col#: 2 Table: MHDISL Alias: MHDISL
NDV: 295495 NULLS: 0 DENS: 3.3842e-06 LO: 1000000001 HI: 930000
1938
NO HISTOGRAM: #BKT: 1 #VAL: 2
TABLE: MHDISL ORIG CDN: 1592807 ROUNDED CDN: 3 CMPTD CDN: 3
Access path: tsc Resc: 1702 Resp: 1702
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL00
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4521
IX_SEL: 5.0000e-01 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL30
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL40
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
BEST_CST: 4.00 PATH: 4 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: MHDISL[MHDISL]#0
Best so far: TABLE#: 0 CST: 4 CDN: 3 BYTES: 357
****** Recost for ORDER BY (using index) ************
SINGLE TABLE ACCESS PATH
TABLE: MHDISL ORIG CDN: 1592807 ROUNDED CDN: 3 CMPTD CDN: 3
Access path: tsc Resc: 1702 Resp: 1702
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4521
IX_SEL: 5.0000e-01 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL30
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 1
Access path: index (scan)
Index: MHDISL40
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4
IX_SEL: 1.6921e-06 TB_SEL: 1.6921e-06
BEST_CST: 4.00 PATH: 4 Degree: 1
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Join order[1]: MHDISL[MHDISL]#0
Best so far: TABLE#: 0 CST: 4 CDN: 3 BYTES: 357
****** Recost for ORDER BY (using index) ************
SINGLE TABLE ACCESS PATH
TABLE: MHDISL ORIG CDN: 1592807 ROUNDED CDN: 3 CMPTD CDN: 3
Access path: tsc Resc: 1702 Resp: 1702
Skip scan: ss-sel 0 andv 292691
ss cost 292691
index io scan cost 4518
Access path: index (scan)
Index: MHDISL10
TABLE: MHDISL
RSC_CPU: 0 RSC_IO: 4521
IX_SEL: 5.0000e-01 TB_SEL: 1.6921e-06
BEST_CST: 4521.00 PATH: 4 Degree: 1
Join order[1]: MHDISL[MHDISL]#0
SORT resource Sort statistics
Sort width: 7 Area size: 131072 Max Area size: 5242880
Degree: 1
Blocks to Sort: 1 Row size: 141 Rows: 3
Initial runs: 1 Merge passes: 1 IO Cost / pass: 2
Total IO sort cost: 2
Total CPU sort cost: 0
Total Temp space used: 0
Final - All Rows Plan:
JOIN ORDER: 1
CST: 4 CDN: 3 RSC: 4 RSP: 4 BYTES: 357
IO-RSC: 4 IO-RSP: 4 CPU-RSC: 0 CPU-RSP: 0
QUERY
EXPLAIN PLAN SET STATEMENT_ID='PLUS114150' FOR SELECT * FROM MVXJDTA.MHDISL WHE
RE URCONO= 100
AND URDLIX=1000000001

Using proper hint..

Similar Messages

Maybe you are looking for