Index access serial

Hi all

There is an index created in the

CREATING INDEX 'TEST' ON "TAB1" ("STAGE_TYPE", "REPORT_TIME")

It's local index and degree's 16 table is partitioned on report_time, if I run the query:

Select max (report_time) in tab1;

The index is used, but it is a series (I checked EM) explain the plan said operation PX and runs for hours

If I create a local index level 16, CREATE INDEX "TEST1" ON "TAB1" ("REPORT_TIME") then the same query is executed in less than a second, which could be the reason?

11.2.0.4 on rhel

In the second case, the index is created exclusively by the single column in your MAX function. If Oracle can simply go to the block of leaves to the right and find the maximum value. In the first case, Oracle must read all the blocks of leaves to figure out that one contains the maximum value. As another test, try to create the index on (REPORT_TIME, STAGE_TYPE), in other words, reverse the order of columns in composite index you. See how well that runs.

See you soon,.
Brian

Tags: Database

Similar Questions

  • RBO and Index access


    Hi I have a 9i database that uses a RBO and we have a query as follows

    tab, select min (a) where b = '111' and c = '1234444' and a > 0;

    We have an index of primary key on the columns a, b and c.Unfortunately the query makes a full table scan, even if the index is present. East - this behaviour will rule based optimizer? Should not go to the index that we select a single line?

    : Note the RBO is used in a production environment, and we cannot change it now.

    Query 1 uses an analysis complete of the index, it reads the ENTIRE index.

    A full table scan is replaced by a full analysis of the index, if there is a unique key of the table,

    Your interpretation of the results of the explain plan for query 1 is wrong: due to the incorrect table design and code wrong, it must use FULL scan restricted index, and he cannot use normal index access.

    If BOTH statements are ineffective due to the implicit conversion! TWO of them. Not a single one.

    And the lack of statistics in the database system Oracle uses the default values for IOSEEKTIM and IOTFRSPEED.

    The column ID in the second query is also authorized NULL, sort of to_number (ID) leads to NULL, which is never in a B-Tree index.

    Oracle did just what you ask. Design of database or application must be fixed, or you must put crutches (the indices of basic function) in the allover database, Oracle to compensate for the incorrect database and application design.

    ---------

    Sybrand Bakker

    Senior Oracle DBA

  • TPC-2106 t: can't access serial port

    I used visa function reading read the serial port through PTC but byte is always zero.

    How to access the serial port?


  • can't access serial port make sure you have the proper authorization

    Separated from this thread.

    IH im nithin my laptop does not take my dongel mts it is showing error massage as it is impossible to access the serial port, make sure that you have proper authorization can solve this problem

    Hello

    Sorry for the late reply.  You receive a message "access denied"?

    Try the steps listed by Srinivas KR

    http://answers.Microsoft.com/en-us/Windows/Forum/Windows_7-hardware/access-denied-Openning-Bluetooth-serial-port/3127e92e-57dB-4d27-A017-16a90a43e8c7

  • order by clause and index access

    Hi all

    I have tried under request.

    SELECT e.employee_id, e.department_id
    E EMPLOYEES
    order by 2;

    Implementation plan...

    SELECT STATEMENT, GOAL = ALL_ROWS 4 107 856
    SORT ORDER BY 4 107 856
    TABLE ACCESS FULL     EMPLOYEES OF HR 3 107 856

    Below query Oracle by using the INDEX FULL SCAN. I'm not able to find an appropriate explanation. Pls how me oracle optimizer include order by clause while to fetch documents.

    -departmentId has index EMP_DEPARTMENT_IX, which is the normal index.

    SELECT e.employee_id, e.department_id
    E EMPLOYEES
    order by 1;

    SELECT STATEMENT, GOAL = ALL_ROWS 3 107 856
    TABLE ACCESS BY INDEX ROWID HR 3 107 856
    INDEX FULL SCAN     HR EMP_EMP_ID_PK 1 107


    Thank you.

    Consolidation of the index factor is used by the CBO to calculate how much is a scan interval index (the one that is followed by a table-access by rowid) for this index will be. The CBO calculates this option to select an index if two or more paths index are available.
    But it could also be used to decide between choosing a full index scan (to honor an order by clause and without having to sort after the scan) in the course of a full table scan that requires an extra sort (in honor of the order by clause) operation.

    There are many articles talking about this:

    http://www.oaktable.NET/category/tags/clustering-factor

    http://Oracle-Randolf.blogspot.com/2010/01/clusteringfactor-what-if-analysis.html

    http://mehrajdba.WordPress.com/2009/02/09/index-clustering-factor/

    I just realized today that in case you described: If department_id column is NULL-able, Oracle cannot use the index in department_id to honor the order by clause, because he would find all the lines (those with an id of NULL service), in this case.

  • like clause and index access

    Hi all

    I went through the link below for the use of the index while using LIKE operator in SQL.
    [http://laurentschneider.com/wordpress/2009/07/how-to-tune-where-name-likebc.html]

    I tried the same approach in the Table Employees, but index not used.

    -There is a normal Index on the Job_id found: EMP_JOB_IX.

    SQL10.2 > select / * + INDEX (EMP_JOB_IX employees) * / e.job_id, e.first_name
    employees e where e.job_id like '%ABC% ';

    -Explain plan
    SELECT STATEMENT, GOAL = 3 5 80 ALL_ROWS
    TABLE ACCESS FULL 3 5 80 HR

    Pls know me why it's full table scan. (using version 10.2)

    Thank you

    you are the aliasing, try using the name of the table, but don't use do not alias to index...

    select /*+ INDEX(e ,EMP_JOB_IX)*/

    Ravi Kumar

  • the user switched on macbook air, cannot access serial number

    Due to some problems with my computer, I need to create another user on my MacBook Air. After that, I can't in my cloud of Adobe creative. He asked my serial number, which I can't seem to locate in previous emails or elsewhere.

    CC does not have a serial number, it uses your Adobe ID to validate registration

    Using this new user account...

    Your subscription to cloud shows correctly on your account page?

    https://www.adobe.com/account.html for subscriptions on your page from Adobe

    If you have more than one email, you will be sure that you use the right Adobe ID?

    .

    If Yes

    Sign out of your account of cloud... Restart your computer... Connect to your paid account of cloud

    -Connect using http://helpx.adobe.com/x-productkb/policy-pricing/account-password-sign-faq.html

    -http://helpx.adobe.com/creative-cloud/kb/sign-in-out-creative-cloud-desktop-app.html

    -http://helpx.adobe.com/x-productkb/policy-pricing/activation-network-issues.html

    -http://helpx.adobe.com/creative-suite/kb/trial--1-launch.html

    -ID help https://helpx.adobe.com/contact.html?step=ZNA_id-signing_stillNeedHelp

    -http://helpx.adobe.com/creative-cloud/kb/license-this-software.html

    .

    If no

    This is an open forum, Adobe support... you need Adobe personnel to help

    Adobe contact information - http://helpx.adobe.com/contact.html

    Chat/phone: Mon - Fri 05:00-19:00 (US Pacific Time)<=== note="" days="" and="">

    -Select your product and what you need help with

    -Click on the blue box "still need help? Contact us. "

  • Table slow access by index rowid

    Hi all
    10.2.0.1
    I have two queries that do the same thing but written in a different way.
    A quick index is scan and accesses the table with rowid, the other performs a full table scan.

    Partial TKPROF for query performing index scan Q_I:
    call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.01          0          0          2           0
Execute      1      0.00       0.00          0          0         13           0
Fetch        5      0.14       0.69         13      24252          0          53
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        7      0.15       0.70         13      24252         15          53

Misses in library cache during parse: 1

Rows     Row Source Operation
-------  ---------------------------------------------------
     53  SORT GROUP BY (cr=24252 pr=13 pw=0 time=692418 us)
   1103   HASH JOIN  (cr=24252 pr=13 pw=0 time=691345 us)
    222    TABLE ACCESS FULL HOD_USER (cr=5 pr=0 pw=0 time=42 us)
   1100    VIEW  (cr=24247 pr=13 pw=0 time=690198 us)
  1100     HASH GROUP BY (cr=24247 pr=13 pw=0 time=689097 us)
  36496      TABLE ACCESS BY INDEX ROWID DDO_ALT (cr=24247 pr=13 pw=0 time=109536 us)
  36496       INDEX FULL SCAN PK_DDOALT (cr=2226 pr=6 pw=0 time=36532 us)(object id 117105)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
     53   SORT (GROUP BY)
   1103    HASH JOIN
    222     TABLE ACCESS   MODE: ANALYZED (FULL) OF 'HOD_USER' (TABLE)
   1100     VIEW
   1100      HASH (GROUP BY)
  36496       TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF
                  'DDO_ALT' (TABLE)
  36496        INDEX   MODE: ANALYZED (FULL SCAN) OF 'PK_DDOALT'
                   (INDEX (UNIQUE))

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  db file sequential read                        13        0.09          0.55
  SQL*Net message from client                     5        0.00          0.00
    Query run TKProf full table SCAN Q_f:
    call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          4           0
Execute      1      0.00       0.00          0          0         13           0
Fetch        5      0.15       0.39         17       2023          0          53
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        7      0.15       0.40         17       2023         17          53

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS


Rows     Row Source Operation
-------  ---------------------------------------------------
     53  SORT GROUP BY NOSORT (cr=2023 pr=17 pw=0 time=398252 us)
    648   VIEW  (cr=2023 pr=17 pw=0 time=399497 us)
    648    SORT GROUP BY (cr=2023 pr=17 pw=0 time=398845 us)
  37537     HASH JOIN  (cr=2023 pr=17 pw=0 time=564274 us)
    222      TABLE ACCESS FULL HOD_USER (cr=5 pr=0 pw=0 time=267 us)
  36679      TABLE ACCESS FULL DDO_ALT (cr=2018 pr=17 pw=0 time=37 us)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
     53   SORT (GROUP BY NOSORT)
    648    VIEW
 648     SORT (GROUP BY)
  37537      HASH JOIN
    222       TABLE ACCESS   MODE: ANALYZED (FULL) OF 'HOD_USER'
                  (TABLE)
  36679       TABLE ACCESS   MODE: ANALYZED (FULL) OF 'DDO_ALT' (TABLE)



Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  db file sequential read                        15        0.06          0.18
  db file scattered read                          1        0.06          0.06
  SQL*Net message from client                     5        0.00          0.00
    Why 24247 complies for access by index rowid table, for access to the index, is 2226.
    Why the full table scan is faster in this case?

    Hisoka says:
    Why the full table scan is faster in this case?

    As P. Forstmann suggested, it would help if you can post queries and their results of EXPLAIN PLAN.
    Now, I know guess is bad, but I want to have a go on this one, so we'll see ;)
    My comments (in no particular order of relevance/importance)
    (1) you use a non patched (10.2.0.1) version which, I believe, is known to contain many bugs (and therefore can throw 'surprises')
    (2) the name of the index, it is clear that PK_DDOALT is a unique index (supporting the primary key constraint) table DDO_ALT so
    factor clustered index is (probably) not the issue.
    (3) the TkProf output tells 36496 lines are currently extracted from table DDO_ALT in the query that uses the index analysis while
    36679 lines are currently extracted a DDO_ALT table in the query that uses the full table scan.
    It seems that the DDO_ALT table has about 36679 lines. Now, it will be slower (such as oracle to access most of these lines using the index
    you will need to visit a (table) block at the same time (and will eventually visit same block several times) compared to the full table scan.
    who reads several blocks at a time (and eventually NOT have to visit same block several times). This can be confirmed
    by the numbers "cr" TkProf. 24247 consistent gets for the query using access indexed for 36496 lines (with the exception of consistent gets for the reading of the index)
    2018 coherent vs gets to access 36679 lines.
    (4) the operation "line Source" indicates that the query using an indexed access is written so that it forces the use of the index (most likely
    using an indicator of index). It's that reason optimizer uses "INDEX FULL SCAN" and not "INDEX RANGE SCAN". A FULL INDEX SCAN bed set
    structure of the index, a block at a time, which is not an efficient operation compared to the optimizer to choose naturally "INDEX RANGE SCAN", which
    that will show some of the index blocks.
    (5) Finally, it appears this query that uses access indexed, is written to 'say' oracle how to process the query. Maybe it's OK if you think that
    your knowledge of the data schemas is better than knowledge of the optimizer. But this certainly isn't the case here.
    Your queries are probably something like
    Query using index:

    SELECT 
FROM HOD_USER, (SELECT /*+ INDEX(DDO_ALT PK_DDOALT) */ 
                             FROM DDO_ALT
                            GROUP BY ) DD
WHERE HOD_USER. = DD.
GROUP BY 
ORDER BY

    The query using full table scan:

    SELECT 
 FROM (SELECT 
             FROM HOD_USER, DDO_ALT
          WHERE HOD_USER. = DDO_ALT.
             GROUP BY 
             ORDER BY )
GROUP BY 
ORDER BY

    Published by: user503699 on August 21, 2010 18:47 added ORDER BY clauses for both queries

  • 2 computers can simultaneously access ports separated on an ENET-232/4 module

    If I buy a NOR-ENET-232/4 series-to-ethernet adapter and plug it into a hub ethernet (or switch), 2 separate computers on the network simultaneously access serial ports as long as they don't try to access the same port?

    Hello Vince.

    See this article .

    Thank you

    Ryan

  • scan of the index systematic range

    Hello

    I read about the differences between the systematic index scan range, single scan, skip scan.

    According to the docs, to how the CBO Evaluates in-list of iterators, http://docs.oracle.com/cd/B10500_01/server.920/a96533/opt_ops.htm

    , I can see that

    "The IN -list iterator is used when a query contains a IN clause with values." The execution plan is the same which would result for a statement of equality clause instead of IN with the exception of an extra step. This step occurs when the IN -list iterator feeds section of equality with the unique values of the IN -list. »

    Of course, the doc is Oracle9i Database. (I do not find it in the docs of 11 g)

    And the example 2-1 list iterators initial statement, shows that is used in the INDEX RANGE SCAN.


    On my Oracle 11 GR 2 database, if I issue a statement similar to the example of the doc, so: select * from employees where employee_id in (7076, 7009, 7902), I see that it uses a SINGLE SCAN


    On Oracle Performance Tuning: the Index access methods: Oracle Tuning Tip #11: Unique Index Scan , I read that

    If Oracle should follow the Index Unique Scan, and then in SQL, equality operator (=) must be used. If any operator is used in other than op_Equality, then Oracle cannot impose this Unique Index Scan.

    (and I think this sentence is somewhere in the docs also).

    Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.

    Thank you.

    It is Internet... find us a lot of information a lot but don't know who to trust.

    Exactly! It is thought, you should ALWAYS have in the back of your mind when you visit ANY site (no matter the author), read a book or document, listen to no matter WHAT presentation or read responses from forum (that's me included).

    All sources of information can and will be errors, omissions and inaccuracies. An example which is used to illustrate a point can involve/suggest that it applies to the related points as well. It's just not possible to cover everything.

    Your post doc 9i is a good example. The earliest records (even 7.3 always available online docs) often have a LOT of better explanations and examples of basic concepts. One of the reasons is that there were not nearly that many advanced concepts that explaining necessary; they did not exist.

    michaelrozar17 just posted a link to a 12 c doc to refute my statement that the article you used was bad. No problem. Maybe this doc has been published because of these lines:

    The database performs a unique sweep when the following conditions apply:

    • A query predicate refers to all columns in a unique index using an equality operator key, such as WHERE prod_id=10 .
    • A SQL statement contains a predicate of equality on a column referenced in an index created with the CREATE UNIQUE INDEX statement.

    The authors mean that a single scan is ONLY performed for these conditions? We do not know. There could be several reasons that an INLIST ITERATOR has not been included in this list:

    1. a LIST is NOT for this use case (what michaelrozar might suggest)

    2. the authors were not aware that the CBO may also consider a unique analysis for a predicate INLIST

    3. the authors WERE aware but forgot to include INLIST in the document

    4. the authors were simply provide the conditions most common where a single sweep would be considered

    We have no way of knowing what was the real reason. This does not mean that the document is not reliable.

    In the other topic, I posted on the analysis of hard steps, site of BURLESON, and Jonathan contradicted me. If neither Burleson isn't reliable, do not know which author have sufficient credibility... of course, the two Burleson and Jonathan can say anything, it's true I can say anything, of course.

    If site X is false, site is fake, Z site is fake... all people should read the documentation only and not other sites?

    This is the BEST statement of reality to find the info I've seen displayed.

    No matter who is the author, and what credibility that they could rely on the spent items you should ALWAYS keep these statements you comes to mind.

    This means you need to do ' trust and verify. " You of 'trust', and then you "checked" and now have a conflict between WORDS and REALITY.

    On those which is correct. If your reality is correct, the documentation is wrong. Ok. If your reality is wrong, then you know why.

    Except that nobody has posted ANY REALITY that shows that your reality is wrong. IMHO, the reason for this is because the CBO probably MUCH, done a LOT of things that are not documented and that are never explored because there is never no reason to spend time exploring other than of curiosity.

    You have not presented ANY reason to think that you are really concerned that a single scan is used.

    Back to your original question:

    Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.

    1. why not use a single sweep?

    2. what you want Oracle to use instead? A full table scan? A scan of the index systematic range? An index skip scan? A Full Scan index? An analysis of index full?

    A full table scan?  For three key values? When there is a unique index? I hope not.

    A scan of the index systematic range? Look a the doc 12 c provided for those other types of indexes

    How the Index range scans work

    In general, the process is as follows:

    1. Read the root block.
    2. Read the bundle branch block.
    3. Replacing the following steps until all data is retrieved:

      1. Read a block of sheets to get a rowid.

      2. Read a block to retrieve a table row.

    . . .
    For example, to analyze the index, the database moves backward or forward through the pads of sheets. For example, an analysis of identifications between 20 and 40 locates the first sheet block that has the lowest value of key that is 20 or more. The analysis produced horizontally through the linked list nodes until it finds a value greater than 40 and then stops.

    If that '20' was the FIRST index value and the '40' was the LAST one who reads ALL of the terminal nodes. That doesn't look good for me.

    How to index full scans of work

    The database reads the root block and then sailed on the side of the index (right or left hand if do a descending full scan) until it reaches a block of sheets. The database then reads down the index, one block at a time, in a sorted order. The analysis uses single e/s rather than I/O diluvium.

    Which is about as the last example is not?

    How to index Fast Full Scans work

    The database uses diluvium I/O to read the root block and all the blocks of leaf and branch. Databases don't know branch blocks and the root and reads the index on blocks of leaves entries.

    Seems not much better than the last one for your use case.

    Skip index scans

    An index skip scan occurs when the first column of a composite index is "skipped" or not specified in the query.

    . . .

    How Index Skip scan work

    An index skip scan logically divides a composite index in smaller subindex. The number of distinct values in the main columns of the index determines the number of logical subindex. The more the number, the less logical subindex, the optimizer should create, and becomes the most effective analysis. The scan reads each logical index separately and "jumps" index blocks that do not meet the condition of filter on the column no leader.

    Which does not apply to your use cases; you do not have a composite index, and there is nothing to jump. If Oracle were to 'jump' between the values of the list in it would be still reads these blocks 'inbetween' and them to jump.

    Which brings back us to the using a single scan, one at a time, for each of the values in the list in. The root index block will be in the cache after the first value lies, so it only needs to be read once. After that just Oracle detects that the entry of only ONE necessary index. Sounds better than any other variants for me if you are only dealing with a small number of values in the IN clause.

  • Existing Dreamweaver cs6 serial number

    I want to reinstall my Adobe Dreamweaver CS6 on Windows 7, but I need to access serial number to use in the new facility. How to find the serial number for existing installation?

    Thank you.

    glennj_2015

    Check your Adobe account online.  The serial number should be there if you have registered the software when you initially installed.

    Quickly find your serial number

  • What is the right time to use the index with force?

    I have an EMPLOYEE table.  I join with the ROLE, and it has only about 200 distinct values on column EMPLOYEE. EMPLOYEE_TYPE_ID.

    Select / * + INDEX (an i_employee_type_id) * / b.SID as EMP_NAME, b.role_cd in the ROLE

    Of

    EMPLOYEE,

    B ROLE

    where

    a.EMPLOYEE_TYPE_ID = b.EMPLOYEE_TYPE_ID

    AND a.EFFECTIVE_END_TS > = systimestamp;

    Is it a good idea to use the index?  .. Or let the full table scan.

    SQL > select distinct EMPLOYEE_TYPE_ID of the EMPLOYEE;

    238 selected lines.

    If you don't know it will help not to use.

    Personally, I found several SQLs with index finger tips (written by programmers thinking index access is ALWAYS GOOD) end up harming performance. Oracle made a reading diluvium full table scan, single index reads as follows, according to the % of the returned array it is actually faster to do a full table scan. The optimizer did a great job to determine this.

    If you think there are cardinality estimation problems, and the optimizer expects a large number of lines when there are actually few being returned, in THIS case a suspicion was justified. Even so, in this case, I prefer that oracle manages the flag itself.

    You can do this by running the SQL tuning advisor. In fact, it will trigger the optimizer checks that the estimates are turned off and it will create a profile for you. (A profile is actually a stored set of advice that set the execution plan for you). If at the point where the underlying data changes significantly and profile ends up hurting performance, you do not need to touch the code like you would with manually added notes, you can just disable or delete the profile and let the optimizer re - analyze the statement.

    Concerning

    EDIT: In case of small tables, it is preferable to just cache the whole table in the POOL to KEEP and let oracle scan if necessary.

    Edit2: With the notable exception of index fast full scans, which are diluvium index readings. But they are only relevant when the request is quite satisfied by the index and has no need to visit the table.

  • Why the optimizer ignores Index Fast full Scan when much lower cost?

    Summary (tracking details below) - to improve the performance of a query on more than one table, I created an index on a table that included all the columns referenced in the query. With the new index in place the optimizer is still choosing a full Table Scan on an Index fast full scan. However, by removing the one query tables I reach the point where the optimizer suddenly use the Index Fast Full Scan on this table. And 'Yes', it's a lot cheaper than the full Table Scan it used before. By getting a test case, I was able to get the motion down to 4 tables with the optimizer still ignoring the index and table of 3, it will use the index.

    So why the optimizer not chooses the Index Fast Full Scan, if it is obvious that it is so much cheaper than a full Table Scan? And why the deletion of a table changes how the optimizer - I don't think that there is a problem with the number of join permutations (see below). The application is so simple that I can do, while remaining true to the original SQL application, and it still shows this reversal in the choice of access path. I can run the queries one after another, and he always uses a full Table Scan for the original query and Index fast full scan for the query that is modified with a table less.

    Watching trace 10053 output for the two motions, I can see that for the original query 4 table costs alone way of ACCESS of TABLE UNIQUE section a full Table Scan. But for the modified query with a table less, the table now has a cost for an Index fast full scan also. And the end of the join cost 10053 does not end with a message about exceeding the maximum number of permutations. So why the optimizer does not cost the IFFS for the first query, when it does for the second, nearly identical query?

    This is potentially a problem to do with OUTER joins, but why? The joins between the tables do not change when the single extra table is deleted.

    It's on 10.2.0.5 on Linux (Oracle Enterprise Linux). I did not define special settings I know. I see the same behavior on 10.2.0.4 32-bit on Windows (XP).

    Thank you
    John
    Blog of database Performance

    DETAILS
    I've reproduced the entire scenario via SQL scripts to create and populate the tables against which I can then run the queries. I've deliberately padded table so that the length of the average line of data generated is similar to that of the actual data. In this way the statistics should be similar on the number of blocks and so forth.

    System - uname - a
    Linux mysystem.localdomain 2.6.32-300.25.1.el5uek #1 SMP Tue May 15 19:55:52 EDT 2012 i686 i686 i386 GNU/Linux
    Database - v$ version
    Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
    Original query (complete table below details):
    SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
LEFT JOIN product_sub_type ON product.prod_sub_type_id = product_sub_type.prod_sub_type_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;
    Execution of display_cursor after the execution plan:
    SQL_ID  5ckbvabcmqzw7, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id LEFT JOIN product_sub_type ON product.prod_sub_type_id =
product_sub_type.prod_sub_type_id WHERE (         episode.department_id = 2 and
product.status = 'I'       ) ORDER BY episode.date_required

Plan hash value: 3976293091

-----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                     |       |       |       | 35357 (100)|          |
|   1 |  SORT ORDER BY        |                     | 33333 |  1920K|  2232K| 35357   (1)| 00:07:05 |
|   2 |   NESTED LOOPS OUTER  |                     | 33333 |  1920K|       | 34879   (1)| 00:06:59 |
|*  3 |    HASH JOIN OUTER    |                     | 33333 |  1822K|  1728K| 34878   (1)| 00:06:59 |
|*  4 |     HASH JOIN         |                     | 33333 |  1334K|       |   894   (1)| 00:00:11 |
|*  5 |      TABLE ACCESS FULL| PRODUCT             | 33333 |   423K|       |   103   (1)| 00:00:02 |
|*  6 |      TABLE ACCESS FULL| EPISODE             |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   7 |     TABLE ACCESS FULL | REQUEST             |  3989K|    57M|       | 28772   (1)| 00:05:46 |
|*  8 |    INDEX UNIQUE SCAN  | PK_PRODUCT_SUB_TYPE |     1 |     3 |       |  0   (0)|          |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   4 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   5 - filter("PRODUCT"."STATUS"='I')
   6 - filter("EPISODE"."DEPARTMENT_ID"=2)
   8 - access("PRODUCT"."PROD_SUB_TYPE_ID"="PRODUCT_SUB_TYPE"."PROD_SUB_TYPE_ID")
    Updated the Query:
    SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;
    Execution of display_cursor after the execution plan:
    SQL_ID  gbs74rgupupxz, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id WHERE (         episode.department_id = 2     and product.status =
'I'       ) ORDER BY episode.date_required

Plan hash value: 4250628916

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |             |       |       |       | 10515 (100)|          |
|   1 |  SORT ORDER BY         |             | 33333 |  1725K|  2112K| 10515   (1)| 00:02:07 |
|*  2 |   HASH JOIN OUTER      |             | 33333 |  1725K|  1632K| 10077   (1)| 00:02:01 |
|*  3 |    HASH JOIN           |             | 33333 |  1236K|       |   894   (1)| 00:00:11 |
|*  4 |     TABLE ACCESS FULL  | PRODUCT     | 33333 |   325K|       |   103   (1)| 00:00:02 |
|*  5 |     TABLE ACCESS FULL  | EPISODE     |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   6 |    INDEX FAST FULL SCAN| IX4_REQUEST |  3989K|    57M|       |  3976   (1)| 00:00:48 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   3 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   4 - filter("PRODUCT"."STATUS"='I')
   5 - filter("EPISODE"."DEPARTMENT_ID"=2)
    Creating the table and Population:
    1 create tables
    2. load data
    3 create indexes
    4. collection of statistics
    --
-- Main table
--
create table episode (
episode_id number (*,0),
department_id number (*,0),
date_required date,
cross_ref_id varchar2 (11),
padding varchar2 (80),
constraint pk_episode primary key (episode_id)
) ;
--
-- Product tables
--
create table product_type (
prod_type_id number (*,0),
code varchar2 (10),
binary_field number (*,0),
padding varchar2 (80),
constraint pk_product_type primary key (prod_type_id)
) ;
--
create table product_sub_type (
prod_sub_type_id number (*,0),
sub_type_name varchar2 (20),
units varchar2 (20),
padding varchar2 (80),
constraint pk_product_sub_type primary key (prod_sub_type_id)
) ;
--
create table product (
product_id number (*,0),
prod_type_id number (*,0),
prod_sub_type_id number (*,0),
episode_id number (*,0),
status varchar2 (1),
number_required number (*,0),
padding varchar2 (80),
constraint pk_product primary key (product_id),
constraint nn_product_episode check (episode_id is not null) 
) ;
alter table product add constraint fk_product 
foreign key (episode_id) references episode (episode_id) ;
alter table product add constraint fk_product_type 
foreign key (prod_type_id) references product_type (prod_type_id) ;
alter table product add constraint fk_prod_sub_type
foreign key (prod_sub_type_id) references product_sub_type (prod_sub_type_id) ;
--
-- Requests
--
create table request (
request_id number (*,0),
department_id number (*,0),
site_id number (*,0),
cross_ref_id varchar2 (11),
padding varchar2 (80),
padding2 varchar2 (80),
constraint pk_request primary key (request_id),
constraint nn_request_department check (department_id is not null),
constraint nn_request_site_id check (site_id is not null)
) ;
--
-- Activity & Users
--
create table activity (
activity_id number (*,0),
user_id number (*,0),
episode_id number (*,0),
request_id number (*,0), -- always NULL!
padding varchar2 (80),
constraint pk_activity primary key (activity_id)
) ;
alter table activity add constraint fk_activity_episode
foreign key (episode_id) references episode (episode_id) ;
alter table activity add constraint fk_activity_request
foreign key (request_id) references request (request_id) ;
--
create table app_users (
user_id number (*,0),
user_name varchar2 (20),
start_date date,
padding varchar2 (80),
constraint pk_users primary key (user_id)
) ;

prompt Loading episode ...
--
insert into episode
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 2,
    sysdate + mod (r, 14),
    to_char (r, '0000000000'),
    'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 300000
/
commit ;
--
prompt Loading product_type ...
--
insert into product_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000000'),
       mod (r, 2),
       'ABCDEFGHIJKLMNOPQRST' || to_char (r, '000000')
  from generator g
where g.r <= 12
/
commit ;
--
prompt Loading product_sub_type ...
--
insert into product_sub_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000'),
       to_char (mod (r, 3), '000000'),
       'ABCDE' || to_char (r, '000000')
  from generator g
where g.r <= 15
/
commit ;
--
prompt Loading product ...
--
-- product_id prod_type_id prod_sub_type_id episode_id padding 
insert into product
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, mod (r, 12) + 1, mod (r, 15) + 1, mod (r, 300000) + 1,
       decode (mod (r, 3), 0, 'I', 1, 'C', 2, 'X', 'U'),
       dbms_random.value (1, 100), NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading request ...
--
-- request_id department_id site_id cross_ref_id varchar2 (11) padding 
insert into request
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 4) + 1, 1, to_char (r, '0000000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890123456789' || to_char (r, '000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789012345678' || to_char (r, '000000')
  from generator g
where g.r <= 4000000
/
commit ;
--
prompt Loading activity ...
--
-- activity activity_id user_id episode_id request_id (NULL) padding 
insert into activity
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 50) + 1, mod (r, 300000) + 1, NULL, NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading app_users ...
--
-- app_users user_id user_name start_date padding 
insert into app_users
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, 
       'User_' || to_char (r, '000000'),
       sysdate - mod (r, 30),
       'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 1000
/
commit ;
--

prompt Episode (1)
create index ix1_episode_cross_ref on episode (cross_ref_id) ;
--
prompt Product (2)
create index ix1_product_episode on product (episode_id) ;
create index ix2_product_type on product (prod_type_id) ;
--
prompt Request (4)
create index ix1_request_site on request (site_id) ;
create index ix2_request_dept on request (department_id) ;
create index ix3_request_cross_ref on request (cross_ref_id) ;
-- The extra index on the referenced columns!!
create index ix4_request on request (cross_ref_id, site_id) ;
--
prompt Activity (2)
create index ix1_activity_episode on activity (episode_id) ;
create index ix2_activity_request on activity (request_id) ;
--
prompt Users (1)
create unique index ix1_users_name on app_users (user_name) ;
--
prompt Gather statistics on schema ...
--
exec dbms_stats.gather_schema_stats ('JB')
    10053 sections - original query
    ***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: TableScan
         Cost: 28806.24  Degree: 1  Resp: 28806.24  Card: 3994236.00  Bytes: 0
***************************************
    10053 - updated the Query
    ***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
  Access Path: index (index (FFS))
    Index: IX4_REQUEST
    resc_io: 3927.00  resc_cpu: 583211030
    ix_sel: 0.0000e+00  ix_sel_with_filters: 1
  Access Path: index (FFS)
    Cost:  3951.96  Resp: 3951.96  Degree: 1
      Cost_io: 3927.00  Cost_cpu: 583211030
      Resp_io: 3927.00  Resp_cpu: 583211030
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 1
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: IndexFFS  Index: IX4_REQUEST
         Cost: 3951.96  Degree: 1  Resp: 3951.96  Card: 3994236.00  Bytes: 0
***************************************

    I mentioned that it is a bug related to the ANSI SQL standard and transformation probably.

    As suggested/asked in my first reply:
    1. If you use a no_query_transformation then you should find that you get the use of the index (although not in the plan you would expect)
    2. If you use the traditional Oracle syntax, then you should not have the same problem.

  • Index BITMAP and NOT NULL

    Hi all
    Is it possible to use the Index BITMAP for a NOT NULL condition?


    >

    CREATE a BITMAP of INDEX x_ix FOR tab (x);

    SELECT *.
    TAB
    WHERE x IS NOT NULL

    >

    Thank you!

    user3646231 wrote:
    You say that :) to hope

    Here it is:

    Your test is a good effort - but it needs a little more.

    Your question is "is it possible...". «, not "If Oracle always...» »

    Your demonstration showed an example where the choice of plan Oracle has surprised you (and me). Now, you need run the query with index indicator (because if the indexed access path is legal, must be taken an indexed correctly suggested path).

    I just ran a similar test (1 line of 100,000), with the following results:

    SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
SQL_ID  52q6gxkscvg9v, child number 0
-------------------------------------
 select /*+ index(t1(n1)) */ * from t1 where n1 is not null

Plan hash value: 2828957992

----------------------------------------------------------------------
| Id  | Operation                    | Name  | Rows  | Bytes | Cost  |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |       |       |       |  1859 |
|   1 |  TABLE ACCESS BY INDEX ROWID | T1    |     1 |   118 |  1859 |
|   2 |   BITMAP CONVERSION TO ROWIDS|       |       |       |       |
|*  3 |    BITMAP INDEX FULL SCAN    | T1_N1 |       |       |       |
----------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("N1" IS NOT NULL)

    You will notice that the cost of the query is unreasonable - and without the suspicion my test showed Oracle taking the full analysis at a much lower cost.
    If your test has actually demonstrated a bug in the costing, explaining why Oracle does not automatically take a path that seems reasonable.

    The above output comes from 11.2.0.3, but I had the same thing with 11.1.0.7

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

  • normal index in oracle.

    I have a city_tbl with columns (city_cd, city_name, state_cd) in oracle 11 g release2
    city_cd is a primary key.
    I ran the query

    Select short-term in the city_tbl where state_cd = 'AL '.

    contact plan shows table scan complete

    now I create normal indexes on column state_cd

    After you run the query still explain plan shows table scan complete.

    After you create the index why there is full table scan?

    Hello

    Looks like the optimizer does the right thing by ignoring your index and by the full table scan. Table scan complete is a perfectly valid way of retrieving data and in many cases, is more effective than the index access, because a) uses readings diluvium b) doesn't have to go through the first index blocks before reading the data.

    In your case, the optimizer estimated the cost to read the table via a FTS at 34 monobloc readings. Access to index in your case is more expensive, because if it is quite cheap to acquire desired lines ROWID (only 2 readings are required), the desired table rows are scattered about 115 blocks, so Oracle will be 117 reads to retrieve data via an index.

    Of course, this is true if the optimizer is right in its assumptions about the size of the table, index, predicate selectivity structure and grouping factor. If this isn't the case, then you must find out where exactly the optimizer is not true and correct (for example, by collecting a histogram on the column in the WHERE clause).

    Best regards
    Nikolai

