non-unique index

Similar Questions

• When I change a column is a primary key the associated non-unique index to become unique?

  So basically I already tried this and it shows me that the associated index is not unique.

  create table employees2 in select * from employees;

  create index emp_idx on employees2 (employee_id);

  ALTER employees2 table add primary key (employe_id) using index emp_idx;

  Select * from user_indexes where index-name = "EMP_IDX";

  I was wondering if I right assuming that when you change a column to a primary key or unique while using a given index that does not have the respective index become unique.

  The textbooks I use are sometimes a little hard to understand because of the wording, also, I want to just ask someone with a little more experience than me.

  Thank you.

  your test did give the correct answer: the index is not unique if it serves to bear a unique or primary key constraint. Indeed, it is one of the benefits of the use of no unique indexes in support of UK/PK constraints (since it allows to set the unusable index before to make bulk loads; and, of course, they have also some disadvantages - for example, they need an additional logical reading to reach a line). Richard Foote explains the details in https://richardfoote.wordpress.com/2008/06/04/primary-keys-and-non-unique-indexes-whats-really-happening/ (and other items).

• Unique and non-unique indexes

  
  Hello

  I have a unique index associated with no doubt. Unique and not unique indexes are used B tree architecture. But I want to know if I create a non-unique index on a column that contains unique data.

  When I query this table using this column, it scans each sheet or times found that value it scan stops and give us the result?

  00125 wrote:

  In a non-unique index, scans all the leaves... so what's the difference between full table scan and index ull. I went through a few articles they mentioned that a non-unique index to check with rowid. How she treated? I have clear knowledge in it.

  Please help me with this.

  Thanks in advance

  If you go through architecture index B-tree you could easily understand how indexing works. The picture here shows how a look of column datatype NUMBER indexed as / stored internally. You can imagine that your indexed column TST_COLA this will look like in the internal process. In the B-tree indexes, you have 3 main structures 1. 2 root. Branch 3. Leaves and the database retrieves lines by browsing through the root of index-> branch-> leaves. If the photo if we wanted to retrieve the row whose value indexed column = 25. First data goes to the root and finds that plugs is set to 25, then he Stoops to this particular branch of find what block sheet retains the value 25. More far away after finding the leaves block then goes to this block of sheets and research the special value of 25.

  If the index is UNIQUE, the database knows that there must be only one value, where it performs INDEX UNIQUE SCAN. If the index is NOT UNIQUE it should check all values in this block of leaves to find who all are 25 - in this case INDEX RANGE SCAN is done - as you must check not only value, but all values in this block of sheets - given that the values are not unique. As you can see it that the sheet block contains the long side of the value of the column ROWID, using this database rowid, then goes to the table to retrieve that particular line.

  Full table scan is a method of access where the database just to access the table directly (bypassing index structure) and analyze the ENTIRE table to satisfy the request.

