i am getting this error in alert log file from past one month stating that

ORA-12012: error on auto execute of job 8884
ORA-08103: object no longer exists

But unable to find root cause, as i am not able to find the object which its stating its does not exists.

Please help in this regard .....as i am afraid that it might be due to block corruption...

Thanks a lot for quick response !!!

But how to find which object is corrupted due to block corruption.....as its production database.

If you are unable to find that object now, doesn't it mean that the object has been dropped ? If the job errored with ORA-8103 it would mean that the object was dropped while the job was running. Why jump to a "conclusion" that it is block corruption ?
Please re-read that MetaLink Note #268302.1

Possibly the object is a an Index or a Table Partition which is getting rebuilt (by some other job) while job 8884 is running.

Edited by: Hemant K Chitale on Oct 16, 2008 3:12 PM

Hi,

try to use the below query to find the facture Block

select ds.*
from dba_segments ds, sys.uet$ e
where ds.header_file=e.segfile#
and ds.header_block=e.segblock#
and e.header_file=
and between e.block# and e.block#+e.length-1;

see if the corrupted Blocks belong index segments you can easily solve the problem, because all the table data required for re-creating the index is still accessible, you can drop and re-create the index (the block will be reformatted when it's taken from the free-space list and reused for the index).

In case of table segment, then

Using datafile backups and archived redo log files, you can do a recovery of the datafile that holds the corrupted data block. You must be sure, however, that the data block was not already corrupted in the backup datafile.

If you regularly make dump files using the Export utility, another option could be to restore the table segment by using the Import utility. Of course, you can do this only if the version of the table as recorded in the dump file is acceptable or not too old. Note that Before doing the table import, you must drop the current table, which deallocates the bad block.

The last option involves using SQL to select as much data as possible from the current corrupted table segment and saving the selected rows into a new table. Make sure that select data that is stored in segment blocks that precede the corrupted block by using a full table scan (via a cursor fetching rows one by one and at the same time saving them to a new table).

Rows that are stored in blocks after the corrupted block cause a problem, because a full table scan will never reach them. However, you can still fetch these rows by using rowids (single-row lookups).

- Pavan Kumar N