Unique and non-unique indexes

Similar Questions

• clustered index and non-clustered indexes

  Hi ihave read on index qqustion
  
  in SQL Server, table has 1 clustered index and 280 (average) no clustered index.
  SqlServer hold a clustered index and the data on the same location. index if cluster command firm data
  but sqlserver hold index non-clustered on another file and do not directly order data.
  oracle index how does this? for example, I have 3 indexes on the table. how they work? is oracle this clustered index and indexes not clustrered?

  Oracle has no cluster & nonclustered indexes.
  Oracle has Btree, bitmap, text, index basis function

  Disappeared through the link
  http://www.lorentzcenter.nl/awcourse/Oracle/server.920/a96520/indexes.htm

• 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).

• 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.

• What is the difference between primary key and unique indexes with forced not null?

  Primary key is = unique index + not null?

  The short answer is Yes.

  However, even if the primary key, applying both uniquness and not null, there is a notion of "special".

  You can only have one primary key in tables, but you can have multiple unique indexes and constraints not null.

  See: https://asktom.oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:8743855576462

• (ORA-00955) conflict of naming for index and constraint when you use a unique index (.. desc,.. CSA)

  Hello

  indexes and constraints are in different namespaces, so it should be possible to give them the same name.

  In the following case that apparently does not work:
  

  create unique index orders_year_show_uq
    on orders (year desc, show_orders asc);
   
   alter table orders
    add constraint orders_year_show_uq unique (year, show_order);
  

  When I run these statement, I get a "SQL Error: ORA-00955: name is already used by an existing object". ""

  If I clean and I execute the same instructions as above with the only difference on the 2 line, using "asc year" instead of "year desc":

  
    on orders (year asc, show_orders asc);
  

  then it success.

  I can't explain it, you have an idea?

  Thanks in advance.

  Kind regards

  Giovanni

  First of all, you have show_orders in index and show_order in the constraint. I'll assume that it's a typo. Second, when you create constraint without index enhance the specification Oracle seeks indexes existing on the same set of columns in ascending order. If this index does not exist (and it's your case, since one of your columns to index is in descending order), Oracle tries to create one with the same name as the constraint. That's why you get ORA-00955: name is already used by an existing object. In general, you can specify explicitly the index name to force the Oracle by using the existing index. But it will not help you. If you issue

  ALTER table orders add unique constraint (year, show_orders) orders_year_show_uq using index orders_year_show_uq;

  You will get the ORA-14196: specified index cannot be used to apply the constraint.

  In any case, Oracle does not support using index DESC for PK/UK.

  SY.

• ORA-01502 error in the case of a unique index unusable and dml in bulk

  Hi all.
  
  The BP is 11.2.0.3 on a linux machine.
  
  I did a unique index unusable and issued a dml on the table.
  Howerver, oracle gave me the error ORA-01502.
  
  In order to avoid the ORA-01502 error, should I drop the unique index and bulk make dml and rebuild the index?
  
  Or is there another solution without recreating the unique index?
  

  create table hoho.abcde as
  select level col1 from dual connect by level <=1000 
  
  10:09:55 HOHO@PD1MGD>create unique index hoho.abcde_dx1 on hoho.abcde (col1);
  
  Index created.
  
  10:10:23 HOHO@PD1MGD>alter index hoho.abcde_dx1 unusable;
  
  Index altered.
  
  Elapsed: 00:00:00.03
  10:11:27 HOHO@PD1MGD>delete from hoho.abcde where rownum < 11;
  delete from hoho.abcde where rownum < 11
  *
  ERROR at line 1:
  ORA-01502: index 'HOHO.ABCDE_DX1' or partition of such index is in unusable state

  Thanks in advance.
  Best regards.

  Do I have to accept the unique index maintenance workload(undo generation/redo for undo generation)
  when doing bulk dml?
  

  I think so.

  The amount of data you load compared to existing data in the table?

  If say for example, you add 20%, and then to compare the retention of 20% adds data during the major part collect to create all of the index after insertion so
  you choose the drop/recreate the unique index

  Best regards

  Mohamed Houri
  www.hourim.WordPress.com

• Difference of path between primary key and a Unique Index

  Hi all
  
  Is there a specific way the oracle optimizer to treat differently the Primary key and Unique index?
  
  Oracle Version

  SQL> select * from v$version;
  
  BANNER
  --------------------------------------------------------------------------------
  Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
  PL/SQL Release 11.2.0.3.0 - Production
  CORE    11.2.0.3.0      Production
  TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
  NLSRTL Version 11.2.0.3.0 - Production
  
  SQL> 

  Sample data test for Index Normal
  

  SQL> create table t_test_tab(col1 number, col2 number, col3 varchar2(12));
  
  Table created.
  
  SQL> create sequence seq_t_test_tab start with 1 increment by 1 ;
  
  Sequence created.
  
  SQL>  insert into t_test_tab select seq_t_test_tab.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
  
  99999 rows created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> exec dbms_stats.gather_table_stats(USER_OWNER','T_TEST_TAB',cascade => true);
  
  PL/SQL procedure successfully completed.
  
  SQL> select col1 from t_test_tab;
  
  99999 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 1565504962
  
  --------------------------------------------------------------------------------
  | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
  --------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |            | 99999 |   488K|    74   (3)| 00:00:01 |
  |   1 |  TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
  --------------------------------------------------------------------------------
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
         6915  consistent gets
          259  physical reads
            0  redo size
      1829388  bytes sent via SQL*Net to client
        73850  bytes received via SQL*Net from client
         6668  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
        99999  rows processed
  
  SQL> create index idx_t_test_tab on t_test_tab(col1);
  
  Index created.
  
  SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB',cascade => true); 
  
  PL/SQL procedure successfully completed.
  
  SQL> select col1 from t_test_tab;
  
  99999 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 1565504962
  
  --------------------------------------------------------------------------------
  | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
  --------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |            | 99999 |   488K|    74   (3)| 00:00:01 |
  |   1 |  TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
  --------------------------------------------------------------------------------
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
         6915  consistent gets
            0  physical reads
            0  redo size
      1829388  bytes sent via SQL*Net to client
        73850  bytes received via SQL*Net from client
         6668  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
        99999  rows processed
  
  SQL> 

  Examples of test when using primary key data
  

  SQL> create table t_test_tab1(col1 number, col2 number, col3 varchar2(12));
  
  Table created.
  
  SQL> create sequence seq_t_test_tab1 start with 1 increment by 1 ;
  
  Sequence created.
  
  SQL> insert into t_test_tab1 select seq_t_test_tab1.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
   
  99999 rows created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true);
  
  PL/SQL procedure successfully completed.
  
  SQL> select col1 from t_test_tab1;
  
  99999 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 1727568366
  
  ---------------------------------------------------------------------------------
  | Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
  ---------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |             | 99999 |   488K|    74   (3)| 00:00:01 |
  |   1 |  TABLE ACCESS FULL| T_TEST_TAB1 | 99999 |   488K|    74   (3)| 00:00:01 |
  ---------------------------------------------------------------------------------
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
         6915  consistent gets
            0  physical reads
            0  redo size
      1829388  bytes sent via SQL*Net to client
        73850  bytes received via SQL*Net from client
         6668  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
        99999  rows processed
  
  SQL> alter table t_test_tab1 add constraint pk_t_test_tab1 primary key (col1);
  
  Table altered.
  
  SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true); 
  
  PL/SQL procedure successfully completed.
  
  SQL> select col1 from t_test_tab1;
  
  99999 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 2995826579
  
  ---------------------------------------------------------------------------------------
  | Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
  ---------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT     |                | 99999 |   488K|    59   (2)| 00:00:01 |
  |   1 |  INDEX FAST FULL SCAN| PK_T_TEST_TAB1 | 99999 |   488K|    59   (2)| 00:00:01 |
  ---------------------------------------------------------------------------------------
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
         6867  consistent gets
            0  physical reads
            0  redo size
      1829388  bytes sent via SQL*Net to client
        73850  bytes received via SQL*Net from client
         6668  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
        99999  rows processed
  
  SQL> 

  If you see here the same even as the statistics were gathered,
  * In the 1st table T_TEST_TAB, table always use FULL table access after creating indexes.
  * And in the 2nd table T_TEST_TAB1, table uses PRIMARY KEY as expected.
  
  Any comments?
  
  Kind regards
  BPat

  >
  * In the 1st table T_TEST_TAB, table always use FULL table access after creating indexes.
  * And in the 2nd table T_TEST_TAB1, table uses PRIMARY KEY as expected.
  >
  Yes - for the first table a full table scan will be used as the currently selected column is nullable and indexes do not include null values.

  The index can be used for the second query, since all the data (first column) is available between the index and there may be no NULL values because of the primary key. If you check constraints, you find that the there is now a CHECK constraint to ensure that the first column cannot be null.

  For a full and interesting discussion see the explanation of this and a related issue on the question I ask in this thread
  What SYS tables (not seen) contain the value NULL spec /not/ column definition? and my response he posted: 23 April 2012 09:02

  I ask the question is based on a question here which is similar to yours
  Columns becoming nullable after a fall of primary key?

