Indexes and UNIQUE constraints

Similar Questions

• Index naming standards does not and unique constraints

  I found yet another question of naming standards

  I have tried to create a unique constraint as a normal index via the unique constraints and indexes in Properties of Table with the assumption that it will use the design properties of models.  This isn't.

  

  As noted in the image of the model above, my Unique constraint model is {table} _ {columns} lancement_remarques

  and my model of Index idx _ {columns} {table}.  Yet, when I try to create the Unique constraint, it creates the naming convention in names like CUSTOMER_ADDRESS__UK (2 lines of underscore?) as shown below.

  

  My assumption is that he needed a column, so I added the column and also applied the rules naming - nothing.

  

  Is my wrong assumption on these constraints being appointed through the models?  If this is not the case, what naming rules is in this context?

  The same behavior is evident when you try to create index.

  I get not all comments on my posts.  Are these bugs or just user error?

  Hello

  Thank you to report the problem, I logged a bug. You can get 'Rules of naming' works properly if you press the button 'Apply' before that.

  I get not all comments on my posts.

  I don't think that anyone (or any job) has been ignored on this forum. Depending on the complexity of the problem and our current commitment (other urgent tasks, holidays, time zone), you can get answer almost immediately or after a certain time.

  It is useful for us, if you mark your messages as replied if you get the right answer.

  Philippe

• Unique index or Unique constraint

  Hi all
  
  I am a student of Oracle SQL Expert Certification. At one point in the book, speaking of the clues, the author says that a unique index is not the same a unique constraint. However, it does not explain why they are two different things.
  
  Could someone clarify the difference between the two, please?
  
  Thank you very much
  
  Valerio

  A constraint has a different meaning for an index. It gives the optimizer more information and allows you to have foreign keys on the column, then that is not a unique index.

  for example:

  SQL> create table t1 (col1 number, col2 varchar2(20), constraint t1_uq unique (col1));
  
  Table created.
  
  SQL> create table t2 (col1 number, col2 varchar2(20));
  
  Table created.
  
  SQL> create unique index t2_idx on t2 (col1);
  
  Index created.
  
  SQL> create table t3 (col1 number, col2 number, col3 varchar2(20), constraint t3_fk
    2                   foreign key (col2) references t1 (col1));
  
  Table created.
  
  SQL> create table t4 (col1 number, col2 number, col3 varchar2(20), constraint t4_fk
    2                   foreign key (col2) references t2 (col1));
                   foreign key (col2) references t2 (col1))
                                                     *
  ERROR at line 2:
  ORA-02270: no matching unique or primary key for this column-list
  

  It's like saying ' what is the difference between a Chair and a Chair? They both allow you to sit! »

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

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

• Name of the PK, unique constraints and to support the index

  I want to have my primary key constraint and index support share of the same name, IE:

  CREATE UNIQUE INDEX MYTABLE_PK ON MYTABLE(...);
  ALTER TABLE MYTABLE ADD CONSTRAINT MYTABLE_PK PRIMARY KEY(...);

  Without definition explicit a unique index using the relational model, the generated DDL added 'X' for the name of the index:

  CREATE UNIQUE INDEX MYTABLE_PKX ON MYTABLE(...);
  ALTER TABLE MYTABLE ADD CONSTRAINT MYTABLE_PK PRIMARY KEY(...);

  I tried to add an index unique explicit to the table, but he changed the name (adds "v1") when I leave the table editor:

  CREATE UNIQUE INDEX MYTABLE_PKv1 ON MYTABLE(...);
  ALTER TABLE MYTABLE ADD CONSTRAINT MYTABLE_PK PRIMARY KEY(...);

  I have the same problem with index & unique constraints.
  
  Issues related to the:
  Can I generate DDL with name matching? "v1" thing seems unlikely, he doesn't want not myself save the definition as I want.
  Where are the transformations of naming for this location? I found tools, preferences, and Data Modeling/naming Standards/Templates but this nugget does nto seem to be there.
  
  Thank you.

  Hi Mike,.

  The Production data release model 3.1 has been updated to allow constraints unique and primary and their indexes share the same name.

  David

• 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