Maybe you are looking for

  • import bookmarks from mozilla to new computer

    Already transferred the files & folders of old laptop to new, but Firefox & associated bookmarks did not transfer. I downloaded Firefox on the new laptop computer, but impossible to find useful info on how to import bookmarks.

  • HP Pavilion HDX9280EL black screen

    Hello, I have a laptop HP Pavilion HDX 9280el that until last week worked, but after a few operations to remove the virus and also some updates from microsoft windows 7 64-bit, began to plant continuously, I tried to read as many post on this problem

  • Equium L40-10 X - cannot install Windows

    Hi all First post real but existed under and turned off for a while. I hope someone here can help! I have a Toshiba laptop Equium L40-10 x computer with a strange problem. He came me second user with the problem already so I don't know any history ot

  • HP Officejet Pro 8720: AirPrint works not the iPhone

    I've implemented a new Officejest of 8720 Pro. I have a mac and wireless printing works great! HOWEVER, when I try to use airprint on my ipad or iphone he says that does not find all printers!... I assured I'm on wifi even as the printer, etc... ever

  • Snapshots created with the EqualLogic VSS provider are not displayed in SAN HQ

    Hello Poster for the first time. We have just implemented an EqualLogic SAN, PS6100X network, and we're having performance issues between our DPM backup server, one of our hosts Hyper-V and VM images stored on the San. I will try to provide as much i