Oracle error

[HutchAdmin]

Dear All,

I am facing below problem in HPUX 11i in Superdome server.

The below is oracle trace.......



Node name: bscstest
Release: B.11.11
Version: U
Machine: 9000/800
Instance name: MIS
Redo thread mounted by this instance: 0
Oracle process number: 0
3074

*** SESSION ID:(16.36) 2004-05-20 08:32:58.569
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-01114: IO error writing block to file 202 (block # 138985)
ORA-27072: skgfdisp: I/O error
HP-UX Error: 25: Not a typewriter
Additional information: 138985
ORA-01114: IO error writing block to file 202 (block # 138985)
ORA-27072: skgfdisp: I/O error
HP-UX Error: 25: Not a typewriter
Additional information: 138985



can anybody help on this


Thanks in advance

[Hein van den Heuvel]

You have an IO problem in db-file 202.
SELECT file_name from dba_datafiles where file_number = 202;

(from memory. Check column names with 'describe dba_datafiles').

Once you have the file_name try for example a copy or dd to /dev/null to confirm the io problem.

You'll probably need to restore the backups and recover with archive logs.

good luck,
Hein.

[T G Manikandan]

Just check your /var/adm/syslog/syslog.log file.

check whether any of the disks have gone bad.


Revert

[HutchAdmin]

Hi Hien / mani

1. There is no error in syslog regarding disk faliure.

2. File no 202 does not exists in database.


point which i like to mention here in that we had recreated database after a crash on manday........


Thanks

[twang]

First of all, check the space available on your hard drive!
Then test the "problem disk"!

[HutchAdmin]

Dear Twang,

Filesystem is 61% used.....
and disk status is fine


Thanks

[twang]

It seems that the database or controlfile don't see the problem datafile, try to do a backup controlfile to trace to verify it:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

[Joseph Loo]

hi,

looks like some permission issue looking at Oracle Metalink:

Problem Explanation: ====================

If you created another user and the permissions on the datafiles that you are trying to migrate are 600 you can not perform a data migration. When the permissions are changed to 660 the migration completes successfully.

Solution Description:
=====================

You need to change the permissions on the datafiles to 660.

You must change the permissions on the datafiles you are trying to migrate to 660. Change to the directory where the datafiles are and type the following:

chmod 660 datafile.dbf

Solution Explanation:
=====================

If another user was created and you are trying to migrate a file as the new user you must have read and write permissions to the file.

hope is helps.

regards.

[Yogeeraj_1]

hi,

can you try to do a full database export?

If there is a problem with a table in particular, you may trap it there!

Then if it is a database block corruption or the like, you can still try to move the table to another tablespace (alter table move tablespace ).

hope this helps too!

regards
Yogeeraj

[Eric Antunes]

Hi HutchAdmin,

202 is the file# (file ID). Do the following to see the state,name, etc... of the datafile:

select *
from v$datafile
where file# = 202

And thiso one to see more about the specific block:

select *
from dba_extents
where block_id = 138985