Accompanied by primary key to a 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).

• 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

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

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

• A composite primary key needs of the Unique ID column or not?

  Hello dear,
  I have a table that's the primary key is a key that is composed of two columns and there are like 5 columns of information. You think I'm going to use two columns as the primary key of this table or create a unique ID column.
  Example:
  Employees table:
  Services of table:
  
  The table of the problem is the Department managers:
  Now, I'll add employee id and service id in this table and Manager info etc... (info does not exist in the employee table), should I use as primary or create the id column in this table?
  
  Thank you very much.

  You must use the new ID as primary (alter table add constraint primary key,...) you cannot use foreign key as primary :)

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

• Another syntax for creating primary key

  
  Hello
  
  
  I have a question about the right way to create primary keys.
  Earlier, we were on Oracle 9i and we have upgraded to Oracle 10 g. The question is when creating primary key is allowed to create the unique index and then to create the primary key constraint? or directly create the first key is better? or are there ways to both the same?
  
  
  for example:
  one way:
  
  
  SQL & gt; CONN u2/u2@db1
  Connected.
  SQL & gt; create table a (a1, b1 varchar2 number (2), the date c1);
  
  
  Table created.
  
  
  SQL & gt; create an index on a (a1) tablespace unique pk_a t1;
  
  
  The index is created.
  
  
  
  SQL & gt; ALTER table a Add (constraint primary key (a1) using index pk_a);
  
  
  Modified table.
  Another way:
  SQL & gt; CONN u1/u1@db1
  Connected.
  SQL & gt; create table a (a1, b1 varchar2 number (2), the date c1)
  2.
  
  
  Table created.
  
  
  SQL & gt;
  SQL & gt; ALTER table a Add (constraint primary key (a1) using index tablespace t1 pk_a)
  2.
  
  
  Modified table.
  Which of the two approach is better? or are they the same?
  
  
  Thank you
  Cedric
  
  

  Oracle will attempt to create the index to apply the constraint. Of course, it is certainly possible that the creation of the index will fail, but you would be just to move the point of failure of the CREATE INDEX statement to the ALTER TABLE statement, assuming that everything else is equal (that is, you create the index in the same tablespace, quotas and tablespace sizes are the same, permissions are not changed, etc.)

  It may be preferable in some contexts to create a non-unique index before the creation of the constraint and instruct Oracle to use the non-unique index to apply the constraint. If you decide in the future to make the primary key constraint can be delayed, for example, have a non-unique index allows you to make this change without having to (implicitly), drop and re-create the index. A separate CREATE INDEX statement also influences when you go to remove a constraint / index. If the index was created before the constraint, you can remove the constraint without affecting the index. If the index was created after the constraint, deleting the constraint implicitly removes the index. Normally, particularly with OLTP applications, this doesn't buy you much. Sometimes, however, there are ETL process benefiting from such things.

  Justin

• 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

• 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
  

• Problem with the primary key and indexes

  Hi all
  
  I'm looking a mess on one of our main tables.
  One of the developers here added an index on 3 columns in the table, thinking that it would speed up (not noticing that it had not a PK).
  
  Subsequently another developer has noticed there do not have a primary on key. So they added a touch of primry on the single column.
  
  The problem is that now the index created on 3 columns is bein used as the primary key index. As when the primary key is created a new index was not created.
  
  Is there anyway to get rid of this index/change it correct?
  
  This table is related to many many other tables, so when we tried to remove the index we could not due to the primary key and foreign key violations with other tables.
  
  Thanks in advance

  Oracle, as you found, is quite capable to use a column enformce multi index a single column primary key, as long as the pk column is the leader in the index. This should not cause performance issues for a search of PK and if the three indexed columns are often selected only may benefit from these types of queries.

  The only way to change that now, would be to drop all CF, drop and add the PK constraint and then add all the FK constraints. A long time and potentially dangerous (if you miss to add back of the FKs) endeavour. Certainly not worth the risk in my opinion.

  John

• Creating primary key in online?

  My database is oracle11g. My environment is 24 * 7.
  
  I know that we can create indexes online. But here it is the primary key. I do below things... These tasks must not lock the table.
  
  1 remove the primary key
  2. recreate the primary key
  3 remove the normal index
  4 re-create the normal index.
  
  Task 4 can be done online. I'm afraid the rest of the task.
  
  1. no oracle locks the table while dropping the PK?
  2. how to recreate the PK online?
  3 oracle locks the table while removing the index?
  
  Please let me know.

  Dear Shrinika,

  If you read the ticket of Richard, you will find the answer to your question.

  There is an improvement over 11 g and concurrent transactions are not owned by a lock of index.

  Index lock will wait only active transaction that was created before the create index command.

  Ogan

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