Incorrect du and ls -lrt size

[sathish kannan]

Hi All,
We are using HPUX 10.20 on K460/4. In one of our filesystem today morning we had a bit of hickup with one of DBF file reporting incorrect "ls -lrt" and "du" size. When I do ls -lrt dbf file it comes with 4.3 GB whereas du shows it as just 2.1 GB. But the filesystem doesn't have enough space to grow to 4GB as because last night during our cold backup the file was just 2GB and filesystem has only 100 MB left. DBA's has confirmed me that the DB is corrupted now and we need to restore now. Does any one knows it why ? .

Config :- K460/4, 10.20
Disks :- VA7400
Oracle :-7.3.4

[sathish kannan]

Hi All,
I forgot to mention that problem exists even after we shutdown database. I ran fsck and status is OK. But the files were deleted before fsck was run.


Regards
Sathish

[Steven E. Protter]

dmesg should show an lbolt.

Most probably a disk or controller failure.

The filesystem is suddenly a lot smaller right?

Same thing happened to my oracle database when a disk dropped out from under it.

SEP

[Massimo Bianchi]

Hi,
there is another nice explanation.

First: i didn't know that oracle 7.3.4 had support for large files, are you sure that it is allowed ? And are the proper option activated on the 10.20, if it will be ?


Second: oracle used sparse files, when creating datafiles, not to use disk space scopeless.

A sparse file can have different size between du and ls.


ls reports what the file claims to be.
du reports the effective size on disk.

with sparse file, they can mismatch.

how do i create a sparse file ?

i open a file, i do a seek, i write 1 byte, i close the file.

space on disk: a couple of cytes
space claimed: all from the seek.

Are you sure that the database is corrupt ?

In which datafile, exactly in that?

Are you sure that you don't have the dafafile with autoexent ? It is known to corrupt files on 10.20 and 7.3.4, is largefiles is not properly set and ksh is used.....


Massimo

[Paddy_1]

I had the same problem due to disk failure.
We had to manually ask the operation folks to salvage old stuff and remount it.Still we couldnt exactly get to the stage we wanted.

[sathish kannan]

Hi Massimo,
You are right. There are lot of combination in this issue. The affected file is in Auto extend mode. Filesystem has largefiles option so it can grow more than 2GB. We don't know whether the file is a sparse or not but definetly it is corrupted. Our DBA's had logged a call with oracle and checking from their end. Thanks for your help.

Steve and PAddy - I can't find any problems with disk and no logs on syslog/dmesg. Thanks for your input.


Regards
Sathish

[Massimo Bianchi]

Hi,
i stress another point: ksh

It has a built in imitation of 2G.

Try to start the db with csh, that can support largefiles if it is properly set up.

Check with "ulimit -a"

Once i resolved the corruption staring it with csh, because it allowed us to write behind the 2G limit. But since you have oracle on your side, i will trust them :)

Massimo

[sathish kannan]

closing thread. issue solved by rebooting and call logged with oracle.