• Accompanied by primary key to a non-unique index?

  Met a weird situation today. A utility, we set up which allows analysts to restore the data in their paintings, started failed when it attempted to drop an index. The index supported a primary key. Makes sense. But our script was supposed to be only an attempt to drop/recreate the nonunique indexes. It turns out that supported on the primary key index was not unique and to the best of my knowledge has emerged as follows:
  

  SQL> create table junk (f number(1));
  
  Table created.
  
  SQL> create index junk_ix on junk(f);
  
  Index created.
  
  SQL> select UNIQUENESS from DBA_INDEXES where index_name = 'JUNK_IX';
  
  UNIQUENES
  ---------
  NONUNIQUE
  
  SQL> alter table forbesc.junk add constraint junk_pk primary key (f) using index junk_ix;
  
  Table altered.
  
  SQL> select UNIQUENESS from DBA_INDEXES where index_name = 'JUNK_IX';
  
  UNIQUENES
  ---------
  NONUNIQUE
  
  SQL> insert into junk values (1);
  
  1 row created.
  
  SQL> insert into junk values (1);
  insert into junk values (1)
  *
  ERROR at line 1:
  ORA-00001: unique constraint (FORBESC.JUNK_PK) violated
  
  
  SQL> select index_name from dba_constraints where constraint_name = 'JUNK_PK';
  
  INDEX_NAME
  ------------------------------
  JUNK_IX

  What I can't understand, is how an index is not unique is to apply oneness. I thought it was the key to this process. I thought that perhaps an index with the 'SYS_123456' has be created, perhaps, but I couldn't find a:
  

  SQL> select object_name, object_type from dba_objects order by created desc;
  
  
  OBJECT_NAME   OBJECT_TYPE
  -------------------------------------------     
  JUNK_IX     INDEX
  JUNK     TABLE
  ...

  How the uniqueness is get applied in this case? It comes in Oracle 11.1.0.7
  
  Thank you
  -= Chuck

  It has always been like that. Oracle can and will use a non-unique index to apply a constraint to PK, the existing index just needs to have the columns PK as the leader or the columns in the index:

  SQL> create table t (id number, id1 number, descr varchar2(10));
  
  Table created.
  
  SQL> create index t_ids on t(id, id1);
  
  Index created.
  
  SQL> select index_name from user_indexes
    2  where table_name = 'T';
  
  INDEX_NAME
  ------------------------------
  T_IDS
  
  SQL> alter table t add constraint t_pk
    2  primary key (id);
  
  Table altered.
  
  SQL> select index_name from user_indexes
    2  where table_name = 'T';
  
  INDEX_NAME
  ------------------------------
  T_IDS
  
  SQL> insert into t values (1, 1, 'One');
  
  1 row created.
  
  SQL> insert into t values (1, 2, 'Two');
  insert into t values (1, 2, 'Two')
  *
  ERROR at line 1:
  ORA-00001: unique constraint (OPS$ORACLE.T_PK) violated
  

  John

• UNIQUE compared to a NON-UNIQUE INDEX

  Hello SQL gurus.
  
  Can you tell me the difference between UNIQUE and NON-UNIQUE index?
  
  Thank you
  Dave

  The fact that a UNIQUE index will not allow duplicate values in the columns in Index key so that NO SINGLE index will allow duplicates.

  If I CREATE an INDEX UNIQUE MY_TABLE_UK ON MY_TABLE (NAME_COLUMN);

  I can't insert the value "HEMANT" twice in the NAME_COLUMN.

  If I CREATE INDEX MY_TABLE_IDX ON MY_TABLE (NAME_COLUMN);

  I can "HEMANT" insert multiple lines.

  NOTE: If I insert NULL values, a UNIQUE INDEX will allow several NULL values as, by definition "NULL! = NULL ". However, a definition of primary key does not allow nulls.

• sizes of compressed index (unique vs. non-unique)

  Hello

  I wonder if anyone can shed any light on what is happening internally in an index which explains the behavior I see when you do the compression tests. It's all about 11.2.0.3.8 on SLES11.

  I have a simple table with about 12 columns, the initial size is 48 GB, I have that compress with compression OLTP and it comes down to 18 GB - that everything is perfect

  The table has 4 clues in this respect everything I can rebuild with the option 'compress' (i.e. just old style compression - there is no advanced for the index compression) - and I see a strange behavior. I took just a hint an example here:

  It's the creation command to original index - which creates an index of 14 GB

  CREATE INDEXES 'RESET_INDEX' ON 'RESET' ('INS_NUM', 'PARAM_SEQ_NUM', 'PARAM_RESET_HEADER_SEQ_NUM', 'RESET_SEQ_NUM');

  If I run the present

  CREATE INDEXES 'RESET_INDEX' ON THE COMPRESS OF 'RESET' ('PARAM_SEQ_NUM', 'PARAM_RESET_HEADER_SEQ_NUM', 'INS_NUM', 'RESET_SEQ_NUM');

  In fact, the index grows - it becomes 18 GB (because of the many column values that are only 1 or 0 according to me that end by expands when compression is enabled)

  However - and this is the bit that confuses me

  CREATE AN INDEX UNIQUE 'RESET_INDEX' ON THE COMPRESS OF 'RESET' ('PARAM_SEQ_NUM', 'PARAM_RESET_HEADER_SEQ_NUM', 'INS_NUM', 'RESET_SEQ_NUM');

  By adding the 'unique' keyword, index is massively more small-, now only 8 GB!

  What is happening here - when an index is unique fact that somehow ID stored inside it must also be compressed where, in a non-unique index, this is not possible?

  Which seems very strange - but the question - if I add a surrogate key column to a table and add it to all my index finger and make it unique as all my index finger will then get more small when compressed...?

  See you soon,.

  Rich

  The response of a Word is not.

  The explanation lies in what happens in the article published in the 2 'compress' on the unique index producing an error.

  For an index not unique 'compress' with no count of column means 'compress n', where n is the number of columns in the index. for an index unique 'compress' means "compress n - 1".

  Your "change to single" index gets smaller on the compression, because it shows duplicates on the first 3 columns (of 4).

  Concerning

  Jonathan Lewis

