Unique index vs non-unique index

Hi Gurus,
I'm getting lots of "TABLE ACCESS FULL" for lots of columns which have non-unique indexes is some queries. So my question is does optimizer does not pick up non-unique index but only pickes up unique indexes for those columns.
Thanks
Amitava.

amitavachatterjee1975 wrote:
Hi Gurus,
I'm getting lots of "TABLE ACCESS FULL" for lots of columns which have non-unique indexes is some queries. So my question is does optimizer does not pick up non-unique index but only pickes up unique indexes for those columns.
Thanks
Amitava.WHY MY INDEX IS NOT BEING USED
http://communities.bmc.com/communities/docs/DOC-10031
http://searchoracle.techtarget.com/tip/Why-isn-t-my-index-getting-used
http://www.orafaq.com/tuningguide/not%20using%20index.html

Similar Messages

WHat is the best index type for non uniqueness / Varchar columns in SQL 2008 R2

Hello All Greetings,
Please help me here with my doubt,
in my table i have two columns about a million rows, it has about 20 columns in it, three columns with name as Period, Gender so most of the time these two columns use in where clause,
Gender will contain Either M or F , Period contains YYYY-Month (2013-December, 2013-August) etc so i would like to add a Index to these two columns so that in will increase the performance, so please let me know what type of indexes i need to add to
these columns in the table,
please note that only one time we will add data to the table which will take only 2 minutes but we query the table every day
so my question what is the best index type that i need to create on columns with non uniqueness values in the column.,
Thank you In Advance,
Milan

There is nothing whatever wrong with creating an index on a VARCHAR column, or set of columns.
Regarding the performance of VARCHAR/INT, as with everything in a RDBMS, it depends on what you are doing. What you may be thinking of is the fact that clustering a table on a VARCHAR key is (in SQL Server) marginally less efficient than clustering on a monotonically
increasing numerical key, and can introduce fragmentation.
Or you may be thinking of what you have heard about writing JOINs on VARCHAR columns - it is true, it is a little less efficient than a JOIN on numeric type, but it is only a little less efficient, nothing that would lead you to never join on varchar cols.
None of this does not mean that you should not create indexes on VARCHAR columns. A needed index on a VARCHAR column will boost query performance, often by orders of magnitude. If you need an index on a VARCHAR, create it. It makes no sense to try to find an
integer column to create the index on - the engine will never use it.
Check this reference: http://stackoverflow.com/questions/14041481/is-it-good-to-create-a-nonclustered-index-on-a-column-of-type-varchar
Mark ANSWER if this reply resolves your query, If helpful then VOTE HELPFUL
INSQLSERVER.COM
Mohammad Nizamuddin

Primary Key supported by a non-unique index?

Encountered a weird situation today. A utility we setup which allows Analysts to restore data into their tables, started failing when it attempted to drop an index. The index was supporting a Primary Key. Makes sense. But our script was supposed to only be attempting to drop/recreate non-unique indexes. Turns out the supporting index on the Primary Key was non-unique, and to the best of my knowledge came about 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_IXWhat I can't figure out is how a non-unique index is enforcing uniqueness. I thought that it was the key in that very same process. I thought that perhaps an index with the 'SYS_123456' was getting created, perhaps, but I couldn't find one:
SQL> select object_name, object_type from dba_objects order by created desc;
OBJECT_NAME   OBJECT_TYPE
JUNK_IX     INDEX
JUNK     TABLE
...How is the uniqueness getting enforced in this case? This is in Oracle 11.1.0.7
Thanks,
--=Chuck

It has always been that way. Oracle can, and will, use a non-unique index to enforce a PK constraint, The existing index just needs to have the PK column(s) as the leading column(s) of 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) violatedJohn

Non Unique Indexes on Dimension Table

