Operating System - HP-UX
1745877 Members
4327 Online
108723 Solutions
New Discussion юеВ

HP-UX Error : 22 /Oracle 7.3.4

 
SOLVED
Go to solution
Edgar Canaan
Occasional Advisor

HP-UX Error : 22 /Oracle 7.3.4

Hi all,

Is anybody familiar with this error I get everytime Oracle tries to read this specific datafile:

KCF: write/open error dba=0x90020038 block=0x20038 online=1
file=36 /u230/oradata/PRTX/RTX_200103.dbf
error=7375 txt: 'HP-UX Error: 22: Invalid argument
Additional information: 131128'
error 1242 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01114: IO error writing block to file 36 (block # 131128)
ORA-01110: data file 36: '/u230/oradata/PRTX/RTX_200103.dbf'
ORA-07375: sfwfb: lseek error, unable to seek to requested block.
HP-UX Error: 22: Invalid argument
Additional information: 131128

--------------------------
In a world without walls there is no need for gates and windows...
10 REPLIES 10
Thierry Poels_1
Honored Contributor

Re: HP-UX Error : 22 /Oracle 7.3.4

Hi,
I'm afraid that this line tells it all :

"ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode"

Media failure, a bad spot on your disk. Try some things on this datafile outside of oracle to get this confirmed : wc, tar, dd, ...
They should also complain if you have a bad disk. How about you backup log of last night? no errors on the specified datafile ??

good luck,
Thierry.
All unix flavours are exactly the same . . . . . . . . . . for end users anyway.
A. Clay Stephenson
Acclaimed Contributor

Re: HP-UX Error : 22 /Oracle 7.3.4

It looks as though the file in question is corrupt. My first step would be to attempt to copy the file to another location and see if you get OS errors. I would then do a CRC checksum via cksum comparing the original and the copy.
If it ain't broke, I can fix that.
Edgar Canaan
Occasional Advisor

Re: HP-UX Error : 22 /Oracle 7.3.4

I already tried dd successfuly and I did not get any error for this datafile in backup log.

We restored the whole database in a test enviorment and seems to be ok there...no error for this datafile.

Any other sugestion? where can I search for this kind of errors, i.e HP-UX Error:22 for more information?
In a world without walls there is no need for gates and windows...
A. Clay Stephenson
Acclaimed Contributor

Re: HP-UX Error : 22 /Oracle 7.3.4

The only other thing that occurs to me is that
your blk no X an assumed 8K blksize is very close to 1GB, a not uncommon ulimit setting.
Check the ulimit value for oracle on the production instance. Also have you resized a datafile recently or does the table need to autoextend and cannot because of disk space/ulimit constraints?
If it ain't broke, I can fix that.
Edgar Canaan
Occasional Advisor

Re: HP-UX Error : 22 /Oracle 7.3.4

nope...we have not resized datafile...this is my output for ulimit:

For production:
/home/oracle:: >ulimit
4194303

Test:
/home/oracle:: >ulimit
unlimited

But this is for core files limits...isn't it?
In a world without walls there is no need for gates and windows...
A. Clay Stephenson
Acclaimed Contributor

Re: HP-UX Error : 22 /Oracle 7.3.4

No, the ulimit w/o args is the file size ulimit. Try using ulimit -a to show all limits such as number of file descriptors
If it ain't broke, I can fix that.
Edgar Canaan
Occasional Advisor

Re: HP-UX Error : 22 /Oracle 7.3.4

Production (as root)

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 81612
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048

Test (as root)
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 81612
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048
In a world without walls there is no need for gates and windows...
A. Clay Stephenson
Acclaimed Contributor

Re: HP-UX Error : 22 /Oracle 7.3.4

You should probably use ulimit -a as user oracle. My last thought after searching the ORACLE support site is that you may be using asynch I/O and an IO operation did not actually complete though dbwriter thought it did.
If it ain't broke, I can fix that.
R. Allan Hicks
Trusted Contributor
Solution

Re: HP-UX Error : 22 /Oracle 7.3.4

In addition to the other suggestions, you might want to use the utilitu dbv. dbv is the dbverify utility. It will probably tell you what Oracle did. dbv verifies the internal structures of the datafile. If you are in archive mode, you can recover.

If you are in non-archive mode, the book says that you can restore the last cold backup. You might save some data by doing exports before you restore, and re-import the data after the restore. You may have some success depending upon how the damaged file interacts with the inferental integrity.

For archive mode....

The Oracle 8i Backup and Recovery Workshop book says

"There are three ways to recover from datafile corruptions and each will depend on the degree of corruption and the amount of data that the business operation can afford to lose.

Method 1 - If an index is available on the table in which the corrupted block resieds, data can be retrieved using index scans:

select distinct(key) from corrupted_table where key> (lowest value for the key) and substr(rowid,1,8) = corrupt_block_id order by 1;

Method 2 - Another method is to select all rows below and above the corrupted block and select them into a new table:

create new_table as select * from corrupt_table where key > (lowest value for the key and key NOT IN (key_list);

Method 3 - The third method and probably the most complete form of recovery complete form of recovery is to restore the datafile in which the corrupted block exists, and perform a recovery in that data file.

In all cases you should do a complete backup of the datafile prior to correcting the corrupted block errors. You should investigate other reasons as to why a corruption occurred."

I'm not sure what the first method really does for you, but the 2nd and 3rd are pretty clear. Method 3 only works with databases where archiving is active. If you are not archiving, and you have a production database, you should be archiving.

Method 3 requires you to go through the lost datafile restoration process. Being basically scared of these things.

Take a complete cold backup of database.

I would rename your datafile so that you can get back to where you started if you had to.

start the datbase with the mount option, but not open it.
svrmgr> STARTUP MOUNT
Alter the database to take the offending file offline

ALTER DATABASE DATAFILE '/fullpath/your_datafile_here' OFFLINE;

Restore a previous backup of just the damaged file, and make sure you have all of the archive logs available either on the disk or tape.

Open the database

ALTER DATABASE OPEN;

Recover the tablespace. You will be prompted for archive logs as Oracle needs them.

RECOVER TABLESPACE your_tablespace_name_here

Put the tablespace back on line

ALTER TABLESPACE your_tablespace_name_here;

Do these things and you should be able to do a complete recovery.


I hope this helps.
"Only he who attempts the absurd is capable of achieving the impossible