• Transform a no Unique Index in a single index

  Hello

  Version: 11.2.0.4.0 Enterprise Edition

  We got a non-unique Index for a primary key constraint. I would like to change that in a unique index. I know that you can not change the index to change. Is the only way to disable the primary key, delete the index and re-enable the constraint or is there a better solution? It is a 24/7 platform.

  sql_colder

  Windows service exist for a reason.

  You can also create clues online in an operational database.

  There is no other method outside the use of DBMS_REDEFINITION.

  Think about it: what is the business case to change the index?

  -----------

  Sybrand Bakker

  Senior Oracle DBA

• unique index on flow error

  Hi gurus,
  
  One of my work in ODI 10.1.3.5 fails to step: create a unique index on the flow table
  and
  throw this error: ORA-02158: invalid CREATE INDEX option
  
  in previous places of employment, he executed successfully but now his failure to get...
  
  I'm looking:
  
  1. What can be the reason of this failure.
  2. can I I skip this step by changing a setting in the flow control tab / (without checking the step by IKM (ignoring the error) - as he will ignore the other packages using the same IKM)
  3. the used IKM is the INCREMENTAL of the IKM ORACLE.
  
  Thank you
  Ravi

  Hi Ravi,

  I'll try to help you.

  1. What can be the reason of this failure.

  ODI will create a non-unique index running based on the PK (primary key) defined in the target data store. So, it could be because some invalid CREATE INDEX option is shown in the flow tab.

  2. can I I skip this step by changing a setting in the flow control tab / (without checking the step by IKM (ignoring the error) - as he will ignore the other packages using the same IKM)

  Better, the flow tab, you can do FLOW_TABLE_OPTION of virgins and try.

  3. the used IKM is the INCREMENTAL of the IKM ORACLE.

  Should be good.

  Thank you
  Guru