Hello ,
I have Material Dimension that has Product MainGroup, Brand , SPC code broken from Product Hierarchy.
As per Business Requirement , we don't want to use the Product Hierarchy , that should need to split into 3 pieces.
Since The Cube Dimensions already reached the 13 , we can not increase the dimensions to keep these 3 fields into separate dimensions.
I heard from Basis guy as <b>we can have index on three fields in same dimension table</b> & read some negative impact on aggregate definition.
Is it true , which one is true , am not sure.
Which one impact causes more worst & usefull..?
Could please some experts throw some light on this.
Cheers
Martin

Martin -
Not sure what you mean by "read some negative impact on aggregate definition".
But as far as adding additional indices on other columns of a dimension table, that certainly is doable. I have never done this as part of an actual intentiional design, but it seems like a valid apporach if you are limited by dimensions. I'm assuming when you say you already have 13, that the 13 does not include the three standard dimensions for time, request, (drawing a blank, is it currency), so that you really have 16 dimensions, 13 of which are user defined.
We have added dimension tabl e indices in our shop when we have found large dimension tables that, either from poor initial design, or changes to the data and/or queries, have resulted in full tables scans against large dimension tables. In some cases, the query costs of the full scan of the dimension table was more than the cost for the access of the fact table itself.
These indices must be added by your DBA as they can not be added thru the Admin Wkbench. You should also probably keep a record of any of these indices you create because if for some reason you delete the tables and reactivate the cube, you'll probably lose them.
Pizzaman

Difference b/w index and unique

Hi,
Difference b/w index and unique?

hi,
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
INDEX:
An index can be considered a copy of a database table that has been reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example using a binary search. The index also contains a pointer to the corresponding record of the actual table so that the fields not contained in the index can also be read.
The primary index is distinguished from the secondary indexes of a table. The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database
You can also create further indexes on a table in the ABAP Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the sorting of the primary index for the access.
Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan).
The system automatically creates the primary index. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.
If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVINGclauses, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set.
You create secondary indexes using the ABAP Dictionary. There you can create its columns and define it as UNIQUE. However, you should not create secondary indexes to cover all possible combinations of fields.
Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table.
If a table has more than five indexes, you run the risk of the optimizer choosing the wrong one for a particular operation. For this reason, you should avoid indexes with overlapping contents.
Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that columns selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to, at most, five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.
If all of the columns in the SELECT clause are contained in the index, the system does not have to search the actual table data after reading from the index. If you have a SELECT clause with very few columns, you can improve performance dramatically by including these columns in a secondary index.
What is the difference between primary index and secondary index?
http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
Message was edited by:
Roja Velagapudi

Difference between Unique key and Unique index

Hi All,
I've got confused in the difference between unique index & unique key in a table.
While we create a unique index on a table, its created as a unique index.
On the other hand, if we create a unique key/constraint on the table, Oracle also creates an index entry for that. So I can find the same name object in all_constraints as well as in all_indexes.
My question here is that if during creation of unique key/constraint, an index is automatically created than why is the need to create unique key and then two objects , while we can create only one object i.e. unique index.
Thanks
Deepak

This is only my understanding and is not according to any documentation, that is as follows.
The unique key (constraint) needs an unique index for achieving constraint of itself.
Developers and users can make any constraint (unique-key, primary-key, foreign-key, not-null ...) to enable,disable and be deferable. Unique key is able to be enabled, disabled, deferable.
On the other hand, the index is used for performance-up originally, unique index itself doesn't have the concept like constraints. The index (including non-unique, unique) can be rebuilded,enabled,disabled etc. But I think that index cannot be set "deferable-builded" automatic.

Can we change the fields of database unique index in a customised table?

Hi all..
I want to know that can we create or change or delete the database unique index of a customized table?
In my case, there is a customised table with 4 primary keys with all the records to be maintained thru transaction code SM30.
There is database unique index maintained for this table which has 2 fields. These 2 fields are out of the 4 primary fields of the table.I hope I have made myself clear!
Now when I am trying to insert a record in the table it give me a short dump.( It says duplication of records is not allowed)
The reason being that the new record that I am trying to insert in the database table has those 2 fields for which the unique index is maintained is the same as an already existing record.And the other two fields are different from the already existing record.So overall the combination of the 4 primary fields is different.
Please tell me how shall I proceed now?
I also tried to change the Unique index but it is asking me some kind of authrization(You are not authorized to make changes (authorization object S_DEVELOP)).Also I am not sure whether changing the unique index is feasible or not.?
Thanks.