• Indexing and the integrity constraint functionality difference

  Hello
  
  Sometimes I confuse me, how we can distinguish between indexing and the integrity of the features of constraint. Please let me know or if any available doc.
  
  
  Kind regards
  REDA

  I assume you mean unique vs unique index constraints?

  The sole (or Primary Key) constraints provide additional metadata that can be used by the optimizer.
  An index will be used to help the database to apply the constraint (it is created, or if there is it will be "captured" by coercion)

  Insofar as a document [url http://docs.oracle.com/cd/E11882_01/server.112/e25789/toc.htm] that's something, you should read

• Indexes and constraints

  Hi guys!
  
  I did a little test and now I do not understand the result. Please explain to me the following:
  
  (1.) I created the following table emp1
  
  < pre >
  CREATE TABLE emp1
  (
  EmpNo NUMBER CONSTRAINT emp1_pk PRIMARY KEY
  USING INDEX
  (
  CREATE UNIQUE INDEX emp1_idx ON emp1 (empno)
  )
  );
  < / pre >
  
  2.) now, I interviewed user_indexes and user_constraints
  
  < pre >
  SELECT i.index_name, i.index_type, i.uniqueness, c.constraint_name, c.constraint_type, c.status
  From user_indexes i, user_constraints c
  WHERE i.table_name (+) = c.table_name
  AND c.constraint_name AS 'emp1_pk '.
  ORDER BY c.constraint_name;
  < / pre >
  The result displays the following lines:
  < pre >
  INDEX_NAME INDEX_TYPE UNIQUENESS CONSTRAINT_NAME, CONSTRAINT_TYPE STATUS
  ---------------------
  NORMAL SINGLE ACTIVE P EMP1_PK EMP1_IDX
  < / pre >
  
  3.) after that I disabled the emp1_pk constraint and I Redid the same query
  
  < pre >
  ALTER TABLE emp1 DISABLE NOVALIDATE CONSTRAINT emp1_pk;
  
  SELECT i.index_name, i.index_type, i.uniqueness, c.constraint_name, c.constraint_type, c.status
  From user_indexes i, user_constraints c
  WHERE i.table_name (+) = c.table_name
  AND c.constraint_name AS 'emp1_pk '.
  ORDER BY c.constraint_name;
  < / pre >
  The result displays the following lines:
  < pre >
  INDEX_NAME INDEX_TYPE UNIQUENESS CONSTRAINT_NAME, CONSTRAINT_TYPE STATUS
  ---------------------
  EMP1_PK NULL NULL NULL P DISABLED
  < / pre >
  
  So far so good. I got disabling of this constraint is okay to delete the corresponding index. But in the following example, the corresponding index would not be deleted.
  
  < pre >
  CREATE TABLE emp2
  (
  EmpNo NUMBER
  );
  
  CREATE UNIQUE INDEX emp2_idx
  ON emp2 (empno);
  
  ALTER TABLE emp2
  ADD CONSTRAINT emp2_pk PRIMARY KEY to the AID of INDEX emp2_idx;
  < / pre >
  
  2.) now, I interviewed user_indexes and user_constraints
  
  < pre >
  SELECT i.index_name, i.index_type, i.uniqueness, c.constraint_name, c.constraint_type, c.status
  From user_indexes i, user_constraints c
  WHERE i.table_name (+) = c.table_name
  AND c.constraint_name AS 'emp1_pk '.
  ORDER BY c.constraint_name;
  < / pre >
  The result displays the following lines:
  < pre >
  INDEX_NAME INDEX_TYPE UNIQUENESS CONSTRAINT_NAME, CONSTRAINT_TYPE STATUS
  ---------------------
  NORMAL SINGLE ACTIVE P EMP2_PK EMP2_IDX
  < / pre >
  
  The result of this query is the same as emp1_pk. But at the next step, the results differ.
  
  < pre >
  ALTER TABLE emp2 DISABLE NOVALIDATE CONSTRAINT emp2_pk;
  
  SELECT i.index_name, i.index_type, i.uniqueness, c.constraint_name, c.constraint_type, c.status
  From user_indexes i, user_constraints c
  WHERE i.table_name (+) = c.table_name
  AND c.constraint_name AS 'emp1_pk '.
  ORDER BY c.constraint_name;
  < / pre >
  The result displays the following lines:
  < pre >
  INDEX_NAME INDEX_TYPE UNIQUENESS CONSTRAINT_NAME, CONSTRAINT_TYPE STATUS
  ---------------------
  NORMAL EMP2_PK UNIQUE P DISABLED EMP2_IDX
  < / pre >
  
  That's what I did not understand. Emp1_pk has been disabled and the corresponding index emp1_idx was abandoned. Emp2_pk has been turned off but the corresponding index has not been deleted. Can someone explain to me please, the difference between the example 1 (emp1_pk) and example 2 (emp2_pk).
  
  Concerning

  Hello

  In the first example, Index was done by primary key, and when we disable the primary key, it also drops the corresponding index.
  But in the second example, the Index is created on the column separately and then the primary key is created. Now that there is already an index on the primary key column will use this existing index and when we disable the constraint this index will not be droppped because it was not created by primary key. It was only used by primary key.

  Concerning

