Re: dbv error in 11.1.0.6

From: Peter Hitchman <pjhoraclel_at_gmail.com>
Date: Mon, 20 Jul 2009 11:24:16 +0100
Message-ID: <5e317f310907200324k21054243u3a0d68e2577e9604_at_mail.gmail.com>

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_at_gmail.com>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_at_gmx.net> 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

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Jul 20 2009 - 05:24:16 CDT