hi
I think you will not be able to do unique indexing withou the help of primary keys,so use all the primary keys into the table field selections and and then create indexing otherwise dupilication of keys can occur. if you are not able to keep the primary keys then go for non unique key indexing,where you have to add the client field and the any keys of your wish.

UNIQUE INDEX and PRIMARY KEYS

Hi Friends,
I am confused about primary keys.
What is the purpose of this key again? I know it is used for unique constraints.
Supposing I have a table with two (2) columns which are each indexed as unique.
Then they can me both candidate at primary key right?
So why do I need a primary key again? when I have 2 columns which are uniquely index?
Thanks a lot

A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. This constraint does not apply to NULL values except for the BDB storage engine. For other engines, a UNIQUE index allows multiple NULL values for columns that can contain NULL
The differences between the two are:
1. Column(s) that make the Primary Key of a table cannot be NULL since by definition; the Primary Key cannot be NULL since it helps uniquely identify the record in the table. The column(s) that make up the unique index can be nullable. A note worth mentioning over here is that different RDBMS treat this differently –> while SQL Server and DB2 do not allow more than one NULL value in a unique index column, Oracle allows multiple NULL values. That is one of the things to look out for when designing/developing/porting applications across RDBMS.
2. There can be only one Primary Key defined on the table where as you can have many unique indexes defined on the table (if needed).
3. Also, in the case of SQL Server, if you go with the default options then a Primary Key is created as a clustered index while the unique index (constraint) is created as a non-clustered index. This is just the default behavior though and can be changed at creation time, if needed.
So, if the unique index is defined on not null column(s), then it is essentially the same as the Primary Key and can be treated as an alternate key meaning it can also serve the purpose of identifying a record uniquely in the table.

What index is suitable for a table with no unique columns and no primary key

alpha
beta
gamma
col1
col2
col3
100
1
-1
a
b
c
100
1
-2
d
e
f
101
1
-2
t
t
y
102
2
1
j
k
l
Sample data above and below is the dataype for each one of them
alpha datatype- string
beta datatype-integer
gamma datatype-integer
col1,col2,col3 are all string datatypes.
Note:columns are not unique and we would be using alpha,beta,gamma to uniquely identify a record .Now as you see my sample data this is in a table which doesnt have index .I would like to have a index created covering these columns (alpha,beta,gamma) .I
beleive that creating clustered index having covering columns will be better.
What would you recommend the index type should be here in this case.Say data volume is 1 milion records and we always use the alpha,beta,gamma columns when we filiter or query records
what index is suitable for a table with no unique columns and primary key?
col1
col2
col3
Mudassar

Many thanks for your explanation .
When I tried querying using the below query on my heap table the sql server suggested to create NON CLUSTERED INDEX INCLUDING columns ,[beta],[gamma] ,[col1]
,[col2] ,[col3]
SELECT [alpha]
,[beta]
,[gamma]
,[col1]
,[col2]
,[col3]
FROM [TEST].[dbo].[Test]
where [alpha]='10100'
My question is why it didn't suggest Clustered INDEX and chose NON clustered index ?
Mudassar

Using UNUSABLE on Unique Index gives "initially in unusable state" error

I am doing the following:
1. Truncate table
2 Alter PK Index Disable
2. Alter Unique Index Unusable
3. Insert /*+ APPEND NOLOGGING*/ into my table
My problem is, I get an "ORA-26026: unique index ... initially in unusable state" error when I try to do the Insert. If I make the Unique index non-unique it isn't a problem. If I drop the index and recreate it its not a problem - so uniqueness doesn't appear to be the issue. Can you not use UNUSABLE with a Unique index, I couldn't find any reference to this in the 10g docs.
I am using 10.1.0.4.
Thanks
Richard

