Query not using Full Scan Index

Hello world

I'm on 11.2.0.3.0 AIX 6.1.

There is a query such as:

Select: sys_b_0 | Count (distinct (column_name)) table;

that goes for the analysis full table. The column was values separate only 104 with not NULL values. To save memory buffer gets, I created an index on the table with the column used in the query (i.e. whose distinct values are recovered).

The problem is that even after the creation of indexes and force the flag index that it does not use the full scan of the index. The provided indication is correct in syntax and was the only clue in the query, so there is no question of conflicts with others.

Can anyone suggest me what I might be missing?

Thank you

It seems to me that if print_branch_code is defined as nullable in the table. If this is the case, the optimizer goes for a sweep of index, even if there is no real NULL values

Tags: Database

Similar Questions

  • query not given function function index in oracle 11g

    I have a query that uses function based indexes when run in oracle 9i, but when I run the same query
    without any change, it does not consider the index. This is the query:

    SELECT distinct patient_role.domain_key, patient_role.patient_role_key,
    patient_role.emergency_contact_name,
    patient_role.emergency_contact_phone, patient_role.emergency_contact_note,
    patient_role.emergency_contact_relation_id,
    patient_role.financial_class_desc_id, no_known_allergies, patient_role. CREATED_BY,
    patient_role. CREATED_TIMESTAMP,
    patient_role. CREATED_TIMESTAMP_TZ, patient_role. UPDATED_BY, patient_role. UPDATED_TIMESTAMP,
    patient_role. UPDATED_TIMESTAMP_TZ,
    patient_role.discontinued_date
    MEETING, patient_role
    WHERE patient_role.patient_role_key = encounter.patient_role_key
    AND SUPERIOR (TRIM (main: encounter.account_number SYS_B_0)) = UPPER (TRIM (main: SYS_B_1 of))
    ((: SYS_B_2))
    AND patient_role.discontinued_date IS null
    AND encounter.discontinued_date IS null;

    Definition of the index:

    CREATE INDEX "user1". "' IX_TRIM_ACCOUNT_NUMBER ' ON 'user1 '. MEETING"(AT THE TOP (TRIM (LEADING))
    ('0' TO 'ACCOUNT_NUMBER')), 'PATIENT_ROLE_KEY', 'DOMAIN_KEY', 'DISCONTINUED_DATE')
    PCTFREE, INITRANS 10 2 MAXTRANS 255 COMPUTE STATISTICS
    STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645)
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
    DEFAULT USER_TABLES)
    TABLESPACE "user1".

    Database: Oracle 11g (11.2.0.3)
    O / s: 64-bit Linux (the query does not consider the index even on the windows operating system)

    Any suggestions?

    -Onkar

    Published by: onkar.nath on July 2, 2012 15:32

    Onkar,

    I don't appreciate posting you this issue in several forums at the same time.
    If I know you also posted this on Asktom, I wouldn't even bother.
    As for your "problem":
    First of all: some kind cursor_sharing MUST have been implemented. Oracle is a predictable system, not a fruitmachine.
    Anyway, your statement that '0' is replaced by a variable binding is simply false. If you really believe this isn't fake, SUBMIT an SR.

    But your real problem isn't Oracle: it is your 'application', which is a mess anyway. Allowing for alphanumeric numbers is a very bad idea.
    Now, you already put workaround on workaround on workaround on workaround.
    Question is this: it is terminal, and you must either to kill him or to replace it.

    -------------
    Sybrand Bakker
    Senior Oracle DBA

  • explain query plan uses no unique index with where condition

    Hi all

    I use in the 10.2.0.5 oracle database Enterprise edition 64-bit on 64-bit windows server 2008.

    I'm following this tutorial on my own table

    Guide to understanding Oracle QUERY PLAN - 10 minutes

    my questions are below

    Analyze table LIB_CLASSIFICATIONS compute statistics;
explain plan for  SELECT class_id  FROM lib_classifications WHERE class_no = '538' ;
select * from table(dbms_xplan.display);

    the result is less than

    Hash value of plan: 3022072076

    -----------------------------------------------------------------------------------------

    | ID | Operation | Name                | Lines | Bytes | Cost (% CPU). Time |

    -----------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                     |     1.    10.     5 (0) | 00:00:01 |

    |*  1 |  TABLE ACCESS FULL | LIB_CLASSIFICATIONS |     1.    10.     5 (0) | 00:00:01 |

    -----------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - filter ("CLASS_NO" = '538')

    DESC LIB_CLASSIFICATIONS

    Name of Type Null

    ----------------- -------- -------------

    CLASS_ID NOT NULL NUMBER (10)

    CLASS_DESC VARCHAR2 (50)

    REMARKS VARCHAR2 (250)

    CLASS_NO VARCHAR2 (20)

    CLASS_TYPE VARCHAR2 (10)

    CREATE_USER VARCHAR2 (10)

    MODIFY_USER VARCHAR2 (10)

    CREATE_DATE DATE

    MODIFY_DATE DATE

    CLASS_CATEGORY_ID VARCHAR2 (10)

    class_id has a primary key.

    now when I remove the condition where the query, the result is lower;

    Analyze table LIB_CLASSIFICATIONS compute statistics;
