Re: Block Corruption in empty pages in Oracle 11g
From: zigzagdna <zigzagdna_at_yahoo.com>
Date: Fri, 13 Aug 2010 21:32:32 -0700 (PDT)
Message-ID: <80cdd9f9-e66e-4f40-b2c4-41b04b789614_at_i31g2000yqm.googlegroups.com>
On Aug 7, 1:39 pm, zigzagdna <zigzag..._at_yahoo.com> wrote:
> On Aug 7, 5:54 am, John Hurley <hurleyjo..._at_yahoo.com> wrote:
>
>
>
>
>
> > Mladen:
>
> > > The command is:
>
> > > ALTER SYSTEM DUMP DATAFILE <file_id> BLOCK MIN <min block>
> > > BLOCK MAX <max block>;
>
> > > On a real OS, one can have rather satisfactory results by doing:
>
> > > dd if=<data file> bs=8k count=<count>|od -x
>
> > > If the block size is not 8k, the corresponding value needs to be
> > > substituted into the dd command.
>
> > Some people actually take the time to ( on a test system ) introduce
> > damage and test out their ability to find problems and recover from
> > them. Shocking eh?
>
> > Of course a hex editor can let you introduce just little tiny bits of
> > corruption ... especially with tools that show one the structure of
> > the blocks.
>
> Thanks to all for provding your input; very useful. I do know how to
> corrupt a blok using dd command. In fact, several years ago when I
> took training on Oracle 9i or 10g; one of the classroom exercises was
> to corrupt a block and recover it using rman block recover command. I
> tried it on my database and I it seems to take same amount of time as
> full recover; because it scans entire backup to serach for the blocks
> specfied in the block recver command.
>
> I am still at loss why this block corruption is happening; I have seen
> it twtice on this system. It is hard to convince UNIX Administartors
> that something is wrong in disk or disk controller; I even don't know
> how they will find that. All they can do is to replace disks and disk
> controllers.- Hide quoted text -
>
> - Show quoted text -
Date: Fri, 13 Aug 2010 21:32:32 -0700 (PDT)
Message-ID: <80cdd9f9-e66e-4f40-b2c4-41b04b789614_at_i31g2000yqm.googlegroups.com>
On Aug 7, 1:39 pm, zigzagdna <zigzag..._at_yahoo.com> wrote:
> On Aug 7, 5:54 am, John Hurley <hurleyjo..._at_yahoo.com> wrote:
>
>
>
>
>
> > Mladen:
>
> > > The command is:
>
> > > ALTER SYSTEM DUMP DATAFILE <file_id> BLOCK MIN <min block>
> > > BLOCK MAX <max block>;
>
> > > On a real OS, one can have rather satisfactory results by doing:
>
> > > dd if=<data file> bs=8k count=<count>|od -x
>
> > > If the block size is not 8k, the corresponding value needs to be
> > > substituted into the dd command.
>
> > Some people actually take the time to ( on a test system ) introduce
> > damage and test out their ability to find problems and recover from
> > them. Shocking eh?
>
> > Of course a hex editor can let you introduce just little tiny bits of
> > corruption ... especially with tools that show one the structure of
> > the blocks.
>
> Thanks to all for provding your input; very useful. I do know how to
> corrupt a blok using dd command. In fact, several years ago when I
> took training on Oracle 9i or 10g; one of the classroom exercises was
> to corrupt a block and recover it using rman block recover command. I
> tried it on my database and I it seems to take same amount of time as
> full recover; because it scans entire backup to serach for the blocks
> specfied in the block recver command.
>
> I am still at loss why this block corruption is happening; I have seen
> it twtice on this system. It is hard to convince UNIX Administartors
> that something is wrong in disk or disk controller; I even don't know
> how they will find that. All they can do is to replace disks and disk
> controllers.- Hide quoted text -
>
> - Show quoted text -
Can some one explain following ooutput from dbv; what is difference in total pages failing and corrupt pages. I see total pages marked corrupt as 1345; yet I do not see any data or index pages marked corrupt; and there is only 1 empty page. So where are those 1345 corrupt pages.
DBVERIFY - Verification complete
Total Pages Examined : 371200 Total Pages Processed (Data) : 328622 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 38 Total Pages Failing (Index): 0 Total Pages Processed (Other): 41194 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 1 Total Pages Marked Corrupt : 1345 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 3430163491 (2476.3430163491)
DBVERIFY: Release 11.1.0.7.0 - Production on Sat Aug 14 00:25:24 2010 Received on Fri Aug 13 2010 - 23:32:32 CDT