26026, 0000, "unique index %s.%s initially in unusable state"
//* Cause: A unique index is in IU state (a unique index cannot have
//* index maintenance skipped via SKIP_UNUSABLE_INDEXES).
//* Action: Either rebuild the index or index partition, or use
//* SKIP_INDEX_MAINTENANCE if the client is SQL*Loader.

ORA-1779?? (I have unique index defined)

I execute the query:
UPDATE
(select rec.cod_instalacion_marca cod_instal_marca_RECLAMAC, ins.cod_instalacion_marca cod_instal_marca_DIM_INST_MAR
from ods.RECLAMAC rec
INNER JOIN master_dwh.DIM_MODELOS mod ON (rec.cod_modelo = mod.cod_modelo)
INNER JOIN master_dwh.DIM_INSTAL_MARCAS ins ON (rec.taller_implicado = ins.cod_instalacion and mod.cod_marca = ins.cod_marca))
SET cod_instal_marca_RECLAMAC = cod_instal_marca_DIM_INST_MAR
And I received the error:
ORA-01779: cannot modify a column that maps to a non-key preserved column
But I have:
*) Primary key in the field: ins.cod_instalacion_marca (table: master_dwh.DIM_INSTAL_MARCAS)
*) Unique Key in the fields: ins.cod_instalacion + ins.cod_marca (table: master_dwh.DIM_INSTAL_MARCAS).
How can I solve it???
Thanks very much!

Iâm sorry,
But the table RECLAMAC is the table I want to modify!!! I canât define unique key in this field (rec.cod_instalacion_marca ) because is the field that I want to modify and the values could repeat and that is correct.
I read for example the AskTom Followup:
You NEED a primary key/unique constraint on object_id in T1 to ensure that each row in T joins to AT MOST 1 row in T1.
Consider, if T had:
OBJECT_NAME OBJECT_ID
ABC xxxx
and T1 had:
OBJECT_NAME OBJECT_ID
ABC 123
ABC 456
what should be the outcome of:
ADHOC@VOYAGER> update
2 (select t.object_id toid,t1.object_id t1oid
3 from t,t1
4 where t.object_name=t1.object_name
5 and upper(t.object_name)='PRIMARY_SALESFORCE')
6 set toid=t1oid;
should T have 123 or 456 and under what circumstances? Since the outcome of
that update is 100% AMBIGOUS, we do not permit it. We need to ensure key
preserved-ness and do that with a primary key/unique constraint.
You need that index anyway typically for performance.
But my T1 table in the AskTom example is DIM_INSTAL_MARCAS and I have defined the unique key: ins.cod_instalacion + ins.cod_marca
Look at this:
If I create the field cod_marca in the table RECLAMAC and execute this query, it is executed OK!!!!!!
UPDATE
(select rec.cod_instalacion_marca cod_instal_marca_RECLAMAC, ins.cod_instalacion_marca cod_instal_marca_DIM_INST_MAR
from ods_clientes.EXP_RECLAMACIONES_EXPEDIENTES rec
INNER JOIN maestros_dwh.DIM_INSTALACIONES_MARCAS ins ON (rec.taller_implicado = ins.cod_instalacion and rec.cod_marca = ins.cod_marca))
SET cod_instal_marca_RECLAMAC = cod_instal_marca_DIM_INST_MAR
But if I execute:
UPDATE
(select rec.cod_instalacion_marca cod_instal_marca_RECLAMAC, ins.cod_instalacion_marca cod_instal_marca_DIM_INST_MAR
from ods.RECLAMAC rec
INNER JOIN master_dwh.DIM_MODELOS mod ON (rec.cod_modelo = mod.cod_modelo)
INNER JOIN master_dwh.DIM_INSTAL_MARCAS ins ON (rec.taller_implicado = ins.cod_instalacion and mod.cod_marca = ins.cod_marca))
SET cod_instal_marca_RECLAMAC = cod_instal_marca_DIM_INST_MAR
I receive the error ORA-01779: cannot modify a column that maps to a non-key preserved column
I NEED IT...
What unique index I have to create?
Thanks very much!

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