• a unique index or unique constraint on the issue of view Matt

  10.2.0.3
  
  I have an OLTP table and a matte view to fast refresh of the table in the warehouse. I have unique indexes on the matte view just as I have on the OLTP table. Of course, it's a bad idea because the updating Oracle on mattress views mechanism does not apply to the dml in the same order that it occurred on the side of OLTP? Should I get rid of all the unique indexes on views mattress in my warehouse and create regular index because of their unique nature will just happen because the side OLTP has a unique index? What will be the impact on the performance of the queries? Here's the alert log...
  
  Journal of owp2 alerts
  =======================
  ORA-12012: error on auto work 1595
  ORA-12008: error path refresh materialized view
  ORA-00001: unique constraint (SMS_AR. IU02_ROUTE_REF_MRKR) violated
  ORA-06512: at "SYS." DBMS_SNAPSHOT", line 510
  ORA-06512: at line 1
  ORA-00001: unique constraint (SMS_AR. IU02_ROUTE_REF_MRKR) violated
  ORA-00610: internal error Code
  ORA-12012: error on auto work 260282
  ORA-30439: updating of the ' ORA-30439: updating of the 'SMS_AR MV_ROUTE_REF_MRKR' failed due to the ORA-12008: error in the path of refresh materialized view
  ORA-00001: unique constraint (SMS_AR. IU02_ROUTE_REF_MRKR) violated
  ORA-06512: at "SYS." DBMS_SNAPSHOT", line 2254
  ORA-06512: at "SYS." DBMS_SNAPSHOT", line 2460
  ORA-06512: at "SYS." DBMS_SNAPSHOT", line 2429
  ORA-06512: at "SMS_AR.PA_PIES_WAREHOUSE", line 44
  ORA-06512: at line 2
  ORA-20000: index 'SMS_AR '. "' I01_MV_PIES_INV_REFMKR ' or the partition of this index is unusable

  Mark Reichman wrote:
  I think that this problem is resolved... Unless someone has something else to add. I have not tried yet... But it seems to be valid. I did a test and a unique constraint can be delayed in fact creates a non-unique index. So I need to remove my unique index on my matte view and create unique constraints can be delayed.

  Or...

  forget the unqiue part and simply change the indexes not unique because the main table has a unique index and guarantees uniqueness for me and the matte view will simply copy whats in the main table.

  Mark,

  the solution seems reasonable. Just a note: If you use a "reportable" unique constraint Oracle ignores any attempt to perform a direct-path insert of access and still stations conventional insert generating undo and many more again.

  As long as you do only a 'rapid' refresh, it should not matter, but in case you deal with refreshs full large MVs, this could make a difference when running not atomic refreshs (who can take advantage of the direct-path inserts / DML etc. at the same time)...

  Then you can consider using only non-unique index rather than the constraint may be delayed if performance can matter and given the fact that you should never see duplicates in the MV because of the constraint on the base table.

  Furthermore, you can use a non-unique index to apply a not reportable unique/primary key constraint as well, it is supported. You just need to create the index yourself before you set the constraint or using explicit syntax "CREATE INDEX" of the constraint clause.

  For more information, I wrote a note on this problem "may be deferred" some time ago:

  http://Oracle-Randolf.blogspot.com/2008/07/Deferrable-constraints-and-direct-path.html

  Kind regards
  Randolf

  Oracle related blog stuff:
  http://Oracle-Randolf.blogspot.com/

  SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
  http://www.sqltools-plusplus.org:7676 /.
  http://sourceforge.NET/projects/SQLT-pp/

