While running the DbUunit test cases I am getting following exception:
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (EMP_SYS.PK_EMP_ID) violated.
After analyzing I understood that DatabaseOperation CLEAN_INSERT will just clean the data from the table but not reset the sequence.
Can anyone help me out to find any way to reset the SEQUENCE value through DB unit?
Thanks in advance...!!
In your dataset.xml file you must specify tables in correctly insertion order, this means, the basic tables first and then the related tables. This way DatabaseOperation.CLEAN_INSERT will delete tables in correctly delete order too (related tables first and then basic tables).
Hope this helps.
Related
We have a multi-threaded batch job ending up in deadlock. I am getting conflicting answers from our dba's as to what actually causes the deadlock.
Caused by: java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
The error output references the sql for inserting into table A. Every row going into table A should be unique. Table A has foreign keys on two other tables, both of which are indexed and primary keys made up of two columns. Many rows in Table A can point to the same FK in the parent tables. Our code handles FK errors by trying to insert into parent tables and then trying into Table A again.
The sql in the trace log refers to the Table A insert sql (does not show param binding values). Does this mean definitively that there are two identical sql statements trying to be inserted into Table A in which case our prior logic is not thread-safe somewhere? Or could it really be that there are two inserts both referencing an unsatisfied FK? And the deadlock occurs from our error handling in trying to insert into the parent table. If so, would the sql in the trace not then reference the parent table sql?
Or perversely, does the original insert attempt put a lock on the row and then after handling the error, does the second attempt of the insert cause the deadlock? Any further debugging assistance?
There's not much info to work with, but my guess would be that two threads are trying to insert the same rows into one of the 'two other tables' at the same time. Idea on debugging below
Use a trigger on table A and on the other two tables ( 3 triggers in total) that write the inserted data to logging tables in an autonomous transaction that commits. This way you can see the uncommitted inserts that were rolled back due to the deadlock (the rows that exists in the logging tables but not in the actual tables are the ones that were rolled back).
HTH, KR
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 error: Message: oci_execute (): ORA-00001: unique constraint (SCHEMA_NAME.NAME CONSTRAINT) violated
I wonder if I do not how to handle the error more simply, more generic.
Because otherwise I will have to work on each function of the models to check the data before adding, for no duplications and not give the error noted above.
Does anyone know a simple way to solve this?
Thanks.
There is a hint that can be specified that will allow the statement to succeed without inserting the duplicated data. It can be useful for replication or bulk data loading where the job may attempt to insert the same data multiple times. I wouldn't recommend it as part of a user application.
"The IGNORE_ROW_ON_DUPKEY_INDEX hint applies only to single-table INSERT operations. It is not supported for UPDATE, DELETE, MERGE, or multitable insert operations. IGNORE_ROW_ON_DUPKEY_INDEX causes the statement to ignore a unique key violation for a specified set of columns or for a specified index. When a unique key violation is encountered, a row-level rollback occurs and execution resumes with the next input row."
I'm encountering this error multiple times, but it appears to be random.
I perform an INSERT query where I attempt to insert a BLOB file into a designated table.
I do not know if there's a connection between the BLOB and the error.
Worth mentioning that the table is partitioned.
Here is the complete query:
INSERT INTO COLLECTION_BLOB_T
(OBJINST_ID, COLINF_ID, COLINF_PARTNO, BINARY_FILE_NAME, BINARY_FILE_SIZE, BINARY_FILE)
VALUES (:p1, :p2, :p3, :p4, :p5, EMPTY_BLOB());
This is the only INSERT/UPDATE into this table in the entire application.
So I doubt that any other query is locking it, and the error is not about a locked resource.
What can be the cause?
As I've mentioned, this appears to occur randomly.
Thanks in advance.
The table is partitioned as I've mentioned, so between midnight - 3:00AM the partitioned changes and this under some instances the error occurs.
I'm deleting this row from a table and it has a bunch of cascades on the FKs and eventually it gives me this error:
ERROR: insert or update on table "foo_route" violates foreign key constraint "foo_route_bar_fk"
SQL state: 23503
Detail: Key (bar_key)=(2176) is not present in table "bar".
foo_route_bar_fk is defined like this:
ALTER TABLE foo_route
ADD CONSTRAINT foo_route_bar_fk FOREIGN KEY (bar_key) REFERENCES bar (bar_key)
MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE;
I'm getting this error by deleting a table unrelated to both of these. I think what's happening is a trigger or a cascade is causing this error, but it's difficult to find out why.
My question is, how do you debug issues like this in postgresql? What are the series of steps that caused this error? Postgresql only tells me the result of the last thing it did before it failed. If this were code the error would give an extremely helpful stack trace. Is there a way to see something like that in Postgresql?
Typically your postgresql log will include the statement which triggered the error. That should allow you to follow the chains of cascading events.
One thing I would suggest however is that you might want to draw out a map of fkeys and look at the mappings of ON events on foreign keys. If it were me I would start with a schema only dump or pg_autodoc output, and go from there. The obvious problem is that you have deletes cascading in cases where it can't so you need to take a look and rethink things here.