Oracle: selective uniqueness index issue with update

I have created selective unique index

CREATE UNIQUE INDEX fn_unique_idx 
    ON table1 (CASE WHEN is_deleted='N' THEN id ELSE null END,
               CASE WHEN is_deleted='N' THEN name ELSE null END,
               CASE WHEN is_deleted='N' THEN type ELSE null END);

So at any point of time I want only one entry with is_deleted 'N' for (id, name, type).

Insertion works fine i.e. it allows to enter mulitple is_deleted 'Y' and thows unique constriant exception when I try to insert with is_deleted = 'N' which is expected.

But when I try to update it is thowing oracle error:

ORA-00600: internal error code, arguments: [qctVCO : bfc], [1], [0], [1], [871], [1], [2], [875], [], [], [], [] 


SQL : UPDATE table1 set is_deleted = 'Y' where id = 1, name = 'foo' and type =bar';

I want to set this current ent开发者_如何学编程ry as deleted and insert a new entry with updated data and is_deleted = 'N'. This is basically for maintaining the history.

Can someone help me fix this issue.

Thanks.

that type of error is an oracle internal error - aka a bug...

what patch version are you on? perhaps go the the current one just in case.

If I understand what you are trying to accomplish, you want to be able to have several rows with the same (id, name, type). For one of these rows is_deleted = 'N' and for the rest of them is_deleted = 'Y'.

Is that correct?

If so, let me offer some ideas:

1. Remove the is_deleted field. Instead, have a version field and whatever the latest version is, this is the row which is not deleted. The unique constraint/index then naturally covers (id, name, type, version). This can complicate querying though.
2. Introduce 3 new fields: archive_id, archive_name, archive_type. The unique constraint still covers the original (id, name, type). The row is "deleted" by moving values to archive_* fields and NULL-ifying the original fields. This should work because tuples that contain all NULLs are not included in the (unique) index.
3. Have a separate table for archival data, without the unique constraint.
4. Maybe use a CONSTRAINT UNIQUE instead of the UNIQUE INDEX?

Also, let us know if there are any referential integrity constraints in play?

Agree with Branko on point #3. You could also add START & END dates to this separate table for archival data.