• Unique index and "$SYS_NC00012".

  Hi bolow is creating scritpt index that I created in on the table

  CREATE UNIQUE INDEX TESTUK_05
  ON TEST (COL1_NO,
               COL2_NO,
               COL3_DATE,
               COL4_NO DESC)
  PCTFREE 002
  INITRANS 5
  STORAGE (
            INITIAL 200M
            PCTINCREASE 0
          )
  TABLESPACE USERS;

  but when I m running table user_ind_columns he shows me another column name instead of the last column that is "col4_no".

  select TABLE_NAME,INDEX_NAME,COLUMN_NAME from user_ind_columns where table_name='TEST' order by INDEX_NAME;
  
  TEST      TESTUK_05            COL3_DATE
  TEST      TESTUK_05            COL2_NO
  TEST      TESTUK_05            COL1_NO
  TEST      TESTUK_05            SYS_NC00012$

  PLEASE TEL ME WHY IT GIVES NAME AS COLUMN "SYS_NC00012$" INSTEAD OF COL4_NO

  See notes on "ASC | DESC' at http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_5010.htm#i2062403

  'DESC' creates a function-based Index. Oracle creates a column for COL4_NO expression in descending order.

  I would advise that you not misc mix ASC and DESC of columns in an index.

  Hemant K Collette

  Published by: Hemant K grapple on March 9, 2011 16:58
  URL edited to CREATE INDEX Syntax

  Published by: Hemant K grapple on March 9, 2011 17:09

• non-unique index

  Hello
  
  Why Oracle adds the rowid of a non-unique index? why each entry in the non-unique index must be unique?
  
  Thank you

  http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:2047869500346039771
  Why a rowid is added to the key for a non-unique index?

  Please read above links. Hope may be useful.

  Concerning
  Girish Sharma

• 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

• 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