Document 457422.1

6/3/24, 11:44 AM Document 457422.
1
Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.
RMAN Reports an ORA-19566: Exceeded Limit Of 0 Corrupt Blocks From Backup And No Segment Associated (Doc ID
457422.1)
In this Document
Symptoms
Changes
Cause
Solution
References
APPLIES TO:
Oracle Database - Enterprise Edition - Version 9.2.0.1 and later

Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Information in this document applies to any platform.
SYMPTOMS
1. Attempting a backup using RMAN, you receive the following error,
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch1 channel at 09/01/2007 19:38:44
ORA-19566: exceeded limit of 0 corrupt blocks for file /<path>/<datafilename>.dbf
2. Performing an DBV on the above file shows a corrupt block.
dbv file=/<path>/<datafilename>.dbf blocksize=16384
DBVERIFY: Release 9.2.0.4.0 - Production on Thu Aug 30 18:06:59 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /<path>/<datafilename>.dbf
Page 91880 is influx - most likely media corrupt

***
Corrupt block relative dba: 0x048166e8 (file 18, block 91880)
Fractured block found during dbv:
Data in bad block -
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
consistency value in tail: 0x00000001
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
DBVERIFY - Verification complete
Total Pages Examined : 128000

Total Pages Processed (Data) : 10475
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 1154
Total Pages Failing (Index): 0
Total Pages Processed (Other): 645
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 115725
Total Pages Marked Corrupt : 1
Total Pages Influx :1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=pldhbisef_150&id=457422.1 1/3
6/3/24, 11:44 AM Document 457422.1
Please note Page number (One which is highlighted) reported in dbverify output at the start is the Oracle block number having the corruption.
3. The following SQL statement is executed to determine that there is no segment associated
SELECT tablespace_name, segment_type, owner, segment_name

FROM dba_extents
WHERE file_id = 18
and 91880 between block_id AND block_id + blocks - 1;
CHANGES
CAUSE
Corrupted blocks will still be reported by RMAN and DBV until they are reused and reformatted.
Note 269028.1 is another explanation.
RMAN reads blocks on the disk level, so it is not aware if they belong to an object. Thus if an
object with corrupted blocks is dropped, those blocks remain corrupted until reused by a new
object or allocated to an existing table. At that time, Oracle will reformat the block (renew it)
and thus remove the corruption. If the following query does not report any objects being used by
the block:
SELECT tablespace_name, segment_type, owner, segment_name

FROM dba_extents
WHERE file_id = &AFN
and &BL between block_id AND block_id + blocks - 1;
then, the corrupted block is still being seen as corrupted, because it has not been reused and
renewed by Oracle.
You can also run
Select * from dba_free_space WHERE file_id = &AFN

and &BL between block_id AND block_id + blocks - 1;
This would return records indicating the block is in free space.
SOLUTION
Solution 1:- Try Resizing the datafile to Smaller size
A simple solution is to RESIZE the datafile which reformats the file.
In this case, Resizing the datafile from 2GB to 1GB resolved the issue.
This only works if the block is in the GB that we've resized back, so, the best solution is NOTE 336133.1 as in most of the cases this will not work.
Solution 2 :- Use Setmaxcorrupt option in RMAN
Allow the unused corrupted blocks to be backed up by RMAN:
Set maxcorrupt = the number of blocks for that file on backup, and periodically check if the block
becomes used by the system. If RMAN finds any other corrupted blocks, it will report them. Once
you see in dba_extents that the block is allocated by an object, you can reduce the number of
blocks and eventually remove the 'maxcorrupt' setting for that file altogether.
For example, in this case add the following to the backup command:
RMAN> set maxcorrupt for datafile 24 to 1;
In Above example Dbverify had reported one block as corrupted. So we used set maxcorrupt to 1 for that datafile.
Corruption in any other file would be reported. If a second block is found corrupted in datafile 24, RMAN would report it.
Please note in this case RMAN would backup the corrupted block as it is in Corrupted state.
Solution 3:_ Force Oracle to use the block, so it can be 'reformatted'.
See Note 336133.1 How to Format Corrupted Block Not Part of Any Segment for details.
REFERENCES
6/3/24, 11:44 AM Document 457422.1
NOTE:269028.1 - DBV Reports Corruption Even After Drop/Recreate Object
NOTE:336133.1 - How to Format Corrupted Block Not Part of Any Segment
NOTE:1088018.1 - Primary Note for Handling Oracle Database Corruption Issues
Didn't find what you are looking for?

Document 457422.1

Uploaded by

Copyright:

Available Formats

Document 457422.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Document 457422.1

Uploaded by

Copyright:

Available Formats

6/3/24, 11:44 AM Document 457422.

Oracle Database - Enterprise Edition - Version 9.2.0.1 and later

1. Attempting a backup using RMAN, you receive the following error,

2. Performing an DBV on the above file shows a corrupt block.

dbv file=/<path>/<datafilename>.dbf blocksize=16384

DBVERIFY: Release 9.2.0.4.0 - Production on Thu Aug 30 18:06:59 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

DBVERIFY - Verification starting : FILE = /<path>/<datafilename>.dbf

Page 91880 is influx - most likely media corrupt

DBVERIFY - Verification complete

Total Pages Examined : 128000

SELECT tablespace_name, segment_type, owner, segment_name

Note 269028.1 is another explanation.

SELECT tablespace_name, segment_type, owner, segment_name

You can also run

Select * from dba_free_space WHERE file_id = &AFN

This would return records indicating the block is in free space.

Solution 1:- Try Resizing the datafile to Smaller size

A simple solution is to RESIZE the datafile which reformats the file.

Solution 2 :- Use Setmaxcorrupt option in RMAN

Allow the unused corrupted blocks to be backed up by RMAN:

RMAN> set maxcorrupt for datafile 24 to 1;

Solution 3:_ Force Oracle to use the block, so it can be 'reformatted'.

Didn't find what you are looking for?

You might also like