• Why choose wrong explain plan when there is a unique index

  SQL > create table test in select * from dba_objects;
  
  Table created.
  
  SQL > create table test1 in select * from user_objects;
  
  Table created.
  
  SQL > create index unique i_test_1 on test (object_id);
  
  The index is created.
  
  SQL > exec dbms_stats.gather_table_stats (user, 'TEST');
  
  PL/SQL procedure successfully completed.
  
  SQL > exec dbms_stats.gather_table_stats (user, 'TEST1');
  
  PL/SQL procedure successfully completed.
  
  SQL > set autot trace
  SQL > select test1.* from test, test1 where test.object_id = test1.object_id;
  
  23037 selected lines.
  
  
  Execution plan
  ----------------------------------------------------------
  Hash value of plan: 3995284093
  
  -------------------------------------------------------------------------------
  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
  -------------------------------------------------------------------------------
  | 0 | SELECT STATEMENT | 23038 | 2114K | 77 (12) | 00:00:01 |
  | 1. NESTED LOOPS | 23038 | 2114K | 77 (12) | 00:00:01 |
  | 2. TABLE ACCESS FULL | TEST1 | 23038 | 2002K | 70 (3) | 00:00:01 |
  |* 3 | INDEX UNIQUE SCAN | I_TEST_1 | 1. 5. 0 (0) | 00:00:01 |
  -------------------------------------------------------------------------------
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  3 - access("TEST".") OBJECT_ID '= 'TEST1'.' OBJECT_ID')
  
  
  Statistics
  ----------------------------------------------------------
  494 recursive calls
  0 db block Gets
  26457 consistent gets
  0 physical reads
  0 redo size
  1090589 bytes sent via SQL * Net to client
  17270 bytes received via SQL * Net from client
  1537 SQL * Net back and forth to and from the client
  5 kinds (memory)
  0 sorts (disk)
  23037 rows processed
  
  
  SQL > drop index i_test_1;
  
  The index is deleted.
  
  SQL > create index i_test_1 on test (object_id);
  
  The index is created.
  
  SQL > set autot trace
  SQL > select test1.* from test, test1 where test.object_id = test1.object_id;
  
  23037 selected lines.
  
  
  Execution plan
  ----------------------------------------------------------
  Hash value of plan: 845425162
  
  --------------------------------------------------------------------------------
  --
  
  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time
  |
  
  --------------------------------------------------------------------------------
  --
  
  | 0 | SELECT STATEMENT | 23038 | 2114K | 99 (6) | 00:00:02
  |
  
  |* 1 | HASH JOIN | 23038 | 2114K | 99 (6) | 00:00:02
  |
  
  | 2. FULL RESTRICTED INDEX SCAN FAST | I_TEST_1 | 49887 | 243K | 27 (4) | 00:00:01
  |
  
  | 3. TABLE ACCESS FULL | TEST1 | 23038 | 2002K | 70 (3) | 00:00:01
  |
  
  --------------------------------------------------------------------------------
  --
  
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  1 - access("TEST".") OBJECT_ID '= 'TEST1'.' OBJECT_ID')
  
  
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block Gets
  1936 complies
  411 physical reads
  0 redo size
  1090589 bytes sent via SQL * Net to client
  17270 bytes received via SQL * Net from client
  1537 SQL * Net back and forth to and from the client
  0 sorts (memory)
  0 sorts (disk)
  23037 rows processed
  
  I think the hash join is the real plan, why choose nest loop where there is a unique index.

  Jinyu wrote:
  I think that thought cbo cost single scan index is 0, so loop nest is less expensive than the hash join, but I do not know why here costs 0

  Jinyu,

  You are right - in a nested loop, the CBO gives unique access by unique index value slightly cheaper than the same access by a non-unique index--essentially subtracting 1 of the normal cost.

  It is one of the reasons why you only need to create a no unique index to support a unique constraint, if you have a very good reason - if you modify a unique index that is not unique, change of costs and execution of some paths may change.

  Concerning
  Jonathan Lewis

• Index on non unique values in order to avoid the full table scan

  I have a table with > 100 k records. The table is updated only during the race every night. All columns except one have non - unique values and I am querying the table with this request.
  
  COL3 - non - unique values - only 40 distinct values
  unique values - no - COL4 - 1000 distinct values
  last_column - 100 k unique values
  
  Select last_column in the table_name where in (...) col3 or col4 (...)
  
  I tried to create a Bitmap index individually on col3 and col4 and also combined. However, in both cases, it performs a full table scan.
  
  Please, help me optimize this query as it is used in the term altogether the system and the cost of the query is very high around 650.
  
  I don't have much experience with popular indexes then all tracks.
  
  Thank you
  Sensey
  
  Published by: user13312817 on November 7, 2011 11:32

  An alternative might be to use a union instead and the 2 index:

  create index my_index1 on my_table (col3, last_column) compress 1;
  create index my_index2 on my_table (col4, last_column) compress 1;

  Select last_column from my_table
  where col3 in (...)
  Union
  Select last_column from my_table
  where col4 (...)

  In other words, if the UNION would apply here whereas in double values for last_column will be deleted.

• When we use a unique index for PK?

  I was reading this part of the manual oracle:

  http://docs.Oracle.com/CD/B28359_01/server.111/b28310/indexes003.htm#ADMIN11727

  I got confused because I was trying to research why sometimes, we want to create a primary key by using a unique index.

  CREATE A UNIQUE MYTABLE_PK ON MYTABLE INDEX

  (START_DT, ANNUAL)

  LOGGING

  TABLESPACE TBS_INDEX01

  NOPARALLEL;

  ALTER TABLE MYTABLE ADD)

  CONSTRAINT MYTABLE_PK

  KEY ELEMENTARY SCHOOL

  (START_DT, ANNUAL)

  WITH THE HELP OF INDEX MYTABLE_PK);

  And sometimes we simply create the primary key without using a unique index.

  ALTER TABLE MYTABLE ADD)

  CONSTRAINT PK_MYTABLE

  KEY ELEMENTARY SCHOOL

  (START_DT, ANNUAL)

  THE HELP INDEX);

  When we use a unique index for PK?

  James, you have returned to the question thread.

  I apologize: I'm sorry, user8875620, your son has been hijacked. A UK or PK constraint needs an index. You can create a (unique or non-unique) explicitly, or you can let Uncle Oracle create it implicitly when you define the constraint.

