Hi, Sorry to be slow on replying. dbv is broken! It calls statfs for a file name and then looks in $ORACLE_HOME/dbs for the file even though it opened it OK: access("store_control01.dbf", F_OK) = 0 statfs("store_control01.dbf", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901535, f_bfree=996315, f_bavail=340955, f_files=6553600, f_ffree=6553470, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 open("store_control01.dbf", O_RDONLY) = 5 lseek(5, 0, SEEK_SET) = 0 read(5, "\0\242\0\0\0\0\300\377\0\0\0\0\0\0\0\0\346\376\0\0\0 \0"..., 8192) = 8192 lseek(5, 9437184, SEEK_SET) = 9437184 read(5, "\0\242\0\0\200\4\0\0\0\0\0\0\0\0\1\5\200\243\0\0\0\0\0"..., 8192) = 8192 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 rt_sigprocmask(SIG_BLOCK, [WINCH], NULL, 8) = 0 rt_sigaction(SIGWINCH, {0x2a96839604, ~[ILL ABRT BUS FPE SEGV USR2 XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x3e57f0c5b0}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [WINCH], NULL, 8) = 0 rt_sigaction(SIGWINCH, NULL, {0x2a96839604, ~[ILL ABRT BUS FPE KILL SEGV USR2 STOP XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x3e57f0c5b0}, 8) = 0 rt_sigaction(SIGWINCH, {0x2a96839604, ~[ILL ABRT BUS FPE KILL SEGV USR2 STOP XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_SIGINFO, 0x3e57f0c5b0}, NULL, 8) = 0 io_setup(128, 0x56a558) = -1 EAGAIN (Resource temporarily unavailable) stat("/oracle/product/11.1.0/dbs/store_control01.dbf", 0x7fbfff98f0) = -1 ENOENT (No such file or directory) write(2, "\nDBV-00600: ", 12 DBV-00600: ) = 12 write(2, "Fatal Error - [21] [2] [0] [0]", 30Fatal Error - [21] [2] [0] [0]) = 30 write(2, "\n", 1 ) = 1 close(5) = 0 munmap(0x2a97e46000, 143360) = 0 close(4) = 0 munmap(0x2a97e23000, 143360) = 0 exit_group(3) = ? Not sure what's going on with the calls to io_setup, even doing this as root it fails. Copying the file to $ORACLE_HOME/dbs makes it work, but a symbolic link fails with errors about too many link levels. Regards Pete On Wed, Jul 15, 2009 at 6:12 PM, Andreas Piesk <a.piesk@xxxxxxx> wrote: > Peter Hitchman schrieb: > > Hi, > > I tried dbv today with 11.1.0.06 on RHL4, normal cooked file system. > > > > I get: > > > > dbv file=system01.dbf blocksize=8192 > > > > DBVERIFY: Release 11.1.0.6.0 - Production on Tue Jul 14 10:07:17 2009 > > > > Copyright (c) 1982, 2007, Oracle. All rights reserved. > > > > > > DBV-00600: Fatal Error - [21] [2] [0] [0] > > > > MetaLink lists a bug (Bug 6820317 -) about not having write access the > > file, but this is not the case here and the error message is different. > > > > I only tried this because over-night the some oddity made the root file > > system read only and we had to reboot. > > > > Any one else seen this? > > > > yes, i have seen his error too. in my case the datafile was 8192 bytes > longer than the file header said. > could you run 'strace -f dbv file=system01.dbf blocksize=8192' to see > which systemcall fails? > > regards, > -ap > > -- Regards Pete