Hi, all.
The db is 11.2.0.3 on a linux machine.
I made a unique index unusable, and issued a dml on the table.
Howerver, oracle gave me ORA-01502 error.
In order to avoid ORA-01502 error, do I have to drop the unique index ,and do bulk dml, and recreate the index?
Or Is there any other solution without re-creating 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 stateThanks in advance.
Best Regards.

Hi. all.
The following is from "http://docs.oracle.com/cd/E14072_01/server.112/e10595/indexes002.htm#CIHJIDJG".
Is there anyone who can show me a tip to avoid the following without dropping and re-creating an unique index?
•DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
Unusable indexes
An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is if you want to improve the performance of bulk loads. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later recreating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then just rebuild it. You can create an index in the unusable state, or you can mark an existing index or index partition unusable. The database may mark an index unusable under certain circumstances, such as when there is a failure while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter.
When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
•DML statements against the table proceed, but unusable indexes are not maintained.
•DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
•For non-partitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
•For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and non-partitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
When SKIP_UNUSABLE_INDEXES is FALSE, then:
•If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
•For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.Thanks in advance.
Best Regards.

Constantly inserting into large table with unique index... Guidance?

Hello all;
So here is my world. We have central to our data monitoring system an oracle database running Oracle Standard One (please don't laugh... I understand it is comical) licensing.
This DB is about 1.7 TB of small record data.
One table in particular (the raw incoming data, 350gb, 8 billion rows, just in the table) is fed millions of rows each day in real time by two to three main "data collectors" or what have you. Data must be available in this table "as fast as possible" once it is received.
This table has 6 columns (one varchar usually empty, a few numerics including a source id, a timestamp and a create time).
The data is collect in chronological order (increasing timestamp) 90% of the time (though sometimes the timestamp may be very old and catch up to current). The other 10% of the time the data can be out of order according to the timestamp.
This table has two indexes, unique (sourceid, timestamp), and a non unique (create time). (FYI, this used to be an IOT until we had to add the second index on create time, at which point a secondary index on create time slowed the IOT to a crawl)
About 80% of this data is removed after it ages beyond 3 months; 20% is retained as "special" long term data (customer pays for longer raw source retention). The data is removed using delete statements. This table is never (99.99% of the time) updated. The indexes are not rebuilt... ever... as a rebuild is about a 20+ hour process, and without online rebuilds since we are standard one, this is just not possible.
Now what we are observing is that the inserts into this table
- Inserts are much slower based on a "wider" cardinality of the "sourceid" of the data being inserted. What I mean is that 10,000 inserts for 10,000 sourceid (regardless of timestamp) is MUCH, MUCH slower than 10,000 inserts for a single sourceid. This makes sense to me, as I understand it that oracle must inspect more branches of the index for uniqueness, and more different physical blocks will be used to store the new index data. There are about 2 million unique sourceId across our system.
- Over time, oracle is requesting more and more ram to satisfy these inserts in a timely matter. My understanding here is that oracle is attempting to hold the leafs of these indexes perpetually buffers. Our system does have a 99% cache hit rate. However, we are seeing oracle requiring roughly 10GB extra ram per quarter to 6 months; we're at about 50gb of ram just for oracle already.
- If I emulate our production load on a brand new, empty table / indexes, performance is easily 10x to 20x faster than what I see when I do the same tests with the large production copies of data.
We have the following assumption: Partitioning this table based on good logical grouping of sourceid, and then timestamp, will help reduce the work required by oracle to verify uniqueness of data, reducing the amount of data that must be cached by oracle, and allow us to handle our "older than 3 month" at a partition level, greatly reducing table and index fragmentation.
Based on our hardware, its going to be about a million dollar hit to upgrade to Enterprise (with partitioning), plus a couple hundred thousand a year in support. Currently I think we pay a whopping 5 grand a year in support, if that, total oracle costs. This is going to be a huge pill for our company to swallow.
What I am looking for guidance / help on, should we really expect partitioning to make a difference here? I want to get that 10x performance difference back we see between a fresh empty system, and our current production system. I also want to limit oracles 10gb / quarter growing need for more buffer cache (the cardinality of sourceid does NOT grow by that much per quarter... maybe 1000s per quarter, out of 2 million).
Also, please I'd appreciate it if there were no mocking comments about using standard one up to this point :) I know it is risky and insane and maybe more than a bit silly, but we make due with what we have. And all the credit in the world to oracle that their "entry" level system has been able to handle everything we've thrown at it so far! :)
Alright all, thank you very much for listening, and I look forward to hear the opinions of the experts.

