Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to solve the problem of bad blocks triggered by adding unempty disks to disk groups in Oracle database". In daily operation, it is believed that many people have doubts about how to solve the problem of bad blocks triggered by adding unempty disks to disk groups in Oracle databases. The editor consulted all kinds of materials and sorted out simple and useful methods of operation. I hope it will be helpful for you to answer the question of how to solve the problem of bad blocks triggered by the addition of unemptied disks to the disk group in the Oracle database. Next, please follow the editor to study!

Problem description

Received a notice from the system maintenance personnel that the Oracle database software directory is suddenly unusually full and needs to be cleaned up in time. After logging in to the environment, it is found that the alarm log is constantly refreshed, and the refresh content is that a bad block is detected.

Some of the alarm logs are as follows:

Reading datafile'+ xx01/xxx85' for corruption at rdba: 0x1c4b3afc (file x3, block 474692348)

Read datafile mirror 'xxx02' (file x3, block 47xx48) found same corrupt data (no logical check)

Read datafile mirror 'xxx 53' (file x3, block 47xx48) found valid data

Hex dump of (file x3, block 47xx48) in trace file / xxx130931.trc

Repaired corruption at (file x3, block 47 xxx 48)

Hex dump of (file x3, block 47xxx24) in trace file / xx931.trc

Corrupt block relative dba: 0x1c308c08 (file x3, block 47xx4)

Bad header found during buffer read

Data in bad block:

Type: 0 format: 6 rdba: 0x34363835

Last change scn: 0x3833.35313431 seq: 0x30 flg: 0x37

Spare1: 0x31 spare2: 0x36 spare3: 0xf00

Consistency value in tail: 0x30520300

Check value in block header: 0x36

Computed block checksum: 0x6060

Reading datafile'+ xxxx8685' for corruption at rdba: 0x1c308c08 (file x3, block 47xx24)

Read datafile mirror 'xxxx2' (file x3, block 47xx24) found same corrupt data (no logical check)

Read datafile mirror 'xxx3' (file x3, block 47xx24) found valid data

Hex dump of (file x3, block 47xxx24) in trace file / xxx0931.trc

Sat Nov 09 12:48:17 2019

Hex dump of (file x3, block 14xxx7) in trace file / xxx22.trc

Corrupt block relative dba: 0x1ed647db (file x3, block 14xxx7)

Bad header found during buffer read

Data in bad block:

Type: 73 format: 6 rdba: 0x5454415f

Last change scn: 0x0e00.00440052 seq: 0x0 flg: 0x00

Spare1: 0x53 spare2: 0x54 spare3: 0x0

Consistency value in tail: 0x01006541

Check value in block header: 0xa00

Block checksum disabled

Reading datafile'+ xxxx17527' for corruption at rdba: 0x1ed647db (file x3, block 14xxx7)

Read datafile mirror 'xx002' (file x3, block 14xxx7) found same corrupt data (no logical check)

Read datafile mirror 'xxx0' (file x3, block 14xxx7) found valid data

Hex dump of (file x3, block 14xx7) in trace file / xxx2.trc

Analysis of Repaired corruption at (file x3, block 14xxx7) problems

Through the information that appears in the alarm log, we look at these problem data blocks and find that the types involved include tables, indexes, and so on.

Select relative_fno,owner,segment_name, segment_type from dba_extents where file_id = x3 and 35xxxx9 between block_id and block_id + blocks-1

RELATIVE_FNO OWNER SEGMENT_NAME SEGMENT_TYPE

1024 IxxxL PxxxT INDEX

RELATIVE_FNO OWNER SEGMENT_NAME SEGMENT_TYPE

124 IxxxM OxxxT TABLE

Use DBV to check and verify:

……

Page 278199 is marked corrupt

Corrupt block relative dba: 0x21843eb7 (file x4, block 2xx9)

Bad header found during dbv:

Data in bad block:

Type: 0 format: 4 rdba: 0x0000ffff

Last change scn: 0x0000.00000000 seq: 0x0 flg: 0x1d

Spare1: 0x0 spare2: 0xa spare3: 0x0

Consistency value in tail: 0x31040000

Check value in block header: 0x1500

Computed block checksum: 0xe403

Page 278200 is marked corrupt

