Hi, My colleague has just shown me that it works as long as the file name argument is a full path name. Regards Pete On Mon, Jul 20, 2009 at 10:46 AM, Peter Hitchman <pjhoraclel@xxxxxxxxx>wrote: > > 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 > -- Regards Pete