Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Primary and Unique Key Constraints Administration TipsPrimary and Unique Key ConstraintsAny time you declare a Primary or Unique Key constraint on a table, Oracle willautomatically create an index for you on the constrained column (unless you alreadycreated your own one).For example, following this command:CREATE TABLE CON_TEST (COL1 NUMBER CONSTRAINT CONTEST_COL1_PK PRIMARY KEY,COL2 CHAR(5)); can immediately issue this query:SELECT INDEX_NAME, INDEX_TYPE, TABLE_NAMEFROM DBA_INDEXESWHERE INDEX_NAME LIKE CON%;... and get this sort of report:INDEX_NAME UNIQUENESS TABLE_NAME-------------------- ----------------------- ------------CONTEST_COL1_PK UNIQUE CON_TEST...and youll notice immediately two key things. First, the index name is the same as theconstraint name specified during the "create table" statement (and thats an excellentreason for getting into the habit of naming your constraints properly whenever you definethem). And secondly, Oracle created a unique index for us. Both these things happenwhen you declare unique constraints, too, not just primary key ones.The last fact, that the index was unique, might not be so surprising, if you think about it:after all, the very definition of a primary key is that every entry is unique. And unique keyconstraints will also be unique (!) -so its blindingly obvious that Oracle will create a uniqueindex. Isnt it?Well, it might be blindingly obvious, (it also happens not always to be true, but more onthat later) but it has one unfortunate side effect. If I disable my primary key constraint(perhaps because I am going to do some maintenance work, or a million row insert), I do itlike this:ALTER TABLE CON_TEST DISABLE CONSTRAINT CONTEST_COL1_PK;If I then immediately re-submit my query about the indexes associated with this table, Iget this:Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 4
  2. 2. Primary and Unique Key Constraints Administration TipsSELECT INDEX_NAME, INDEX_TYPE, TABLE_NAMEFROM DBA_INDEXESWHERE INDEX_NAME LIKE CON%;NO ROWS SELECTEDIn other words, disabling the constraint caused the index to be dropped.This behaviour is potentially appalling. There you are, intending to disable the constraintfor two minutes maintenance work, and woosh! An entire 10Gb index disappears -whichmeans that when I re-enable the constraint, the entire thing has to be rebuilt from scratch,necessitating exclusive table locks until the entire 10Gb edifice is reconstructed (and thishas actually happened to me!)So theres the first thing to learn about both primary key and unique key constraints: ifenforced with a unique index, the index is dropped when the constraint is disabled, andre-built when re-enabled.Is there anything to be done about this? Well, not in Oracle 7 there isnt. But in Oracle 8.0,the idea of a deferred constraint was introduced.A deferred constraint is one that is not checked as each insert is performed, but is checkedwhen all the inserts have finished, and the User attempts a commit. If at that point, arecord that violates the constraint is detected, the complete set of inserts is rolled back.One of the main ideas behind deferring constraints in this way is that it allows bulk loadsof data to proceed much faster than if the constraint is "immediate" -theres one mammothcheck at the end of the load, rather than 10,000,000 little immediate checks as each rowof new data is inserted.But think about it... If we are inserting data which might temporarily violate theconstraint, fair enough that Oracle will sort that out when we come to commit. But in themeantime, where does that bit of bad data have to reside? Well, in the table, of course(since data cant just float around in the ether!). So, when the constraint is deferred,records which violate the constraint must be allowed to get into the table (although theyllbe kicked out when we commit).But how can a non-unique record reside in the table, however temporarily, if theres aunique index on that table? The answer is it cant -the index will protest at the inclusionof non-unique leaf entries, and will throw an error. So how then can we ever defer aconstraint if there is a unique index backing it up, as the example shown above makesclear there will be?Well, the answer is that we cant. If the index is unique, the constraint can not bedeferred. But put it the other way around: if the constraint is deferred, the index can notCopyright © Howard Rogers 2001 10/18/2001 Page 2 of 4
  3. 3. Primary and Unique Key Constraints Administration Tipsbe unique! Even more importantly, the determinant is whether the constraint isdeferrable, not whether it is actually deferred or not. A deferrable constraint can beinitially immediate or initially deferred. Its the fact that it might one day be deferredthat is important to Oracle.Therefore, if I issue the following command:CREATE TABLE CONTEST2 (COL1 NUMBER CONSTRAINT CONTEST2_COL1_PK PRIMARY KEY DEFERRABLE INITIALLY IMMEDIATE,COL2 CHAR(5));...and then re-run my query for the index details, we see this:INDEX_NAME UNIQUENES TABLE_NAME------------------------ --------- ---------------CONTEST2_COL1_PK NONUNIQUE CONTEST2...and we discover that a primary key constraint is now being enforced with a NON-uniqueindex.So what happens when we disable the constraint now?SQL> ALTER TABLE CONTEST2 DISABLE CONSTRAINT CONTEST2;TABLE ALTERED.SQL> SELECT INDEX_NAME, UNIQUENESS, TABLE_NAME 2 FROM DBA_INDEXES 3 WHERE INDEX_NAME LIKE CON%;INDEX_NAME UNIQUENES TABLE_NAME------------------------------ --------- --------------CONTEST2 NONUNIQUE CONTEST2...and now youll notice that the index is retained after the constraint is disabled.Summing all that up, we get a very simple rule: the index associated with a primary orunique key constraint is dropped when the constraint is disabled if it is unique, but isretained if it is non-unique.And that translates into a simple rule of thumb for most DBAs: always make your uniqueand primary key constraints deferrable. Whether you choose then to make them actuallydeferred or initially immediate is up to you. But by making them deferrable, you putCopyright © Howard Rogers 2001 10/18/2001 Page 3 of 4
  4. 4. Primary and Unique Key Constraints Administration Tipsyourself in control over when indexes are dropped, not let Oracle silently make thedecision for you.Before buying into that piece of advice, you might reasonably ask whether the fact that aconstraint is using a unique index makes it faster than if it using a non-unique index. Arethere any performance penalties in making constraints deferrable?The answer is no. Its just as quick to use a non-unique index as a unique one. That mightsurprise you, but the reason for it isnt hard to find. Although the index is created as non-unique, its contents will actually be unique, because even when deferrable, the constraintIS enforced at commit time. Any violating records found at that point are rolled back outof the table (and hence out of the index) -so the index contents are indeed going to beunique in practice. The optimiser is smart enough to know this, and therefore it treats anon-unique index which it knows to be enforcing a primary or unique key constraint inexactly the same way as it would a unique index. In effect, it totally ignores theuniqueness attribute of an index when working out how best to answer a query or performsome DML.One final point which many DBAs seem to overlook. The indexes that are created whenunique and primary key constraints are defined need to be housed in a tablespacesomewhere. In none of the examples Ive shown above have I mentioned that: andaccordingly, all my indexes would have been created in the default tablespace of the Userwho was issuing the create table commands.Thats not usually what you want: indexes are normally sent to their own tablespace. Thatneeds to be specified when you define the constraint like this:CREATE TABLE CONTEST2 (COL1 NUMBER CONSTRAINT CONTEST2_COL1_PK PRIMARY KEY DEFERRABLE INITIALLY IMMEDIATE USING INDEX TABLESPACE INDX01,COL2 CHAR(5));The using index clause is the one that does the deed. You can also stick a storage clausein there if you really want to (my advice is never to specify storage clauses at the segmentlevel -thats why theres a tablespace default storage clause!).In summary: primary and unique key constraints should always be declared deferrable,and should always include a using index clause to house the associated index in anappropriate tablespace.Copyright © Howard Rogers 2001 10/18/2001 Page 4 of 4