Corrupt block relative dba: 0x21843eb8 (file x4, block 2xx0)

Bad header found during dbv:

Data in bad block:

Type: 48 format: 0 rdba: 0x000a0018

Last change scn: 0x3031.31060000 seq: 0x30 flg: 0x30

Spare1: 0x30 spare2: 0x0 spare3: 0x19

Consistency value in tail: 0x000b0000

Check value in block header: 0x31

Block checksum disabled

. Omit n lines here

Recorded in the relevant Trace:

Corrupt block relative dba: 0x2180ba80 (file x4, block 4xx4)

Bad header found during user buffer read

Data in bad block:

Type: 82 format: 0 rdba: 0x534e4901

Last change scn: 0x4546.464f2e54 seq: 0x52 flg: 0x5f

Spare1: 0x0 spare2: 0x0 spare3: 0x5453

Consistency value in tail: 0x0908bdf2

Check value in block header: 0x4e49

Computed block checksum: 0x66c6

Reading datafile'+ xxx05' for corruption at rdba: 0x2180ba80 (file x4, block 4xx4)

Ksfdrfms:Mirror Read file=+xxx905 fob=0x246076cb80 bufp=0x7f9a07619c00 blkno=47744 nbytes=8192

Ksfdrfms: Read success from mirror side=1 logical extent number=0 disk=xxx2 path=/dev/axxx1

Mirror I/O done from ASM disk / dev/axxx1

Read datafile mirror 'xxx02' (file x4, block 4xx4) found same corrupt data (no logical check)

Ksfdrnms:Mirror Read file=+xxx7905 fob=0x246076cb80 bufp=0x7f9a07619c00 nbytes=8192

Ksfdrnms: Read success from mirror side=2 logical extent number=1 disk=xxx3 path=/dev/axxx4

Mirror I/O done from ASM disk / dev/axxx4

Read datafile mirror 'xxx3' (file x4, block 4xx4) found valid data

Hex dump of (file x4, block 4xx4)

After careful observation, it is found that the bad block errors are very similar each time, as shown below:

Read datafile mirror 'xxx2' (file x3, block 47xxx48) found same corrupt data (no logical check)

When we take a closer look at the logs, we find that a common feature is that basically all the disks are named xxx2 and the same data blocks are found in other disk names, and the valid data blocks in these data blocks are all on other disks, while the invalid bad data blocks are all on disk / dev/axxx1 (that is, disk name: xxx2), so the guess may be related to the related operations of this disk. Further understanding and discovery, this disk was originally a disk in the disk group xxx1, but due to some reason, the disk was not in the disk group, and then they re-added the disk the day before the abnormal time, and finally the truth came out. Because the old data of / dev/axxx1 has not yet been emptied, the old block conflicts with the new block, and the database exception reports an error, exploding the software directory.

The redundancy of xxx1 disk groups is NORMAL. For a simple example, according to the number of mirrors in oracle, the redundancy of disk groups is divided into the following three categories:

1) external redundancy (External redundancy): the data is not mirrored. This situation applies to systems that have mirrored the data using the underlying storage software.

2) normal redundancy (Normal redundancy): 1-way image. This redundancy applies to most systems.

3) High redundancy (High redundancy): 2-way images. This redundancy is suitable for storing important data of the system, which, of course, means taking up more space.

Oracle mirroring data is realized through failuregroup (failure Group). That is to say, because the xxx1 disk group is normal redundant, while retaining a mirror, Oracle ensures that each Extent and its corresponding mirror will not be saved in the same failure group, thus ensuring that there will be no data loss when one or more disks in the failure group, or even the entire failure group, are lost. When the disk / dev/axxx1 is rejoined to the disk group, the ASM rebalance feature equalizes the distribution of file extent on all disks in the disk group, which is handled by the background process RBAL. An error will be reported when the distributed mirror conflicts with the old data in the disk / dev/axxx1.

Problem solving

Directly eliminate the problem disk, dd disk, clear the old data, and then add back, problem solving, fault recovery.

Alter diskgroup xxx1 drop disk 'Oxxxx2'

Dd if=/dev/zero of=/dev/asxxx1 bs=1M count=256 at this point, the study on "how to solve the problem of bad blocks triggered by adding unemptied disks to disk groups in the Oracle database" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.