• Models to define templates for keys, indexes and constraints in Version 4

  Oracle SQL Developer Data Model Version 4.0.0.833

  Someone tell me where to find templates to define templates for keys, indexes and constraints?

  In version 3, it has been in tools > General Options > naming standards > models

  Hello

  In the 4.0.0.833 version, you must open the Properties dialog box for the design (by doing a right click on the entry for the relevant design in the browser tree, and select properties).

  Then in the design properties dialog box, select settings > naming Standard > models

  David

• composite unique constraint on the values of parent and child?

  Is it possible to have a composite unique constraint that contains the values of the child elements? The example below has the "child" elements are offline, but it's preferred, but optional, I know that you can have a unique constraint in the set of tables without using a reference table that contains the constraint and the two columns. How xdb manages this requirement?
  
  permit:

  <parent ID="1">
     <child><name>test1</name></child>
     <child><name>test2</name></child>
  </parent>
  <parent ID="2">
     <child><name>test1</name></child>
     <child><name>test2</name></child>
  </parent>

  not allowed:

  <parent ID="1">
     <child><name>test1</name></child>
     <child><name>test1</name></child>
  </parent>

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
             xmlns:xdb="http://xmlns.oracle.com/xdb"
             xdb:storeVarrayAsTable="true"
             elementFormDefault="qualified">
      
      <xs:element name="parent" type="Parent_T"
          xdb:columnProps="CONSTRAINT parent_pkey PRIMARY KEY (XMLDATA.ID)"
          xdb:defaultTable="PARENT"/>
  
      <xs:complexType name="Parent_T" xdb:SQLType="PARENT_T" xdb:maintainDOM="false">
          <xs:sequence>
              <xs:element name="child" type="Child_T" minOccurs="1" maxOccurs="unbounded" xdb:SQLName="CHILD"
                        xdb:SQLInline="false" xdb:defaultTable="CHILD" "/>
          </xs:sequence>
          <xs:attribute name="ID" xdb:SQLName="ID" use="required" />
      </xs:complexType>
      
      <xs:complexType name="Child_T" xdb:SQLType="CHILD_T">
         <xs:sequence>
           <xs:element name="name" type="xs:string" xdb:SQLName="NAME"/>
         </xs:sequence>
       </xs:complexType>     
  </xs:schema>

  xdb:columnProps = "CONSTRAINT parent_pkey PRIMARY KEY (XMLDATA.ID), * UNIQUE (XMLDATA.» "Child.Name) *" triggers the non-existent attribute
  
  
  A possible solution would be to copy the value of the primary key parent of the child element, then I could create a composite unique constraint using only the values of the child. However, I have this same requirement elsewhere in my lowest nested schema, and it can become messy / bad design with cascading of all primary keys on the schema. For example, I have a recursive element in which two attributes must be unique only within the parent company:

  <parent id="1">
     <child a="1" b="1">
        <child a="1" b="2">
           <child a="1" b="1" /> *not allowed
        </child>
     </child>
     <child a="1" b="2" /> *not allowed
  </parent>

  Possible solution:

  <child a="1" b="2" parent_id="1" />
  <xs:complexType name="Child_T>
     <xs:sequence>
        <xs:element name="child" xsd:SQLInline="false" xsd:columnProps="UNIQUE(XMLDATA.a,XMLDATA.b,XMLDATA.parent_id)" minOccurs="0" maxOccurs="unbounded" type="Child_T">
     </xs:sequence>
     </xs:element
  </xs:complexType>

  Is there a better design?
  
  

  Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi 
  PL/SQL Release 10.2.0.4.0 - Production                           
  CORE     10.2.0.4.0     Production                                       
  TNS for Linux: Version 10.2.0.4.0 - Production                   
  NLSRTL Version 10.2.0.4.0 - Production 

  You can do something like this:

  SQL> DECLARE
    2
    3    xsd_doc xmltype := xmltype('
    4  
    5    
    6      
    7        
    8          
    9        
   10      
   11    
   12    
   13      
   14        
   15          
   16        
   17      
   18    
   19    
   20      
   21        
   22          
   23        
   24        
   25      
   26    
   27    
   28      
   29        
   30          
   31        
   32      
   33    
   34  ');
   35
   36  BEGIN
   37
   38    dbms_xmlschema.registerSchema(
   39      schemaURL => 'test_parent.xsd',
   40      schemaDoc => xsd_doc,
   41      local => true,
   42      genTypes => true,
   43      genbean => false,
   44      genTables => false,
   45      enableHierarchy => dbms_xmlschema.ENABLE_HIERARCHY_NONE
   46    );
   47
   48  END;
   49  /
  
  PL/SQL procedure successfully completed
  
  SQL> CREATE TABLE my_xml_table OF XMLTYPE
    2  XMLTYPE STORE AS OBJECT RELATIONAL
    3  XMLSCHEMA "test_parent.xsd"
    4  ELEMENT "root"
    5  VARRAY xmldata."parent" STORE AS TABLE my_parent_tab
    6  (
    7    VARRAY "child" STORE AS TABLE my_child_tab
    8  )
    9  ;
  
  Table created
  
  SQL> ALTER TABLE my_parent_tab ADD CONSTRAINT parent_uk UNIQUE (nested_table_id, "ID");
  
  Table altered
  
  SQL> ALTER TABLE my_child_tab ADD CONSTRAINT child_uk UNIQUE (nested_table_id, "name");
  
  Table altered
   
  

  Then:

  SQL> insert into my_xml_table values (
    2  xmltype('
    3     test1
    4     test2
    5  
    6  
    7     test1
    8     test2
    9  ')
   10  );
  insert into my_xml_table values (
  *
  ERREUR à la ligne 1 :
  ORA-00001: violation de contrainte unique (DEV.PARENT_UK)
  
  SQL> insert into my_xml_table values (
    2  xmltype('
    3     test1
    4     test1
    5  
    6  
    7     test1
    8     test2
    9  ')
   10  );
  insert into my_xml_table values (
  *
  ERREUR à la ligne 1 :
  ORA-00001: violation de contrainte unique (DEV.CHILD_UK)
  
  SQL> insert into my_xml_table values (
    2  xmltype('
    3     test1
    4     test2
    5  
    6  
    7     test1
    8     test2
    9  ')
   10  );
  
  1 ligne créée.
  

  http://download.Oracle.com/docs/CD/B19306_01/AppDev.102/b14259/xdb06stt.htm#sthref987

• Unique constraint on the values in both directions

  I'm looking to create a unique constraint that works in two ways. Say I got a constraint unique in columns 1 and 2. I want it to be impossible for the two lines below the two exist at the same time. Is there a way to do this? I googled around for a while now and I found nothing that works so far.

  Header 1	Header 2
  Dog	CAT
  CAT	Dog

  Hello

  You can create an index based on a single function:, like this:

  CREATE UNIQUE INDEX table_x_header_1_header_2

  ON table_x (LESS (header_1, header_2)

  More LARGE (header_1, header_2)

  );

  How will you use these values?  You might be better to simply create a regular old unique constraint, but also have a CHECK constraint to ensure that header_1<= header_2. ="" that="" way,="" when="" you="" want="" to="" search="" for="" the="" combination="" ('cat',="" 'dog')="" you="" won't="" have="" to="" search="" for="" ('dog',="" 'cat')="">

• Customized for a Unique constraint processing scripts

  Hallo,

  How can I create the Unique constraint (not a Unique Index) transformation scripts:

  var key_column = 'KEY';
  // get tables
  tables = model.getTableSet().toArray();
  for (var t = 0; t < tables.length;t++){
       table = tables[t];
       table_name = table.getName();
       abbr = table.getAbbreviation()+"_";
       key_col = table.getElementByName(key_column);
       if (key_col!=null){
            uniq = table.createIndex(); // it is right?
            table.setDirty(true);
            uniq.setName('UNIQUE'); // does not matter
            uniq.add(id3_col);
            uniq.setUK(true); // a method does not exist
            table.setUK(uniq);// a method does not exist
        }
  }
  
  

  regarding

  Oleg

  Hello Oleg,

  lines 14 and 15 are false. The use of the persistence method is:

  uniq.setIndexState ("Unique constraint");

  Other options here - you can spot if you look at the XML file representing the table with PK and UK constraints and regular index - "primary constraint, «Unique Index ordinary', «Clear index»»

  Philippe

• table partitioned and unique keys

  I really don't understand why Oracle does not apply in some cases, unique keys.

  Let's say I have a table

  create table t (t_type not null, t_key not null, id not null, not null value)

  list partition (t_type)

  (

  type1 partition values ('ppp1"),

  rest of partition (default) values

  ) as

  Select "ppp" | rownum, rownum, rownum, rownum of double connect by rownum < = 100;

  And following changes in the indices for unique keys

  -1

  create index idx_1 on t (t_key, id);

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  ALTER table drop constraint t_uk drop index;

  -2

  create index idx_1 on t (t_key, id, t_type);

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  ALTER table drop constraint t_uk drop index;

  -3

  create index idx_1 on t (t_key, id, t_type) local;

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  Drop index idx_1;

  -4

  create an index only idx_1 on t (t_key, id);

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  Drop index idx_1;

  -5

  create an index only idx_1 on t (t_key, id, t_type);

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  Drop index idx_1;

  -6

  create an index only idx_1 on t (t_key, id, t_type) local;

  ALTER table t add constraint t_uk unique (t_key) using index idx_1;

  Drop index idx_1;

  -7

  create index idx_1 on t (t_key, t_type, id) local;

  ALTER table t add t_uk unique constraint (t_key, t_type) using index idx_1;

  ALTER table drop constraint t_uk drop index;

  -8

  create an index only idx_1 on t (t_key, t_type, id) local;

  ALTER table t add t_uk unique constraint (t_key, t_type) using index idx_1;

  Drop index idx_1;

  I got the set of questions:

  1. first and second cases were performed with success while 4th and 5th failed.

  The only difference is that the overall index in 4th and 5th cases are unique.

  It is unclear why ' ORA-14196: specified index cannot be used to apply the constraint. ' has occurred.

  2. in the third case index is similar to that in second place with the only difference that it is local.

  Still, it is not clear why it failed with ORA-14196.

  3 and the last question why ORA-14196 arose in 8 cases, while the 7th, it didn't.

  The only difference is the local index in 8 cases is unique.

  Thank you

  Hi Alex

  (1) index 4 and 5 cannot be used to police the unique constraint as a unique index must have the same list of column under duress. Index 4, to establish in a non-unique index or to remove the column id of the index. To index 5, you will need to make a non-unique index or remove the columns id and index t_type.

  (2) 3 index cannot be used to the unique constraint of police that it is a local index and is not partitioned column (t_type) in both the definition of index/constraint. If allowed, this would require Oracle having to visit each partition to ensure that any new value of t_key is truly unique, that would not scale. Include the t_type column in the constraint and the index to both t_type and t_key as of the columns (so move the id column 3rd position) and it would be successful.

  (Index 3) 8 fails for the same reason as in 1). It's a unique index with a different column from the constraint list. Remove the id column of the index or to make it a non-unique index and it will be successful.

  In summary, a unique index MUST have the same list of column than the constraint and a local index MUST have the partitioning columns in both the definition of index/constraint.

  See you soon

  Richard Foote

  http://richardfoote.WordPress.com/

• Case-insensitive unique constraint

  Hi guys,.
  
  Is it possible to create a unique constraint that is case-insensitive
  
  I mean if there is a unique constraint on the name of col
  
  then
  'James' and 'JAMES' must not
  
  
  Kind regards
  
  PAPI

  Create a unique index to the basic function of...

  create unique index uk_name on emp(upper(ename));