We have a header table which has a primary key and a detail table which references the header table (Foreign key). Both the header and detail tables are monthly partitioned. These tables contain 5 years of data, so when a new month comes the data for the first partition is deleted and so on. So that always only 5 years of data is maintained.
The problem that we are facing is while dropping the partition from the header we are getting the following error:
ORA-02266: unique/primary keys in table referenced by enabled foreign keys
ORA-06512: at "SCH_TEST.DROP_PARTITION", line 51
ORA-06512: at line 16 (DBD ERROR: OCIStmtExecute)
We have deleted the referencing data from the detail table, still the above error is occuring.
One way for solving this error is to disable the constraint, drop the partition and then enable the constraint. Is there any other approach/solution for this issue.
Database is Oracle 11G.
Edit 1: I'm able to drop the partition from header table if i delete the data in the partition first and then drop it. Any idea how this works?
Oracle 11g introduced partition by reference for this. Are you using reference partitioning? If not you need to change your partitioning scheme.
I chose "disable the reference constraint and then drop the partition" approach, as i did not find any other solution for this issue.
Posting this information here and accepting it as answer so that it may help others who search for the same issue.
Related
I have 2 schemas TBCAM and AR_TBCAM. There is a table called BKP_COST_EVENT in TBCAM which I have partitioned and I have moved the partition data into another simple table in AR_TBCAM schema called BKP_COST_EVENT_P2016. Now the data has moved to AR_TBCAM schema via this query
ALTER TABLE BKP_COST_EVENT EXCHANGE PARTITION P2016 WITH TABLE AR_TBCAM.BKP_COST_EVENT_P2016 INCLUDING INDEXES WITHOUT VALIDATION;
Now I want to bring the partition data back into the original table BKP_COST_EVENT.
But when I run this query standing on AR_TBCAM
ALTER TABLE BKP_COST_EVENT_P2016 EXCHANGE PARTITION P2016 WITH TABLE TBCAM.BKP_COST_EVENT INCLUDING INDEXES WITHOUT VALIDATION;
It is giving this error:
Error starting at line : 1 in command -
ALTER TABLE BKP_COST_EVENT_P2016 EXCHANGE PARTITION P2016 WITH TABLE TBCAM.BKP_COST_EVENT INCLUDING INDEXES WITHOUT VALIDATION
Error report -
ORA-14501: object is not partitioned
14501. 00000 - "object is not partitioned"
*Cause: Table or index is not partitioned. Invalid syntax.
*Action: Retry the command with correct syntax.
Can anyone suggest what am I doing wrong? Or how to bring/restore the data back to my TBCAM schema table BKP_COST_EVENT.
I have not dropped the partition p2016 in the original BKP_COST_EVENT
In exchange partition syntax first table should be the one which is partitioned, second should be unpartitioned one.
So, your first command was correct but 2nd command is wrong.
If you are bringing back data to same table's partition run the same command again.
ALTER TABLE BKP_COST_EVENT EXCHANGE PARTITION P2016 WITH TABLE AR_TBCAM.BKP_COST_EVENT_P2016 INCLUDING INDEXES WITHOUT VALIDATION;
Also, if there are no indexes to be moved, its better not to use including indexes clause.
The below statement consumes a huge amount of time for a table containing 70 million records.
ALTER TABLE <table-name> ENABLE CONSTRAINT <constraint-name>
Does table scan all rows while enabling the constraint.
Even though the constraint got enabled, the process just hung for more than 5 hours.
Any ideas on how this can be optimized
As guys said before, depends on constrain type it is possibility skip validate existing data by ALTER TABLE ENABLE NOVALIDATE CONSTRAINT . And check this data by some additional procedure or query.
You can find documentation about that here https://docs.oracle.com/cd/B28359_01/server.111/b28310/general005.htm#ADMIN11546
I recently received a case which my client came across the ORA-00001: unique constraint violated error. This happened when a program tried to truncate two tables and then insert data into them.
From the error-log file, the truncate step was completed,
delete from INTERNET_GROUP
delete from INTERNET_ITEM
BUT right after this, the insertion to the Internet_group table triggered the ORA-00001 error. I am wondering if there is any database settings related to this error? I never used Oracle and am wondering if Oracle puts a lock on a row with SELECT statement, in which case the row is locked and not deleted somehow? Any help is appreciated.
Please know that there is a difference between truncate and delete. You say you truncated the table, but you mention "delete from" . That is entirely different.
If you're sure you want to empty the tables, try replacing with
truncate table internet_group reuse storage;
Mind you that a commit is not necessary with the truncate statement as this is considered a DDL (data definition language) statement and not a DML (Data modification language) statement like updates and deletes.
Also, there is no row locking on selects. But changes are only applied and visible for other sessions in the database when commit-ed.
I guess that is wat happened; you deleted the records but did not execute a commit (yet) and subsequently inserted new records.
edit:
I now realize you're probably inserting multiple records....
The other option might be, that the data itself causes a violation. Can you please provide the constraints on the table? There must be a primary key or unique constraint. You might want to hold that against your dataset.
This question already has an answer here:
Use of FLASHBACK in Oracle
(1 answer)
Closed 6 years ago.
I am new to Oracle Advance concepts, In my application I have accidentally "truncate" the data. I am facing difficulty to
restore the truncated data. I googled about it alot, I found there is "FLASHBACK" command from oracle 10g. I tried it using timestamp approach in flashback
but I am getting the following error:
Error: The table definition has changed.
Could any body tell me how to get back my truncated table data?
Is it possible? If it is Please let me know the procedure to get back the data.
The error message is pretty clear. FLASHBACK is not available if you had DDL operations on the table (add or drop column, add or drop constraint, etc.) It's right there in the first paragraph in the documentation. http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9012.htm As Tim suggests - this is where backing up your data would have helped.
Edit: To be very precise, the wording in the Oracle documentation is (with my emphasis): Oracle Database cannot restore a table to an earlier state across any DDL operations that change the structure of the table. So adding or dropping a column will prevent the use of FLASHBACK since they change the structure of the table. TRUNCATE does not, so TRUNCATE by itself does not prevent FLASHBACK (although TRUNCATE is a DDL operation). I got carried away in the first paragraph with "add or drop constraint" - I actually don't know if that will prevent FLASHBACK; one can find out by experimenting.
I am trying to drop an index :
DROP INDEX PK_CHARGES
but I get this error
cannot drop index used for enforcement of unique/primary key
Why I am getting this error? I will provide further information if you need any.
How to solve it?
Edit I have no primary key in the table, but I found this weird index that I don't remember I had added:
index name = SYS_C0040476 which have the same columns
You can query the ALL_CONSTRAINTS performance view to see which constraint the index is used by, and which table it applies to, e.g:
select owner, constraint_name, constraint_type,
table_name, index_owner, index_name
from all_constraints
where index_name = 'PK_CHARGES';
I would expect the table name to be 'CHARGES', the constraint name to match the index name, and the constraint type to be 'P'. But since you have a table in mind, perhaps the names aren't following a helpful convention. Maybe an old version of the table was renamed, which would leave the constraints against the new name (e.g. CHARGES_BACKUP or something).
You said you click on the table, then on the view. Perhaps you're not looking at the table that the constraint/index is on; or perhaps you're looking at a view on top of the actual table. You also mention a SYS_ index on the same columns - which can't be on the same table. Do you have multiple similar tables, or access to multiple schemas? You shold run the above query for that index too. As mentions above, you might find an old version (or versions) of the table.
Once you've identified which table the constraint is on, you'll need to decide whether you should actually be keeping it, and if not you can remove it by dropping the constraint with an ALTER TABLE command.
The problem with
But I found this weird index that I dont rember I hadve add
comes because you didn't add it. You had a primary key, then you dropped it, but when you do that Oracle doesn't drop the associated unique index that every primary key has.
So when you drop a primary key you have to drop the unique index of that primary key, that amazingly has the same name as the primary key had.
So for dropping a MY_TABLE_PK you must do:
ALTER TABLE MY_TABLE DROP PRIMARY KEY DROP INDEX;
so you ensure that the index is dropped as well.
"from pl/sql I right click on the table"
The problem with IDEs is that they make us feel very productive, because we can do things with just a click instead of writing some code. This is a problem because when something unusual happens the IDE is no good for investigation and we lack the understanding of the underlying structure of the database which we need to help ourselves.
If you want to learn the Oracle database the worst thing you can do is download SQL Developer or PLSQL Developer or TOAD. They're all fine tools but the only people who should use them are the people who don't need to use them.
the following worked for me with unique index:
ALTER INDEX UX_CHARGES UNUSABLE
/
DROP INDEX UX_CHARGES
/
see: https://docs.oracle.com/cd/E18283_01/server.112/e17120/indexes004.htm#insertedID3