Error message: ORA-08103: object no longer exists. [message #677709] |
Tue, 08 October 2019 09:01  |
 |
abhilashrn
Messages: 12 Registered: October 2019
|
Junior Member |
|
|
I have a scenario with two ETL batch jobs(Lets call them Job A and Job B) belonging to different subject areas with no dependency among each other, but operating on same table.
job A has the following statement
ALTER TABLE <TABLENAME> TRUNCATE PARTITION (PNAME) UPDATE INDEXES
job B does a simple select * from the same table above
Now the issue is this. On rare occasions they kind of overlap or run simultaneously causing the below error in second batch job (which has the select statement)
Error message: ORA-08103: object no longer exists.
We are aware that the root cause is because it is trying to select from the table when the partition is being truncated. We even were able to reproduce it in the TEST environment where we ran the batch job 2 and on a separate toad session we ran the Truncate PArtition query
As I said this happens on only once or twice a month when these jobs run simultaneously. This is completely not in our control as we cant set dependencies between these 2. As i said they belong to different domains and we cant just make 1 job wait for another
In this case, is there something which can be done in the Job B SELECT query such that this error does not happen ?
Version Info:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
|
|
|
|
|
|
|
Re: Error message: ORA-08103: object no longer exists. [message #677726 is a reply to message #677723] |
Wed, 09 October 2019 05:31   |
 |
Michel Cadot
Messages: 68757 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
Quote:Can you elaborate with a pseudo code?
select ...
when exception ORA-08103 then
wait a little bit
goto select
end when
You can also add a counter in the loop and re-raise the exception of the exceptions exceed a number of time to avoid an infinite loop.
You can also use a "select for update" it will try to lock the table and so was blocked by the truncate but the counterpart is that it will then block other treatments it should not with "for update".
[Updated on: Wed, 09 October 2019 05:31] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Error message: ORA-08103: object no longer exists. [message #677763 is a reply to message #677761] |
Fri, 11 October 2019 06:13   |
Bill B
Messages: 1971 Registered: December 2004
|
Senior Member |
|
|
Michel gave you the code to handle the error, all you had to do was expand on what he showed.
DECLARE
Cnt NUMBER;
No_object EXCEPTION;
PRAGMA EXCEPTION_INIT (No_object, -8103);
My_col VARCHAR2 (100);
BEGIN
Cnt := 1;
WHILE Cnt > 0
LOOP
BEGIN
SELECT Col1 INTO My_col FROM My_table;
Cnt := 0;
EXCEPTION
WHEN No_object
THEN
IF Cnt = 10
THEN
RAISE No_object;
END IF;
-- sleep for 5 seconds. The user running the dbms_lock
-- procedure must be given permission by the dba to
-- access the package.
DBMS_LOCK.Sleep (5);
Cnt := Cnt + 1;
END;
END LOOP;
END;
/
|
|
|
|
|
|
|
|
|
|
Re: Error message: ORA-08103: object no longer exists. [message #677777 is a reply to message #677774] |
Fri, 11 October 2019 08:13   |
cookiemonster
Messages: 13966 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
That's just repeating your initial post without giving any meaningful additional details.
What is the tool/program/language that is running these jobs?
Is it PL/SQL in a stored procedure
Is it a custom program written in java or c++ or something?
Is it some third party tool?
Without knowing what is running that select statement we can't give you any advise about to implement to way of handling the error beyond what we've already posted.
|
|
|
Re: Error message: ORA-08103: object no longer exists. [message #677809 is a reply to message #677768] |
Sat, 12 October 2019 09:14  |
 |
EdStevens
Messages: 1376 Registered: September 2013
|
Senior Member |
|
|
abhilashrn wrote on Fri, 11 October 2019 07:04The existing query is not a PL/SQL block. It is a simple SQL Select * from TABLE
Putting 'select * ' in production code is a bug waiting to happen. If you use 'select *', your code will break the first time someone modifies the table definition. 'Select *' is fine for one-off, ad hoc code. But production code should KNOW EXACTLY what columns are to be dealt with, and code accordingly.
|
|
|