explain plan for  SELECT class_id  FROM lib_classifications ;
select * from table(dbms_xplan.display);

    the result is less than

    Hash value of plan: 262704430

    ------------------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    ------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |             |  1558.  6232.     2 (0) | 00:00:01 |

    |   1.  FULL RESTRICTED INDEX SCAN FAST | SYS_C005653 |  1558.  6232.     2 (0) | 00:00:01 |

    ------------------------------------------------------------------------------------

    now it's using indexes with INDEX FAST FULL SCAN.

    I need the index using the WHERE condition as well.

    How to do this?

    Thank you.

    you have indexes on the column class_id not on class_no column how u would expect index to use when there is no index on the column class_no

  • Zoom of Safari do not using full window

    Is anyone else seeing this... in the last 2-3 days that some sites (but not all) behave as expected or desired in Safari when I "zoom". Previous behavior (what I want) is for the entire page in the window of the browser to expand I have to zoom (and vice versa when I Zoom out).

    Instead, the page seems to be divided into images and content within each vertical frame performs a zoom, but not the width of the frame itself. The result is that the zoom will not use all of the available window width.

    Image #1 is the default zoom HuffPost.

    Image #2 is after I zoomed in a few levels.

    Notice how the text in the 'frame' (with white background) Center got a lot bigger, but it doesn't have the framework. Zoom does not use the full width available to the window as she always did before. Note that the links-spills bar now off the frame to the right. Clearly a problem of rendering here.

    Software conflict maybe?

    MacOS 10.11.13

    Safari 9.0.3

    MacBook Pro with the retina

    Oops.   I found my problem.

    There is a new item on the menu display of Safari... at least, I have never noticed before... called 'zoom text only '.  Somehow, which was fixed. Disabling this feature allowed to zoom to behave as you wish.

    I'll leave this message upward in the other case travels through it also.

  • query not using the index for some user

    Hello

    I have a query that is running in less than a second for sys, system, or schema owner. However, another user (test_user) take 30 seconds to run the same query.

    I certainly dba and privileges identical to test_user as schmea_user, but the result is the same.

    I checked

    Select * from V$ SYS_OPTIMIZER_ENV;

    Both are the same for both users.

    I have check the plan to explain to both users. I noticed that for sys/system/schema_owner, the query uses an index, but not the test_user.

    All have experience the issue where a user uses an index, but not the other?

    Thank you for any assistance.

    Thank you for the display of formatting output, this output is much easier to read.

    One of the first things you notice about the execution plans that is for the owner non-schema "SQL_ID, 0wcs85uywn72m, number of children 1" appears in the output of DBMS_XPLAN, while "SQL_ID 0wcs85uywn72m, child number 0" (the same SQL_ID but a different number of child) appears for the schema owner. "" Whereas the SQL_ID is the same, which indicates that the client requires exactly the same SQL statement, so it's a good start.

    Then, note that in the predicate for the nonschema owner information section the following appears (sometimes with the order of the two conditions switched in position) as a condition placed on each table that is available in the schema:

    filter(("SEAL_FLAG" IS NULL OR "SEAL_FLAG"'Y'))

    The above suggests the presence of the virtual private database (or a superset of private database virtual) generated the predicates. You should be able to confirm that this is the case by querying V$ VPD_POLICY using the SQL_ID which was displayed in the DBMS_XPLAN output:

    SELECT
  *
FROM
  V$VPD_POLICY
WHERE
  SQL_ID='0wcs85uywn72m';

    As a test, I made a few minor adjustments to the example on this page:
    http://Antognini.ch/2011/09/optimizer_secure_view_merging-and-VPD/
    I changed the name of T to T12 and TESTUSER table specified for the schema names. I then created the function S of this page as follows:

    CREATE OR REPLACE FUNCTION s (schema IN VARCHAR2, tab IN VARCHAR2) RETURN VARCHAR2 AS
BEGIN
  RETURN 'ID < 10';
END;
/

    I then added a couple of lines in the T12 test table:

    INSERT INTO T12 VALUES (1,1,NULL);
INSERT INTO T12 VALUES (4,1,NULL);
INSERT INTO T12 VALUES (10,1,NULL);
INSERT INTO T12 VALUES (12,1,NULL);