• Collections [PL/SQL] table with a unique index

  Hello
  
  Is it possible to create a table with a unique index collection?
  
  example:
  
  declare
  type tabletype is the table of non-null number IN directory INDEXES;
  tabletype_nummer tabletype;
  Start
  tabletype_nummer (1): = 1;
  tabletype_nummer (2): = 2;
  tabletype_nummer (3): = 2;
  end;
  
  2nd and 3rd index have the same value.
  so he could not fill the index 3.
  
  Thank you.
  Ludo
  
  Published by: Ludock on December 10, 2009 11:36
  The unique index should be the value.

  Yes, he is not required to start the index within the collection of 1... regardless of the number...
  Here put your index to the collection and the value of the collection as even... so you can launch it from 12 to...
  Him even when modified a bit

  DECLARE
  type tabletype
  IS
    TABLE OF NUMBER NOT NULL INDEX BY BINARY_INTEGER;
    tabletype_nummer tabletype;
    v_num  NUMBER;
    v_num1 NUMBER;
  BEGIN
    v_num                   := 12;
    tabletype_nummer(v_num) := v_num;
    v_num                   := 2;
    tabletype_nummer(v_num) := v_num;
    v_num                   := 2;
    tabletype_nummer(v_num) := v_num;
    v_num                   :=5;
    tabletype_nummer(v_num) := v_num;
    v_num1                  :=tabletype_nummer.First;
  
    WHILE v_num1            IS NOT NULL
    LOOP
      dbms_output.put_line(v_num1);
      v_num1 := tabletype_nummer.Next(v_num1);
    END LOOP;
  END;
  

  I assigned collection it beginning with 12 and next 2 I assigned twice and 5 next time... So now, if you check the o/p, you will get 2,5,12 which are distinct values, you want to store in the collection.

  Ravi Kumar

• creating a unique index of instaed of using the primary key index

  Hello
  
  I heard in a debate sometimes it is better to create a unique index on a column and use it instead of using the primary key index in oracle. I did not understand what that the reason propely.
  
  Can someone please help me in this topic if it is valid.
  
  Thanks in advance

  On the surface, which does not seem reasonable... Volume of the DML is irrelevent to determine which column is the primary key for a table.

  My wild speculation a bit at a reasonable time could someone do...

  If you use synthetic primary keys (i.e. the keys generated by sequence) and that your tables are subject to large volumes of inserts such as there is a danger that the block "to the right" will be the source of contention block and worry not about analysis of beach on the column, you can create a reverse on this column (unique or non-unique) key index before creating the primary key constraint and to indicate Oracle to use this existing index to respect the primary key constraint.

  Obviously, however, this involves a lot of assumptions to arrive at a reasonable point. There may well be another set of assumptions that could also lead to a valid argument. Or it could be a myth that someone has heard and just repeats.

  Justin

• How to add a column to an existing unique index?

  Hello
  
  I have a unique index defined on 5 columns in a table. I want to add a column more to the unique index. Is there one solution other than to drop and create the index?
  
  Also please let me know which is the ideal way to do it. The table has about 80 million documents.
  
  
  Thanks in advance,
  Noble.

  None...

  but creating the new index before your previous fall, the previous will be helping to create the new index faster.

  Abhishek Gera