Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ORA-01578 data block corrupted with 10G

Re: ORA-01578 data block corrupted with 10G

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: 4 May 2005 06:11:31 -0700
Message-ID: <1115212291.764218.228440@z14g2000cwz.googlegroups.com>


Kurt-Erich.Fin..._at_hte-company.de wrote:
> RDBMS : 10.1.0.4
> OS : Linux Debian Sarge 3.1
> Kernel: 2.4.27-1-386
> Box : standard office PC with 1G RAM
>
> We are testing an upgrade from 8.1.7 to 10.1.0.4 with some changes in
> the database design.
> The schema was exported from the production machine (8.1.7) imported
> into the new box (10.1.0.4). The application could access the tables
> and seems to run correctly. We have to modify the design to remove
some
> faults in the old version. In one table we are replacing a column
> containing strings with the corresponding ID's from a master table.
> During this operation we get:
>
> ORA-01578 ORACLE data block currupted (file# 6, block 54871)
> ORA-01110 : data file 6 '/data.dbf'
>
> I followed the Oracle instructions 28814.1 and found that the segment
> type where the corruption occured was a table (the table where I want
> to perform the update)
> To exclude hardware error, I renamed the table and recreated it. The
> corrupted block error persists (with another record).
> There is no ORA-600 error in the alert log file.
>
> The last lines in the alert log are:
>
> Thread 1 advanced to log sequence 6864
> Current log# 1 seq# 6864 mem# 0: /data/redologs/redo1.log
> Wed May 4 10:36:28 2005
> Private_strands 18 at log switch
> Thread 1 advanced to log sequence 6865
> Current log# 2 seq# 6865 mem# 0: /data/redologs/redo2.log
> Wed May 4 10:38:19 2005
> Thread 1 cannot allocate new log, sequence 6866
> Checkpoint not complete
> Current log# 2 seq# 6865 mem# 0: /data/redologs/redo2.log
> Private_strands 18 at log switch
> Thread 1 advanced to log sequence 6866
> Current log# 3 seq# 6866 mem# 0: /data/redologs/redo3.log
> Wed May 4 10:39:45 2005
> Hex dump of (file 6, block 54871) in trace file
> /data/log/oradev10_ora_27480.trc
> Corrupt block relative dba: 0x0180d657 (file 6, block 54871)
> Bad check value found during buffer read
> Data in bad block:
> type: 6 format: 2 rdba: 0x0180d657
> last change scn: 0x0000.01c64777 seq: 0x1 flg: 0x04
> spare1: 0x0 spare2: 0x0 spare3: 0x0
> consistency value in tail: 0x47770601
> check value in block header: 0x3558
> computed block checksum: 0xa400
> Reread of rdba: 0x0180d657 (file 6, block 54871) found same corrupted
> data
> Wed May 4 10:39:46 2005
> Corrupt Block Found
> TSN = 6, TSNAME = FAST_CORE_TS
> RFN 6, BLK = 54871, rdba = 25220695
> OBJN = 53256, OBJD = 53256, OBJECT= PARAM_VALUES, SUBOBJECT
=
> Segment Owner= KEF, Segment Type = Table Segment
>
>
> Thanks for any help
>
> Kurt-Erich
>
>
> PS
>
> We know that Debian is not certified by Oracle, we had to use it for
> other
> reasons. If this is a Debian problem we will of course install Red
hat
> or Suse
>
> PS2
>
> What does
> Private_strands 18 at log switch
> mean?

One possible option ... get an rman backup before causing the problem, keep db in archive log mode, use rman block recover to fix. That's a possible solution to allow you to continue testing.

Isolating the source of this interesting failure as an os problem versus a hardware problem versus an oracle bug will be an interesting exercise. As you noted one of the first things to possbibly think about is re-testing on a different os ... without knowing any more than you supplied can ugly throw in a free SWAG (Stupid Wild Ass Guess) that your problem may be hardware based ... (controller or disk or ?). Received on Wed May 04 2005 - 08:11:31 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US