COMMIT;

    With an active 10053 trace, I executed the following SQL statement:

    SELECT id, pad
  FROM t12
  WHERE
  spy(id, pad) = 1

    The SQL_ID (in my case, found in the 10053 trace file) was 6hqw5p9d8g8wf, so I checked V$ VPD_POLICY to this SQL_ID:

    SELECT
  *
FROM
  V$VPD_POLICY
WHERE
  SQL_ID='6hqw5p9d8g8wf';

ADDRESS          PARADDR            SQL_HASH SQL_ID        CHILD_NUMBER OBJECT_OWNER OBJECT_NAME                    POLICY_GROUP                   POLICY                 POLICY_FUNCTION_OWNER          PREDICATE
---------------- ---------------- ---------- ------------- ------------ ------------ ------------------------------ ------------------------------ ---------------------- ------------------------------ ------------------------------------------------------------------------------------
000007FFB7701608 000007FFB7743350 1518838670 6hqw5p9d8g8wf            0 TESTUSER     T12                            SYS_DEFAULT                    T_SEC                  TESTUSER                       ID < 10

    As noted above, the VPD test function named S added the predicate "ID".< 10"="" to="" the="" sql="">

    There are not many clues in the 10053 trace file in my test VPD generated additional predicates. Trace the following was found shortly after the beginning of the file (this is the SQL statement initially presented):

    ----- Current SQL Statement for this session (sql_id=6hqw5p9d8g8wf) -----
SELECT id, pad
  FROM t12
  WHERE
  spy(id, pad) = 1

    I searched then down in the trace for final after changes query file (to be noted that this sentence could be slightly different in different versions of database Oracle). That's what I found:

    Final query after transformations: ******* UNPARSED QUERY IS *******