Hello,
Here is a link to a blog article that will give you the right questions and answers which apply to your case:
http://jonathanlewis.wordpress.com/?s=delete+90%25
As far as you are deleting 80% of your data (old data) based on a timestamp, then don't think at all about using the direct path insert /*+ append */ as suggested by one of the contributors to this thread. The direct path load will not re-use any free space made by the delete. You have two indexes:
(a) unique index (sourceid, timestamp)
(b) index(create time)
Your delete logic (based on arrival time) will smatch your indexes as far as you are always deleting the left hand side of the index; it means you will have what we call a right hand index - In other words, the scattering of the index key per leaf block is certainly catastrophic (there is an oracle iternal function named sys_op_lidbid that will allow you to verify this index information). There is a fairly chance that your two indexes will benefit from a coalesce as already suggested:
           ALTER INDEX indexname COALESCE;This coalesce should be investigated to be done on a regular basis (may be after each 80% delete) You seem to have several sourceid for one timestamp. If the answer is yes you should think about compressing this index
    create index indexname (sourceid, timestamp) compress;
or
    alter index indexname rebuild compress;     You will do it only once. Your index will have a smaller size and may be more efficient than it is actually. The index compression will add an extra CPU work during an insert but it might help improving the overal insert process.
Best Regards
Mohamed Houri

Hi i have created a unique index on table on 3 columns.

Hi i have created a unique index on table on 3 columns.I want to know when i have 2 records
which contain same values in 2 fields and the 3rd field contains a null
will unique index allow me to insert these records.

Robert Angel wrote:
This must be one time when null = null. ;)
regards,
Robert.Not really, it is more the case that the non-null columns need to be unique. Your second attempt failed because there was already an index entry with 'a', 'b', and the lack of a value for column c gave Oracle no way to differentiate between the two rows so they are not unique.
A subtle, but conceptually important difference. :-)
John

How to create unique index on a View

Hi All,
11.2.0.1
How do I create an index on a view or any workaround that my view wont get duplicates?
SQL> create unique index indx01 on db_backup_details_vw(id);
create unique index indx01 on db_backup_details_vw(id)
ERROR at line 1:
ORA-01702: a view is not appropriate here
Thanks a lot,
Kinz

I'm thinking of using a distinct clause here.
if i get 5 duplicate rows in my selection set because of the join condition, can't i discard the remaining 4 using a distinct clause.
Observe this
SQL> select * from a;
T1 T2
1 4
2 4
3 4
SQL> select * from b;
T1 T2
1 4
2 5
in both a,b t1 is the primary key. so we'll write a join on t2 (non PK).
SQL> select b.t1,b.t2 from a,b where a.t2=b.t2;
T1 T2
1 4
1 4 -- duplicates
1 4
Now create view with distinct clause
create view ab as select distinct b.t1,b.t2 from a,b where a.t2=b.t2;
SQL> select * from ab;
T1 T2
---------- ---------- -- no duplicates
1 4
CSM

Unique index vs non-unique index

Similar Messages

Maybe you are looking for