How to have Oracle ASM scan for and repair uncorrectable ECC errors (bad sectors)

oracleoracle-11g-r2oracle-asm

I'm running Oracle ASM (11gR2) with normal redundancy on SATA disks (WD Raptors). This is on a physical standby database, if it matters. Occasionally, disk sectors develop read errors (ECC failures). When that happens, that block is no longer mirrored, but ASM doesn't know this.

How can I have ASM read through the partitions it controls, and make sure that each block is readable?

Ideally, it'd also confirm that both sides of the mirror match, and re-write any sectors that the disk reports uncorrectable ECC errors for.

(I.e., I'd like the equivalent of mdraid's echo 'repair' > /sys/block/md0/md/sync_action or a hardware RAID controller's background consistency check.)

Update 2012-01-03: So far, the best I've found is to alter the diskgroup to drop the disk, wait for the rebalance to finish, use an OS utility to zero the disk, and then add the disk back. This of course doesn't compare the two sides of the mirror, but at least reallocates any bad sectors. It seems like there must be a better way. Its hard to believe ASM lacks such a standard RAID feature.

Best Answer

Use alter diskgroup mydiskgroup check all; or the remap command. But ASM should manage this for you; perhaps you need a higher redundancy setting on your JBODs,

Related Solutions

Oracle extents – How to have so many with this small size

The data you're getting from Toad appears to be incorrect or, at least, misleading. If you are using a locally managed tablespace with automatic extent allocation, Oracle will determine your initial and next extent sizes automatically. In 11.2, the first 16 extents are going to be 64k in size (for a total of 1 MB). The next 63 extents are going to be 1 MB in size. So if you have 26 extents, that implies that the table occupies 11 MB of space on disk. An initial extent of 1.44 GB makes no sense and a size of 4.18 MB seems rather low if you're saying it hasn't shrunk.

What does

SELECT tablespace_name,
       extent_id, 
       bytes/1024 kb
  FROM user_extents
 WHERE segment_name = <<name of table>>

show you? If you have 26 extents, you should see that extents 0-15 are 64 kb in size and extents 16-25 are 1 MB in size.

SELECT SUM(bytes)/1024/1024 size_in_mb
  FROM user_extents
 WHERE segment_name = <<name of table>>

will show you the total size of the table's extents on disk.

Oracle extents – How to have so few with this large size

You may believe that this is a different question but my answer is going to be essentially identical assuming the additional information from the prior question is the same-- you're using automatic extent allocation and you're not sure how Toad is determining these numbers.

The data you're getting from Toad appears to be incorrect or, at least, misleading. If you are using a locally managed tablespace with automatic extent allocation, Oracle will determine your initial and next extent sizes automatically. In 11.2, the first 16 extents are going to be 64k in size (for a total of 1 MB). The next 63 extents are going to be 1 MB in size. So if you have 12 extents, that implies that the table occupies 768 kb of space on disk. An initial extent of 118 MB makes no sense and a size of 376 MB makes no sense.

What does

SELECT tablespace_name,
       extent_id, 
       bytes/1024 kb
  FROM user_extents
 WHERE segment_name = <<name of index>>

show you? If you have 12 extents, you should see that extents 0-11 are 64 kb in size.

SELECT SUM(bytes)/1024/1024 size_in_mb
  FROM user_extents
 WHERE segment_name = <<name of index>>

will show you the total size of the table's extents on disk.

Related Question