SELECT "T12"."ID" "ID","T12"."PAD" "PAD" FROM "TESTUSER"."T12" "T12" WHERE "TESTUSER"."SPY"("T12"."ID","T12"."PAD")=1 AND "T12"."ID"<10
kkoqbc: optimizing query block SEL$F5BB74E1 (#0)

    Note that the final query after transformation shows how the final version of the query that has been rewritten by the query optimizer before the SQL statement has been executed and this version of the query includes AND "T12". "" IDENTITY CARD ".<10. if="" i="" was="" attempting="" to="" determine="" how="" that=""><10 predicate="" was="" added="" to="" the="" sql="" statement,="" i="" would="" start="" at="" the="" "current="" sql="" statement="" for"="" line="" in="" the="" trace="" file="" and="" search="" down="" the="" trace="" file="" for=""><10* -="" in="" this="" case,="" the="" following="" is="" what="" i="" found="" as="" the="" first="" search="" result,="" very="" close="" to="" the="" "current="" sql="" statement="" for"="" line="" in="" the="" trace="">

    **************************
Predicate Move-Around (PM)
**************************
PM:     PM bypassed: Outer query contains no views.
PM:     PM bypassed: Outer query contains no views.
query block SEL$F5BB74E1 (#0) unchanged
FPD: Considering simple filter push in query block SEL$F5BB74E1 (#0)
"TESTUSER"."SPY"("T12"."ID","T12"."PAD")=1 AND "T12"."ID"<10
try to generate transitive predicate from check constraints for query block SEL$F5BB74E1 (#0)
finally: "TESTUSER"."SPY"("T12"."ID","T12"."PAD")=1 AND "T12"."ID"<10

    As can be seen from the above (because the predicate again appeared before and after the line containing the word "Finally: '), the AND"T12 ". "" IDENTITY CARD ".<10 predicate="" was="" already="" added="" to="" the="" original="" sql="" statement="" by="" the="" time="" the="" predicate="" move-around="" section="" of="" the="" trace="" file="" was="" written,="" and="" that="" is="" the="" first="" mention="" of=""><10 in="" the="" trace="" file.="" in="" your="" case,="" you="" would="" search="" the="" 10053="" trace="" file="">

    "SEAL_FLAG" IS NULL

    If V$ VPD_POLICY revealed that there are virtual private database (VPD) generated predicates applied to the SQL statement, take a look at the following article in the Oracle documentation library:
    http://docs.Oracle.com/CD/B28359_01/network.111/B28531/VPD.htm

    This article lists the different points of view, who can be interviewed to learn more about the VPD rules which are in force in the schema. For example, with my SPV test:

    SELECT
  *
FROM
  ALL_POLICIES;

OBJECT_OWNER                   OBJECT_NAME                    POLICY_GROUP                  POLICY_NAME                    PF_OWNER                       PACKAGE                       FUNCTION                       SEL INS UPD DEL IDX CHK ENA STA POLICY_TYPE              LON
------------------------------ ------------------------------ ----------------------------- ------------------------------ ------------------------------ ----------------------------- ------------------------------ --- --- --- --- --- --- --- --- ------------------------ ---
TESTUSER                       T12                            SYS_DEFAULT                   T_SEC                          TESTUSER                       S                                                            YES YES YES YES NO  NO  YES NO  DYNAMIC                  NO

    He knows performance issues related to the use of VPD, some of which are Oracle Database version-dependent, and some have been fixed in recent versions. Take a look at the following articles if you have access to My Oracle Support:
    MetaLink (MOS) Doc ID 728292.1 ' known performance problems when you use transparent encryption data and indexes on the encrypted columns.
    MetaLink (MOS) Doc ID 967042.1 "How to investigate Query Performance regressions Caused by VPD (FGAC) predicates?"

    You might find working through the second of the above that the problem is caused by a bug in database Oracle.

    On a side note. Execution plans you have published include the 0 value in the column starts many of the operations in the execution plan. 0 indicates that the operation never actually executed. A 0 is included in the column starts on the line that includes the FULL ACCESS of TABLE of PEOPLE_TRANSACTIONS at least to the OPC. Value 123, a full table of PEOPLE_TRANSACTIONS table scan PROPERTY_CONTAINER_ID was not actually performed.

    Charles Hooper
    http://hoopercharles.WordPress.com/
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • Satellite A300 - 20 p - games with Windows 7 not working not not using full screen

    I have Satellite A300 - 20 p and VGA ATI 3650
    I did the upgrade to Windows 7 Professional

    All games works fine but not full screen. I installed the latest driver for ATI for Windows 7. He worked in full screen in Vista prior to upgrade.

    Same problem on my brother's cell phone after he made the upgrade to Windows 7.

    Hello

    Normally you can change the resolution of the screen in every game and if they should run full screen or not. Check this box!

    Can you also tell us what display driver you have installed? Pilots of the Toshiba page are for maps of office and not for mobile maps. So please only use the Toshiba drivers.

  • YouTube videos don't play don't not using full screen

    Updated to OS X 10.11.2 and now videos from YouTube DO NOT play in full screen. There is a problem with SAFARI and OS X. Works fine in other browsers, but I don't have to use 2 or more browsers to use my Macbook Pro.  I know put paused and resumed the game helps but is not a HOTFIX or Patch.

    Send feedback to Apple. They will not respond, but at least know that there is a problem. If enough people send feedback, it can become the problem solved as soon as possible.

    Your comments

    Or you can use your Apple ID to register on this site and go the Apple BugReporter. Allegedly, you will get a response if you submit your comments.

    Comments via Apple Developer

  • XPS 8700 RAM upgrade - do not use full capacity

    I decided to get max out my RAM on my XPS 8700 to 32 GB. After booting, I am only using one half of the total. I checked the system settings to see if there is something that needs to be defined, but I don't see anything that will help.

    Is there a material DIM switch or something of RAM is correctly adjusted? I looked in the user guide but cannot see how to swap the RAM modules.

    If you have windows 7 home, your authorized max is memory 16 GB.  If you have Pro, you can go up to 192 GB.  Windows 8 and higher increased the memory limit.

    If it does not, you may have some bad RAM.

  • Satellite Pro M40 does not using full RAM

    Hi all

    I have a Satellite Pro M40 which has a 512 band on board, but allocate only 448Mb.

    Any ideas?

    Dice

    Magic word is shared memory. Google a bit and you will find explanations of what it is and how it works.

    Can I just say one thing: Don t worry! Everything is ok.

    Good day!

  • Setting the query: optimizer does not use the index function

    Hello

    I have a request written by a developer that I can't change.

    It is here that the condition:

    OÙ (   UPPER(TRIM (CODFSC)) = UPPER (TRIM ( '01923980500'))

           OR UPPER(TRIM (CODUIC)) = UPPER (TRIM ( '01923980500')))

    There is an index on CODFSC and on CODUIC1.

    the plan is:

    Plan

    INSTRUCTION SELECT ALL_ROWS cost: 9 194 bytes: 3 206 502 cardinality: 15 054

    ACCESS FULL ANAGRAFICA cost TABLE TABLE 1: 9 194 bytes: 3 206 502 cardinality: 15 054

    So I created two new index on SUPERIOR (TRIM ()CODFSC)) and SUPERIOR (TRIM ()CODUIC)) but the plan

    complete analysis of STIL.

    Modifing where condition in:

    OÙ (   CODFSC = UPPER (TRIM ( '01923980500'))

           OR CODUIC = UPPER (TRIM ( '01923980500')))

    the plan is:

    SELECT STATEMENT ALL_ROWSCost: 157 bytes: 426 cardinality: 2

    CONCATENATION OF 5

    TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 2: cardinality of 5 bytes: 213: 1

    1 INDEX RANGE SCAN INDEX ANAGRAFICA_IDX01 cost: cardinality 3: 1

    TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 4: cardinality 152 bytes: 213: 1

    3 INDEX SKIP SCAN INDEX ANAGRAFICA_IDX02 cost: cardinality 1: 151

    Why optimizer not use my funct index?

    Thank you.

    Franck,

    I always forget that the default value for the GOLD expansion depends on a path indexed for each branch.

    2 in your use of or_predicates (2) depends on the position of complex predicate which must be expanded.  If you change the order of predicate 'State = 0' to display AFTER the complex predicate, you must change the indicator of "or_predicates (1).

    Outside of the current state of undocumented indicator, it also introduces the disturbing thought that, for a more complex query, a change in the transformation may result in another set of query blocks generated with a different ranking of the predicates. Yet another case to ensure that if you suggest anything suggest you (or create a SQL database).

    Concerning

    Jonathan Lewis

  • Reg - full scan limited index

    Hi Experts/gurus,
    I read Oracle http://docs.oracle.com/cd/B19306_01/server.102/b14211/optimops.htm#i52044 docs, i.e. the difference between the range index scans, full scan and full scan index restricts index. Here is the description of 'Fast Full Index Scans'

    Full index scans are an alternative to a full table scan when the index contains all the columns needed for the query, and at least one column in the index key has the NOT NULL constraint. A full scan accesses the data in the index itself, without access to the table. It can be used to eliminate a sort operation, because the data are not classified by the index key. It reads the entire index using multiblock bed, unlike a full index scan and can be parallelized.

    Therefore, the document says, the optimizer to choose index FFS, 'at least in the index key column a NOT NULL constraint', but I see less test cases is in complete contrast to what I've read.

    I created a table without constraints "NOT NULL".
    SQL> create table r_dummy(a number,b varchar2(10));

Table created.

SQL> insert into r_dummy select level,'hi' from dual connect by level<=20;

20 rows created.

SQL> commit;

Commit complete.

SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY');

PL/SQL procedure successfully completed.

SQL> select * from r_dummy where a <= 10;

         A B
---------- ----------
         1 hi
         2 hi
         3 hi
         4 hi
         5 hi
         6 hi
         7 hi
         8 hi
         9 hi
        10 hi

10 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2533004807

-----------------------------------------------------------------------------
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |         |    10 |    60 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| R_DUMMY |    10 |    60 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   1 - filter("A"<=10)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
        329  bytes sent via SQL*Net to client
        238  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         10  rows processed
    As expected under its weight "Full Table Scan", now if I have an index on columns (a, b), if my interpretation is correct, according to the docs, the optimizer should not do a "full Index scan", but Interestingly, it obeys the indication of index_ffs and did a full scan index
    SQL> create index r_dummy_idx on r_dummy(a,b);

Index created.

SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX');

PL/SQL procedure successfully completed.

SQL> select /*+index_ffs(r)*/ * from r_dummy r where a <= 10;

         A B
---------- ----------
         1 hi
         2 hi
         3 hi
         4 hi
         5 hi
         6 hi
         7 hi
         8 hi
         9 hi
        10 hi

10 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3219236618

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |    10 |    60 |     2   (0)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| R_DUMMY_IDX |    10 |    60 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

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

   1 - filter("A"<=10)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        330  bytes sent via SQL*Net to client
        238  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         10  rows processed
    This clearly shows the optimizer chooses 'INDEX FAST FULL SCAN' even though none of the indexed columns have 'NOT NULL' constraint.

    And there is another statement that talks about the results of the COMMAND.

    + "May not be used to eliminate a sort operation, because data are not classified by the index key ' +.

    He eliminated the sort operation, I see my results in ascending order.
    SQL> drop table r_dummy;

Table dropped.

SQL> create table r_Dummy(a number);

Table created.

SQL> insert into r_dummy values(10);

1 row created.

SQL> insert into r_dummy values(3);

1 row created.

SQL> insert into r_dummy values(1);

1 row created.

SQL> insert into r_dummy values(9);

1 row created.

SQL> insert into r_dummy values(5);

1 row created.

SQL> insert into r_dummy values(4);

1 row created.

SQL> insert into r_dummy values(2);

1 row created.

SQL> insert into r_dummy values(6);

1 row created.

SQL> insert into r_dummy values(7);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from r_dummy;

         A
----------
        10
         3
         1
         9
         5
         4
         2
         6
         7

9 rows selected.

SQL> create index r_dummy_idx on r_dummy(a);

Index created.

SQL> set autotrace on;
SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY');

PL/SQL procedure successfully completed.

SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX');

PL/SQL procedure successfully completed.
    Below you can see the results in ascending order.
    SQL> select /*+index_ffs(r)*/ * from r_dummy r where a<=10;

         A
----------
         1
         2
         3
         4
         5
         6
         7
         9
        10

9 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3219236618

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     9 |    27 |     2   (0)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| R_DUMMY_IDX |     9 |    27 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

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

   1 - filter("A"<=10)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        291  bytes sent via SQL*Net to client
        238  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          9  rows processed

SQL>
    I am not sure if the docs are wrong or I'm reading wrong. Please help / correct me if my interpretation is poor.

    RUSSO says:
    Nicosa salvation,
    First of all, thank you for your elaborate explanation.

    Nicosa wrote:
    Will rely on data to order no order by clause and your app will be one day or the other have a bug. + (which, in fact, will not one, as the app has been designed in this way!) +

    I don't really do this, I know that even in parallel the same query may return also rows without a prescription. But was surprised to see my results neatly on INDEX NORMAL (non-partitioned). However, I make sure that I have use 'order by' when I want my results to order.

    But still I'm not sure, how the absence of constraint column 'NOT NULL' in the index would stop optimizer to do a full scan limited index

    Oracle does not index lines where all coluumns in the index are null. So, in your first example it could be possible that there is a line wiith the two a and b null. Oracle could not return this line using an index full assessment because it would not be in the index. However, by adding a predicate on a indexed columns say you actually column is not null.

    In the table, that I used in my example above, all three columns are nullable. Take into account:

    SQL> select acctno, count(*) from pttrans
  2  group by acctno;

Execution Plan
----------------------------------------------------------
Plan hash value: 3294770776

--------------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |   532K|  6239K|       | 48143   (2)| 00:09:38 |
|   1 |  HASH GROUP BY     |         |   532K|  6239K|   107M| 48143   (2)| 00:09:38 |
|   2 |   TABLE ACCESS FULL| PTTRANS |  5081K|    58M|       | 37895   (1)| 00:07:35 |
--------------------------------------------------------------------------------------

SQL> select acctno, count(*) from pttrans
  2  where acctno is not null
  3  group by acctno;

Execution Plan
----------------------------------------------------------
Plan hash value: 3737827862

------------------------------------------------------------------------------------------
| Id  | Operation             | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |          |   532K|  6239K|       | 20641   (4)| 00:04:08 |
|   1 |  HASH GROUP BY        |          |   532K|  6239K|   107M| 20641   (4)| 00:04:08 |
|*  2 |   INDEX FAST FULL SCAN| PTTRANS1 |  5081K|    58M|       | 10393   (2)| 00:02:05 |
------------------------------------------------------------------------------------------

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

   2 - filter("ACCTNO" IS NOT NULL)

    The first query must examine acctno null to get the correct number, but the second, because I asked explicitly not null can use the index.

    John

  • SQL, not not using index on a partitioned table

    I partitioned table that has rows over 15 million
    I have a query that selects records based on the flag = 1
    There are only 2 possible values for the flag, it is 0 or 1
    I tried two index and local bitmap index on this field.
    The query always uses full table scan
    any suggestions?

    Assuming that you have an index

    CREATE INDEX idx_maint_chg_flag
   ON a_maintenance( CASE WHEN record_changed = 1 THEN 1 ELSE NULL END);

    your request would be

    SELECT *
  FROM a_maintenance
 WHERE (CASE WHEN record_changed = 1 THEN 1 ELSE NULL END) = 1

    Of course, it may be easier to follow if you create a function is_record_changed

    CREATE FUNCTION is_record_changed( p_flag NUMBER )
  RETURN NUMBER
IS
BEGIN
  IF( p_flag = 1 )
  THEN
    RETURN p_flag;
  ELSE
    RETURN NULL;
  END IF;
END;

    create an index on this function

    CREATE INDEX idx_maint_chg_flag
   ON a_maintenance( is_record_changed( record_changed ) );

    and use this function in your query

    SELECT *
  FROM a_maintenance
 WHERE is_record_changed( record_changed ) = 1

    Justin

  • FBI and XMLINDEX not use by the optimizer

    Hello

    I've created a function based index but optimizer is never using my index and found for BINARYXML FBI is not suggested rather THAN XMLINDEX is good, it seems does not work for me, but even.

    I tried to use tips but doesn't help me at all. Any suggestions would be really useful.

    SQL > show parameter index

    VALUE OF TYPE NAME
    ------------------------------------ ----------- ------------------------------
    optimizer_index_caching integer 0
    OPTIMIZER_INDEX_COST_ADJ integer 1
    optimizer_use_invisible_indexes boolean FALSE
    skip_unusable_indexes Boolean TRUE
    SQL >

    SQL > desc FXXX_SEC_POS_FB
    Name                                                                                  Null?    Type
    ------------------------------------------------------------------------------------- -------- ----------------------------------------------------------
    RECID A NOT NULL VARCHAR2 (255)
    XMLRECORD                                                                                      SYS. XMLTYPE BINARY STORAGE

    SQL >

    SQL * more: Production release 11.2.0.4.0 Wed Feb 11 06:34:39 2015

    Copyright (c) 1982, 2013, Oracle.  All rights reserved.


    Connected to:
    Oracle Database 11 g Enterprise Edition Release 11.2.0.4.0 - 64 bit Production
    With partitioning, OLAP, Data Mining and Real Application Testing options

    INDEX_NAME INDEX_TYPE VISIBILITY FUNCIDX_ DOMIDX_MANAGEM
    ------------------------------ --------------------------- --------- -------- --------------
    SYS_IL0000174507C00003$ $ LOB VISIBLE
    BASED ON A NORMAL VISIBLE ENABLED FUNCTION IX_FBNK_SEC_POS_FB_C2
    BASED ON A NORMAL VISIBLE ENABLED FUNCTION IX_FBNK_SEC_POS_FB_C81

    SELECT t.RECID FROM FBNK_SEC_POS_FB WHERE SECURITY_NUMBER = t'000566-000' and xmlexists ("$xmlrecvar/row [c81/text () ="US0010001"]' by the WAY ')

    XMLRECORD AS 'xmlrecvar')

    The higher the SQL statement execution Plan:

    Hash value of plan: 4259655978

    --------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |                 |   361K |   738 M |   197K (2) | 00:39:31 |
    |   1.  SEMI NESTED LOOPS.                 |   361K |   738 M |   197K (2) | 00:39:31 |
    |*  2 |   TABLE ACCESS FULL | FBNK_SEC_POS_FB |  4427 |  9247K |  75786 (1) | 00:15:10 |
    |*  3 |   XPATH EVALUATION.                 |       |       |            |          |
    --------------------------------------------------------------------------------------

    Name of the query block / Alias object (identified by the operation identity card):
    -------------------------------------------------------------

    1 SALT$ BCF67709
    2 SALT$ BCF67709 / T@SEL$1

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    2 - filter("SECURITY_NUMBER"='000566-000')
    3 - filter("P".") C_01$ "= 'US0010001')

    Projection of the column information (identified by the operation identity card):
    -----------------------------------------------------------

    1 (#keys = 0) "T". "RECID" [VARCHAR2, 255], "T" "." " SYS_NC00003$ '[LOB, 4000],
    "SECURITY_NUMBER" [VARCHAR2, 12]
    2 - « T ». "RECID" [VARCHAR2, 255], "T" "." " SYS_NC00003$ '[LOB, 4000],
    "SECURITY_NUMBER" [VARCHAR2, 12]
    3 VALUE (A0) [4000]

    Note
    -----
    -dynamic sample used for this survey (level = 2)
    LETTER: SQL: 2:Full: SELECT t.RECID FROM FBNK_SEC_POS_FB WHERE SECURITY_NUMBER = t'000566-000' and xmlexists (' $xmlrecvar/row [c81 / text ()])

    (= "US0010001"]' in PASSING XMLRECORD AS 'xmlrecvar')

    4096 selected records

    You probably won't see the difference in approach...

    I have NOT used and not STRUCTURED XML, but a STRUCTURED index rather XML index...

    • Index unstructured XML when introduced in 11.1 and use an ARRAY of path. Unstructured XML indexes are mainly used for research "blurred".
    • Structured XML indexes where introduced in 11.2 and make use of one or more TABLES of CONTENTS that contain, must contain content of the structured parts in the XML document

    So I have not used

    CREATE INDEX IX_FXXX_AAA_BBB_FB_FB
ON FXXX_AAA_BBB_FB (XMLRECORD)
INDEXTYPE IS XDB.XMLINDEX
PARAMETERS ('  PATH TABLE IX_PATH_TABLE
                PATHS (  INCLUDE ( /row/c2 /row/c81 ))'
            );

    but instead I used a XML structured, based on the function XMLTABLE index

    CREATE INDEX IX_FXXX_AAA_BBB_FB_FB
  ON FXXX_AAA_BBB_FB (XMLRECORD)
INDEXTYPE IS XDB.XMLINDEX
  PARAMETERS (q'# GROUP SXI_GROUP
                  XMLTABLE SXI_CONTENT_TABLE
                  '/row'
                  COLUMNS
                    C2  VARCHAR2(100)     PATH 'c2'
                  , C81 VARCHAR2(100)     PATH 'c81'
                #');

    On those, I also created EXTRA build secondary indexes on the columns of the TABLE CONTENT with the name 'SXI_CONTENT_TABLE '.

    create index SEC_FXXX_C2_FB on SXI_CONTENT_TABLE(C2);
create index SEC_FXXX_C81_FB on SXI_CONTENT_TABLE(C81);
create unique index SEC_FXXX_RIDC2C81_FB on SXI_CONTENT_TABLE(RID, C2, C81);

    ...

  • Regarding the use of the Index

    Hello

    I have some doubts about the index:

    1. What is the difference between the 2 index usage scenarios below:
    / * + index (an index_name) parallel (a, 4) * /.
    / * + parallel_index(a,index_name,4) * /.

    Are the same two these?

    2. What is scan limited index complete and full scan index?

    3. I have a table in the database and there a few indexes on some columns. How can I check if the index is Bitmap or B-Tree?


    Thank you
    AB

    1. What is the difference between the 2 index usage scenarios below:
    / * + index (an index_name) parallel (a, 4) * /.
    / * + parallel_index(a,index_name,4) * /.
    Are the same two these?

    No,
    First of all the two boards, use the index and the other to indicate to the optimizer to use 4 simultaneous servers to a parallel operation are

    The second is just an indication. He tells the optimizer to use 4 concurrent servers on partitioned indexes.

    2. What is scan limited index complete and full scan index?

    The full index scan simple block reads.
    Full Fast scan do multi block reads.

    3. I have a table in the database and there a few indexes on some columns. How can I check if the index is Bitmap or B-Tree?

    In user_ | all_dba_indexes. Index_type will be BITMAP or NORMAL

    Concerning
    Peter

    PS: Speaking of tips. This favorite, can answer most of these questions, much better that I can:
    http://www.Oracle.com/pls/db112/homepage

    Published by: Peter on March 26, 2013 13:47

  • Performance problem on the SQL query that does not use the primary key index

    Hello!

    I have some performance issues on a single SQL query (Oracle 10 g).
    I could solve the problem by using the INDEX indicator, but I would like to know WHY this is happening.

    * Tables *.
    create table jobs)
    ID number (5) not null,
    name varchar2 (100),
    primary key constraint Job_PK (id)
    )
    /
    -Record count: 298

    create table Comp)
    integer ID not null,
    name varchar2 (100),
    primary key constraint Comp_PK (id)
    )
    /
    -Record count: 193

    -Relation m: n
    create table JobComp)
    integer ID not null,
    id_job integer not null,
    id_comp integer not null,
    primary key constraint JobComp_PK (id),
    unique key constraint JobComp_UK (id_job, id_comp),
    Constraint JobComp_FK_Job foreign key (id_job) refers to Job (id),
    Constraint JobComp_FK_Comp foreign key (id_comp) makes reference Comp (id)
    )
    /
    create index JobComp_IX_Comp on JobComp (Cod_Comp)
    /
    create index JobComp_IX_Job on JobComp (Cod_Job)
    /
    -Record count: 6431

    * Ask *.

    When I run this query, the execution plan shows the index using (JobComp_PK and JobComp_IX_Comp).
    No problem.

    Select JobComp.*
    of JobComp
    Join jobs
    on Job.id = JobComp.id_job
    where JobComp.id_comp = 134
    /
    -runs in 0.20 sec

    But when I add the field 'name' of the work table the plan uses full access table to the table of work

    Select JobComp.*, Job.name
    of JobComp
    Join jobs
    on Job.id = JobComp.id_job
    where JobComp.id_comp = 134
    /
    -runs in the 2.70 dry

    With the help of the index

    Select / * + INDEX (Job Job_PK) * /.
    JobComp.*, Job.name
    of JobComp
    Join jobs
    on Job.id = JobComp.id_job
    where JobComp.id_comp = 134
    /
    -runs in 0.20 sec

    * Doubt *.

    This behavior is correct?

    PS. : I tried to recalculate the statistics, but nothing changes:

    analyze the job calculation table statistics.
    /
    change the statistical calculation of index Job_PK reconstruction;
    /
    Start
    dbms_utility.analyze_schema (sys_context ('userenv', 'current_schema'), 'CALCULATE');
    end;
    /

    [of]
    Gustavo Ehrhardt

    Gus.EHR wrote:
    Hello.
    I'm sorry for the plan unformatted.
    The execution time of the querys "without field name' and 'with the field name with suspicion" are equal.
    He has no problem caching, because I get the plans of the sequence different from the querys and repeated the performance. The result is always the same.

    I don't think that there is no problem with oracle crossing LOOP IMBRIQUEE to the HASH JOIN when you include the field name and this should be the expected behavior. But it seems that your WORKING table has a degree of parallelism set against what is causing the query to run in parallel (as JOB table is now available with full table scan, instead of indexed access earlier). It could be that the parallel execution is contributor to extra Runtime.
    (a) do you know why the degree of parallelism on the WORK table has been defined? Do you need it?

    You can see if the following query provides a better response time?

    select /*+ NOPARALLEL(JOB) */ JobComp.*, Job.Name
  from JobComp
  join Job
    on Job.id = JobComp.id_job
 where JobComp.id_comp = 134

Maybe you are looking for