Corrupt block detected in control file

Hi All,
I have a scenario where I have set up Active/Standby RACs and successfully have archive redo logs being applied to Standby - everything was ok
Versions - Oracle 11g R2 , of RHEL 5
Scenario 1:
Redo log application on Standby works perfectly when I do not create our software application tables using sql scripts on the Primary until AFTER the steps for Dataguard/RAC is completed successfully.
Scenario 2:
Redo log application does not work when I do run our sql scripts BEFORE I take a RMAN backup of the Primary to duplicate in the Standby
Everything comes up on the Standby after the rman duplicate, archive logs get transferred , but now they do not get applied.
I see the ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) in the alert log when I put standby in Recovery Mode
My theory is that somehow our sql scripts are breaking my rman backups when I run them before creating an RMAN backup of Primary to load on Standby- I just need someone to advise whether this is a possibility from their experience, if so I will contact Oracle support to investigate further. This is my first time working on RAC DG etc
Thanks

Hi All ,
Ive tried to upgrade Oracle to 11.2.0.2 to fix this issue - that I can no longer remember !
Managed to complete upgrade on the standby node (after having to reinstall due to hostname change )
Now trying the Active node, I see the following error during the grid upgrade where i execute rootupgrade.sh
Now product-specific root actions will be performed.
Using configuration parameter file: /opt/app/11.2.0/grid2/crs/install/crsconfig_params
Creating trace directory
Failed to add (property/value):('OLD_OCR_ID/'-1') for checkpoint:ROOTCRS_OLDHOMEINFO.Error code is 256
The fixes for bug 9413827 are not present in the 11.2.0.1 crs home
Apply the patches for these bugs in the 11.2.0.1 crs home and then run rootupgrade.sh
/opt/app/11.2.0/grid2/perl/bin/perl -I/opt/app/11.2.0/grid2/perl/lib -I/opt/app/11.2.0/grid2/crs/install /opt/app/11.2.0/grid2/crs/install/rootcrs.pl execution failed
I have to download this patch from MOS for bug 9413827, somehow apply it to the old version of grid 11.2.0.1 and then rootupgrade.sh

Similar Messages

Error: ORA-00227 - Corrupt block detected in control file

Hey everybody,
I'm having problems with Oracle, here is the error displayed:
SQL> startup;
ORACLE instance started.
Total System Global Area 247463936 bytes
Fixed Size 1258244 bytes
Variable Size 92278012 bytes
Database Buffers 150994944 bytes
Redo Buffers 2932736 bytes
ORA-00227: corrupt block detected in control file: (block 16, # blocks 1)
ORA-00202: control file: '/usr/lib/oracle/xe/oradata/XE/control.dbf'
I wonder what I should do to solve this problem.
Could anyone help me?
Thanks

user10826800 wrote:
Hey everybody,
I'm having problems with Oracle, here is the error displayed:
SQL> startup;
ORACLE instance started.
Total System Global Area 247463936 bytes
Fixed Size 1258244 bytes
Variable Size 92278012 bytes
Database Buffers 150994944 bytes
Redo Buffers 2932736 bytes
ORA-00227: corrupt block detected in control file: (block 16, # blocks 1)
ORA-00202: control file: '/usr/lib/oracle/xe/oradata/XE/control.dbf'
I wonder what I should do to solve this problem.
Could anyone help me?
ThanksHi and welcome to the forum. Replace corrupted control file with non-corrupted one and start the database

Strange Corrupt Block Error in Control File not in CONTROL_FILES

When in RMAN connected to the TARGET and CATALOG I issue a RESYNC CATALOG I get this error:
RMAN> RESYNC CATALOG;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync command on default channel at 08/17/2009 10:36:59
ORA-00227: corrupt block detected in control file: (block 15, # blocks 1)
ORA-00202: control file: 'E:\ORACLE\PRODUCT\10.2.0\DATABASE\SNCFEBIZ01PD.ORA'
RMAN>
This control file is in the Oracle Windows default dir but I am not using it and did not create it.
My control files listed in the init.ora are:
SQL> show parameter control
NAME TYPE VALUE
control_file_record_keep_time integer 7
control_files string E:\ORACLE\ORADATA\EBIZ01PD\CNT
RL01.DBF, D:\ORACLE\ORADATA\EB
IZ01PD\CNTRL02.DBF, E:\ORACLE\
ORADATA\EBIZ01PD\CNTRL03.DBF
Any idea why this is happening?

That is a SNAPSHOT CONTROLFILE, created by RMAN as a copy of the current controlfile.
Wonder how and why the copy is corrupted ? Check the timestamp of the file to see when it was created. A RESYNC will always create a fresh Snapshot Controlfile.
See http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmarchi.htm#sthref65

Error in reading (block 3, # blocks 8) of control file

Hi All,
My database experiencing this error :
ORA-00204: error in reading (block 3, # blocks 8) of control file
ORA-00202: control file: 'C:\ORACLEXE\ORADATA\XE\CONTROL.DBF'
ORA-27091: unable to queue I/O
ORA-27070: async read/write failed
OSD-04006: ReadFile() failure, unable to read from file
O/S-Error: (OS 23) Data error (cyclic redundancy check).
Worst part we do not have latest backup and makes things weird.
My Control file seem corrupted.

Error: ORA 204
Text: error in reading control file <name> block <num>, # blocks <num>
Cause: A disk read-failure occurred while attempting to read the specified
control file.
The block location of the failure is given.
Action: Check that the disk is online.
If it is not, bring it online and shut down and restart Oracle.
If the disk is online, then look for operating system reasons for
Oracle's inability to read the disk or control file.
Use the mutiplxed controlfile if you have already available to start your instance...
SQL>show parameter control_files;
Use above command

DBVERIFY and control file

Hi,
in 10g R2 on Win 2003,
can we used dvf to verify if controlfile is corrupted or not ?
I had this in alertolog :
Tue Oct 05 10:05:25 2010
Errors in file d:\oracle\product\10.2.0\admin\MYDB\bdump\opermst_arc0_5616.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: 'D:\BASES\MYDB\CTL\CONTROL02.CTL' But database did not stop.
I want to know if CONTROL02.CTL' is still corrupted or not ?
Should I absolutely renew it ?
Thanks.

here they are :
Tue Oct 05 16:27:44 2010
Thread 1 advanced to log sequence 1274 (LGWR switch)
Current log# 2 seq# 1274 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 16:30:59 2010
Thread 1 advanced to log sequence 1275 (LGWR switch)
Current log# 3 seq# 1275 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 16:35:12 2010
Thread 1 advanced to log sequence 1276 (LGWR switch)
Current log# 1 seq# 1276 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 16:39:12 2010
Thread 1 advanced to log sequence 1277 (LGWR switch)
Current log# 2 seq# 1277 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 16:43:15 2010
Thread 1 advanced to log sequence 1278 (LGWR switch)
Current log# 3 seq# 1278 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 16:47:32 2010
Thread 1 advanced to log sequence 1279 (LGWR switch)
Current log# 1 seq# 1279 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 16:51:42 2010
Thread 1 advanced to log sequence 1280 (LGWR switch)
Current log# 2 seq# 1280 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 16:56:43 2010
Thread 1 advanced to log sequence 1281 (LGWR switch)
Current log# 3 seq# 1281 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 17:01:42 2010
Thread 1 advanced to log sequence 1282 (LGWR switch)
Current log# 1 seq# 1282 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 17:06:23 2010
Thread 1 advanced to log sequence 1283 (LGWR switch)
Current log# 2 seq# 1283 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 17:10:34 2010
Thread 1 advanced to log sequence 1284 (LGWR switch)
Current log# 3 seq# 1284 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 17:15:54 2010
Thread 1 advanced to log sequence 1285 (LGWR switch)
Current log# 1 seq# 1285 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 17:21:38 2010
Thread 1 advanced to log sequence 1286 (LGWR switch)
Current log# 2 seq# 1286 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 17:27:07 2010
Thread 1 advanced to log sequence 1287 (LGWR switch)
Current log# 3 seq# 1287 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 17:32:28 2010
Thread 1 advanced to log sequence 1288 (LGWR switch)
Current log# 1 seq# 1288 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 17:38:14 2010
Thread 1 advanced to log sequence 1289 (LGWR switch)
Current log# 2 seq# 1289 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 17:44:06 2010
Thread 1 advanced to log sequence 1290 (LGWR switch)
Current log# 3 seq# 1290 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 17:50:26 2010
Thread 1 advanced to log sequence 1291 (LGWR switch)
Current log# 1 seq# 1291 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 17:57:45 2010
Thread 1 advanced to log sequence 1292 (LGWR switch)
Current log# 2 seq# 1292 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 18:06:01 2010
Thread 1 advanced to log sequence 1293 (LGWR switch)
Current log# 3 seq# 1293 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 18:13:52 2010
Thread 1 advanced to log sequence 1294 (LGWR switch)
Current log# 1 seq# 1294 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 18:21:26 2010
Thread 1 advanced to log sequence 1295 (LGWR switch)
Current log# 2 seq# 1295 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 18:28:25 2010
Thread 1 advanced to log sequence 1296 (LGWR switch)
Current log# 3 seq# 1296 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 18:36:13 2010
Thread 1 advanced to log sequence 1297 (LGWR switch)
Current log# 1 seq# 1297 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 18:45:03 2010
Thread 1 advanced to log sequence 1298 (LGWR switch)
Current log# 2 seq# 1298 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 18:53:51 2010
Thread 1 advanced to log sequence 1299 (LGWR switch)
Current log# 3 seq# 1299 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 19:01:59 2010
Thread 1 advanced to log sequence 1300 (LGWR switch)
Current log# 1 seq# 1300 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 19:09:21 2010
Thread 1 advanced to log sequence 1301 (LGWR switch)
Current log# 2 seq# 1301 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Tue Oct 05 19:17:37 2010
Thread 1 advanced to log sequence 1302 (LGWR switch)
Current log# 3 seq# 1302 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 20:56:07 2010
Thread 1 cannot allocate new log, sequence 1303
Private strand flush not complete
Current log# 3 seq# 1302 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG
Tue Oct 05 20:56:09 2010
Thread 1 advanced to log sequence 1303 (LGWR switch)
Current log# 1 seq# 1303 mem# 0: D:\BASES\MYDB\LOGS\REDO01.LOG
Tue Oct 05 20:56:10 2010
ALTER SYSTEM ARCHIVE LOG
Tue Oct 05 20:56:10 2010
Thread 1 advanced to log sequence 1304 (LGWR switch)
Current log# 2 seq# 1304 mem# 0: D:\BASES\MYDB\LOGS\REDO02.LOG
Wed Oct 06 03:22:58 2010
Thread 1 advanced to log sequence 1305 (LGWR switch)
Current log# 3 seq# 1305 mem# 0: D:\BASES\MYDB\LOGS\REDO03.LOG

Datafiles and control file corrupted

I have oracle 9i installed on windows 2003 server. A couple of days before our windows crashed and the system administrator took the backup of all files and reinstalled windows. After reinstallation of windows I restored the files backed up by system administrator and tried to start the database. I got the following error:
ORA-00227: corrupt block detected in controlfile: (block 1, # blocks 1)
ORA-00202: controlfile: 'D:\ORACLE\ORADATA\ORCL\CONTROL03.CTL'
All the multiplexed copies of control files are also corrupted. We do not have the backup since last few days and the database is in noarchivelog mode. Simple restoration to the old backup would be a great loss. Kindly help me to recover the control file and datafiles.

All the multiplexed copies of control files are also corrupted. We do not have the backup since last few days and the database is in noarchivelog mode. Simple restoration to the old backup would be a great loss. Kindly help me to recover the control file and datafiles.You could try to re-create the control files assuming the database itself was closed properly.
However you should only do this if you know what you are doing.
In any case you should backup the database in its current state in case things getting worse by trying to recover. CHECK this backup twice!
In any case: Open a support ticket at Oracle. You will most probably need their help.
In addition to that - it look quite bad for your data. You should prepare for data loss (just to be sure; i dont want to scare you)....
Ronny Egner
My Blog: http://blog.ronnyegner-consulting.de

Corrupted control file?

Hi there,
I have an Oracle 10.2.0.3 DB running on Solaris 10 update 5, SPARC 64-bit.
I recently noticed that there are a number of files in my backupsets that have been flagged as corrupt:
<pre>
SQL> select recid, stamp, set_count, file#, marked_corrupt, media_corrupt, logically_corrupt
2 from v$backup_datafile
3 where checkpoint_change# >= 2215146265248
4 and (marked_corrupt > 0 or media_corrupt > 0 or logically_corrupt > 0);
</pre>
<pre>
RECID STAMP SET_COUNT FILE# MARKED_CORRUPT MEDIA_CORRUPT LOGICALLY_CORRUPT
99977 746035916 15992 0 2011 317 1
99978 746132372 15998 0 2011 318 0
99979 746153962 15999 0 2011 319 0
</pre>
File#=0 means that this is corruption is on the control file.
I checked a couple other views for more information, but I can't find anything about this:
<pre>
SQL> select * from v$backup_corruption;
no rows selected
SQL> select * from v$database_block_corruption;
no rows selected
</pre>
Can anyone please explain what this information really means and how bad of a situation this is? What methods are available to resolve this issue?

Thanks for answering so quickly.
There are 3 copies of the controlfile available. They all have the same size & timestamp:
<pre>
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control01.ctl
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control02.ctl
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control03.ctl
</pre>
DB is operating normally. We did have problems with our RMAN backups (incremental level 0) over this past weekend to our external tape system, which led me down this path.
There are no errors in the alert log.
I am not completely convinced my control files are corrupted though. What would be an easy way to check for corruption without taking DB down?

Corrupt control file

Hello,
I try to simulate some recovery scenarios. My Oracle 11g database is configured with two control files. I've stopped the database and corrupted one of the control files by editing it with some random characters using a hex editor. When I've started the database everything went as nothing has happened. No alerts, no errors, in Enterprise Manager the control file status is VALID. I've opened the control file, but is still edited (so it wasn't automatically replaced with the good one, which is not a good thing anyway).
Why is this happening? The system can't alert me if one of the control files is corrupted?
Thank you,
Adrian
Edited by: Adrian P on Dec 7, 2010 10:10 AM

Adrian P wrote:
Hello,
I try to simulate some recovery scenarios. My Oracle 11g database is configured with two control files. I've stopped the database and corrupted one of the control files by editing it with some random characters using a hex editor. When I've started the database everything went as nothing has happened. No alerts, no errors, in Enterprise Manager the control file status is VALID. I've opened the control file, but is still edited (so it wasn't automatically replaced with the good one, which is not a good thing anyway).
Why is this happening? The system can't alert me if one of the control files is corrupted?
Thank you,
Adrian
Edited by: Adrian P on Dec 7, 2010 10:10 AMThat is not possible,if one controlfile is corrupted then database will automatically shutdown with abort option(while running) else if when after shutdown one controlfile was corrupted then next startup you must get an error like ORA-00205: error in identifying control file ,so you need recover/repair this.I think you did not impact current active controlfile.Please query used controlfile from v$controlfile

Data corrupt block

os Sun 5.10 oracle version 10.2.0.2 RAC 2 node
alert.log 내용
Hex dump of (file 206, block 393208) in trace file /oracle/app/oracle/admin/DBPGIC/udump/dbpgic1_ora_1424.trc
Corrupt block relative dba: 0x3385fff8 (file 206, block 393208)
Bad header found during backing up datafile
Data in bad block:
type: 32 format: 0 rdba: 0x00000001
last change scn: 0x0000.98b00394 seq: 0x0 flg: 0x00
spare1: 0x1 spare2: 0x27 spare3: 0x2
consistency value in tail: 0x00000001
check value in block header: 0x0
block checksum disabled
Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
corrupt 발생한 Block id 를 검색해 보면 Block id 가 검색이 안됩니다.
dba_extents 로 검색
corrupt 때문에 Block id 가 검색이 안되는 것인지 궁금합니다.
export 받으면 데이타는 정상적으로 export 가능.

다행이네요. block corruption 이 발생한 곳이 데이터가 저장된 블록이
아닌 것 같습니다. 그것도 rman백업을 통해서 발견한 것 같는데
맞는지요?
scn이 scn: 0x0000.00000000 가 아닌
0x0000.98b00394 인 것으로 봐서는 physical corrupt 가 아닌
soft corrupt인 것 같습니다.
그렇다면 버그일 가능성이 높아서 찾아보니
Bug 4411228 - Block corruption with mixture of file system and RAW files
의 버그가 발견되었습니다. 이것이 아닐 수도 있지만..
이러한 block corruption에 대한 처리방법 및 원인분석은
오라클(주)를 통해서 정식으로 요청하셔야 합니다.
metalink를 통해서 SR 요청을 하십시오.
export는 high water mark 이후의 block corruption을 찾아내지 못하고 이외에도
아래 몇가지 경우에서도 찾아내지 못합니다.
db verify( dbv)의 경우에는 physical corruption은 찾아내지 못하고
soft block corruption만 찾아낼 수 있습니다.
경험상 physical corruption 이 발생하였으나 /dev/null로
datafile copy가 안되는데도 dbv로는 이 문제를 찾아내지
못하였습니다.
그렇다면 가장 좋은 방법은 rman 입니다. rman은 high water mark까지의
데이터를 백업해주면서 전체 데이터파일에 대한 체크를 하기도 합니다.
physical corruption뿐만 아니라 logical corruption도 체크를
하니 점검하기로는 rman이 가장 좋은 방법이라 생각합니다.
The Export Utility
# Use a full export to check database consistency
# Export performs a full scan for all tables
# Export only reads:
- User data below the high-water mark
- Parts of the data dictionary, while looking up information concerning the objects being exported
# Export does not detect the following:
- Disk corruptions above the high-water mark
- Index corruptions
- Free or temporary extent corruptions
- Column data corruption (like invalid date values)
block corruption을 정상적으로 복구하는 방법은 restore 후에
복구하는 방법이 있겠으나 이미 restore할 백업이 block corruption이
발생했을 수도 있습니다. 그러므로 다른 서버에 restore해보고
정상적인 datafile인 것을 확인 후에 실환경에 restore하는 것이 좋습니다.
만약 백업본까지 block corruption이 발생하였거나 또는 시간적 여유가
없을 경우에는 table을 move tablespace 또는 index rebuild를 통해서
다른 테이블스페이스로 데이터를 옮겨두고 문제가 발생한 테이블스페이스를
drop해버리고 재생성 하는 것이 좋을 것 같습니다.(지금 현재 데이터의
손실은 없으니 move tablespace, rebuild index 방법이 좋겠습니다.
Handling Corruptions
Check the alert file and system log file
Use diagnostic tools to determine the type of corruption
Dump blocks to find out what is wrong
Determine whether the error persists by running checks multiple times
Recover data from the corrupted object if necessary
Preferred resolution method: media recovery
Handling Corruptions
Always try to find out if the error is permanent. Run the analyze command multiple times or, if possible, perform a shutdown and a startup and try again to perform the operation that failed earlier.
Find out whether there are more corruptions. If you encounter one, there may be other corrupted blocks, as well. Use tools like DBVERIFY for this.
Before you try to salvage the data, perform a block dump as evidence to identify the actual cause of the corruption.
Make a hex dump of the bad block, using UNIX dd and od -x.
Consider performing a redo log dump to check all the changes that were made to the block so that you can discover when the corruption occurred.
Note: Remember that when you have a block corruption, performing media recovery is the recommended process after the hardware is verified.
Resolve any hardware issues:
- Memory boards
- Disk controllers
- Disks
Recover or restore data from the corrupt object if necessary
Handling Corruptions (continued)
There is no point in continuing to work if there are hardware failures. When you encounter hardware problems, the vendor should be contacted and the machine should be checked and fixed before continuing. A full hardware diagnostics should be run.
Many types of hardware failures are possible:
Bad I/O hardware or firmware
Operating system I/O or caching problem
Memory or paging problems
Disk repair utilities
아래 관련 자료를 드립니다.
All About Data Blocks Corruption in Oracle
Vijaya R. Dumpa
Data Block Overview:
Oracle allocates logical database space for all data in a database. The units of database space allocation are data blocks (also called logical blocks, Oracle blocks, or pages), extents, and segments. The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks allocated for storing a specific type of information. The level of logical database storage above an extent is called a segment. The high water mark is the boundary between used and unused space in a segment.
The header contains general block information, such as the block address and the type of segment (for example, data, index, or rollback).
Table Directory, this portion of the data block contains information about the table having rows in this block.
Row Directory, this portion of the data block contains information about the actual rows in the block (including addresses for each row piece in the row data area).
Free space is allocated for insertion of new rows and for updates to rows that require additional space.
Row data, this portion of the data block contains rows in this block.
Analyze the Table structure to identify block corruption:
By analyzing the table structure and its associated objects, you can perform a detailed check of data blocks to identify block corruption:
SQL> analyze table_name/index_name/cluster_name ... validate structure cascade;
Detecting data block corruption using the DBVERIFY Utility:
DBVERIFY is an external command-line utility that performs a physical data structure integrity check on an offline database. It can be used against backup files and online files. Integrity checks are significantly faster if you run against an offline database.
Restrictions:
DBVERIFY checks are limited to cache-managed blocks. It’s only for use with datafiles, it will not work against control files or redo logs.
The following example is sample output of verification for the data file system_ts_01.dbf. And its Start block is 9 and end block is 25. Blocksize parameter is required only if the file to be verified has a non-2kb block size. Logfile parameter specifies the file to which logging information should be written. The feedback parameter has been given the value 2 to display one dot on the screen for every 2 blocks processed.
$ dbv file=system_ts_01.dbf start=9 end=25 blocksize=16384 logfile=dbvsys_ts.log feedback=2
DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Output:
$ pg dbvsys_ts.log
DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = system_ts_01.dbf
DBVERIFY - Verification complete
Total Pages Examined : 17
Total Pages Processed (Data) : 10
Total Pages Failing (Data) : 0
Total Pages Processed (Index) : 2
Total Pages Failing (Index) : 0
Total Pages Processed (Other) : 5
Total Pages Empty : 0
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Detecting and reporting data block corruption using the DBMS_REPAIR package:
Note: Note that this event can only be used if the block "wrapper" is marked corrupt.
Eg: If the block reports ORA-1578.
1. Create DBMS_REPAIR administration tables:
To Create Repair tables, run the below package.
SQL> EXEC DBMS_REPAIR.ADMIN_TABLES(‘REPAIR_ADMIN’, 1,1, ‘REPAIR_TS’);
Note that table names prefix with ‘REPAIR_’ or ‘ORPAN_’. If the second variable is 1, it will create ‘REAIR_key tables, if it is 2, then it will create ‘ORPAN_key tables.
If the thread variable is
1 then package performs ‘create’ operations.
2 then package performs ‘delete’ operations.
3 then package performs ‘drop’ operations.
2. Scanning a specific table or Index using the DBMS_REPAIR.CHECK_OBJECT procedure:
In the following example we check the table employee for possible corruption’s that belongs to the schema TEST. Let’s assume that we have created our administration tables called REPAIR_ADMIN in schema SYS.
To check the table block corruption use the following procedure:
SQL> VARIABLE A NUMBER;
SQL> EXEC DBMS_REPAIR.CHECK_OBJECT (‘TEST’,’EMP’, NULL,
1,’REPAIR_ADMIN’, NULL, NULL, NULL, NULL,:A);
SQL> PRINT A;
To check which block is corrupted, check in the REPAIR_ADMIN table.
SQL> SELECT * FROM REPAIR_ADMIN;
3. Fixing corrupt block using the DBMS_REPAIR.FIX_CORRUPT_BLOCK procedure:
SQL> VARIABLE A NUMBER;
SQL> EXEC DBMS_REPAIR.FIX.CORRUPT_BLOCKS (‘TEST’,’EMP’, NULL,
1,’REPARI_ADMIN’, NULL,:A);
SQL> SELECT MARKED FROM REPAIR_ADMIN;
If u select the EMP table now you still get the error ORA-1578.
4. Skipping corrupt blocks using the DBMS_REPAIR. SKIP_CORRUPT_BLOCK procedure:
SQL> EXEC DBMS_REPAIR. SKIP_CORRUPT.BLOCKS (‘TEST’, ‘EMP’, 1,1);
Notice the verification of running the DBMS_REPAIR tool. You have lost some of data. One main advantage of this tool is that you can retrieve the data past the corrupted block. However we have lost some data in the table.
5. This procedure is useful in identifying orphan keys in indexes that are pointing to corrupt rows of the table:
SQL> EXEC DBMS_REPAIR. DUMP ORPHAN_KEYS (‘TEST’,’IDX_EMP’, NULL,
2, ‘REPAIR_ADMIN’, ‘ORPHAN_ADMIN’, NULL,:A);
If u see any records in ORPHAN_ADMIN table you have to drop and re-create the index to avoid any inconsistencies in your queries.
6. The last thing you need to do while using the DBMS_REPAIR package is to run the DBMS_REPAIR.REBUILD_FREELISTS procedure to reinitialize the free list details in the data dictionary views.
SQL> EXEC DBMS_REPAIR.REBUILD_FREELISTS (‘TEST’,’EMP’, NULL, 1);
NOTE
Setting events 10210, 10211, 10212, and 10225 can be done by adding the following line for each event in the init.ora file:
Event = "event_number trace name errorstack forever, level 10"
When event 10210 is set, the data blocks are checked for corruption by checking their integrity. Data blocks that don't match the format are marked as soft corrupt.
When event 10211 is set, the index blocks are checked for corruption by checking their integrity. Index blocks that don't match the format are marked as soft corrupt.
When event 10212 is set, the cluster blocks are checked for corruption by checking their integrity. Cluster blocks that don't match the format are marked as soft corrupt.
When event 10225 is set, the fet$ and uset$ dictionary tables are checked for corruption by checking their integrity. Blocks that don't match the format are marked as soft corrupt.
Set event 10231 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing full table scans:
Event="10231 trace name context forever, level 10"
Set event 10233 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing index range scans:
Event="10233 trace name context forever, level 10"
To dump the Oracle block you can use below command from 8.x on words:
SQL> ALTER SYSTEM DUMP DATAFILE 11 block 9;
This command dumps datablock 9 in datafile11, into USER_DUMP_DEST directory.
Dumping Redo Logs file blocks:
SQL> ALTER SYSTEM DUMP LOGFILE ‘/usr/oracle8/product/admin/udump/rl. log’;
Rollback segments block corruption, it will cause problems (ORA-1578) while starting up the database.
With support of oracle, can use below under source parameter to startup the database.
CORRUPTEDROLLBACK_SEGMENTS=(RBS_1, RBS_2)
DB_BLOCK_COMPUTE_CHECKSUM
This parameter is normally used to debug corruption’s that happen on disk.
The following V$ views contain information about blocks marked logically corrupt:
V$ BACKUP_CORRUPTION, V$COPY_CORRUPTION
When this parameter is set, while reading a block from disk to catch, oracle will compute the checksum again and compares it with the value that is in the block.
If they differ, it indicates that the block is corrupted on disk. Oracle makes the block as corrupt and signals an error. There is an overhead involved in setting this parameter.
DB_BLOCK_CACHE_PROTECT=‘TRUE’
Oracle will catch stray writes made by processes in the buffer catch.
Oracle 9i new RMAN futures:
Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the alert.log, trace files, or a media management interface. For example, you may see the following in a trace file:
ORA-01578: ORACLE data block corrupted (file # 9, block # 13)
ORA-01110: data file 9: '/oracle/dbs/tbs_91.f'
ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
ORA-01110: data file 2: '/oracle/dbs/tbs_21.f'
$rman target =rman/rman@rmanprod
RMAN> run {
2> allocate channel ch1 type disk;
3> blockrecover datafile 9 block 13 datafile 2 block 19;
4> }
Recovering Data blocks Using Selected Backups:
# restore from backupset
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
# restore from datafile image copy
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM DATAFILECOPY;
# restore from backupset with tag "mondayAM"
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 199 FROM TAG = mondayAM;
# restore using backups made before one week ago
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
UNTIL 'SYSDATE-7';
# restore using backups made before SCN 100
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE UNTIL SCN 100;
# restore using backups made before log sequence 7024
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
UNTIL SEQUENCE 7024;
글 수정:
Min Angel (Yeon Hong Min, Korean)

RMAN Skips the corrupted Block

Hi,
We are using Oracle 10.2.0.4 rman utility for backup, In SYSAUX tablespace, datafile 3, one block has been corrupted.
I have try to export the tablespace , i found warning message of "corrupted block and table name". But RMAN, while try to backup datafile 3, or validate the backup, it doesn't popu any error message and went through with out any problem.
==>I have set maxcorrupt 0 in run block
==> Check logical i have used
==> V$database_block_corruption pops the result but MAXCORRUPT 0.
==> But Analyis the table show the corrupted block error.
===> Try to select * from corrupted table. it throws the error message.
Please advice
Regards
Krish

Steve,
Thank you for the doc, But i have already mentioned,
--> i have tried from check logical
--> Also MaxCorrupt parameter
Am able to view the corrutped block information in database_block_corruption
but while backing with rman using
RMAN> run
2> {
3> set MAXCORRUPT for datafile 3 to 0;
4> backup datafile 3;
5> }
executing command: SET MAX CORRUPT
using target database control file instead of recovery catalog
Starting backup at 27-APR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=12 instance=TEST devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00003 name=+DBFILE_GRP1/TEST/datafile/sysaux.499.667900479
channel ORA_DISK_1: starting piece 1 at 27-APR-09
channel ORA_DISK_1: finished piece 1 at 27-APR-09
piece handle=/usr/oradata/BKUP/TEST/backup/database/BIRTEF1_4229_1_1_45kdh7uj tag=TAG
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 27-APR-09
Starting Control File and SPFILE Autobackup at 27-APR-09
Finished Control File and SPFILE Autobackup at 27-APR-09
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 23260 1 0 CORRUPT
3 123228 1 0 CORRUPT
ITs backing up with no issues. Thats the confusion here.
REgards
KRishnan

RAC control file has correpted, unable to mount database

hi guru's,
Im trying to startup my rac db, but it giving following error.
SQL> startup
ORACLE instance started.
Total System Global Area 233861120 bytes
Fixed Size 2212088 bytes
Variable Size 176164616 bytes
Database Buffers 50331648 bytes
Redo Buffers 5152768 bytes
ORA-00221: error on write to control file
ORA-00206: error in writing (block 1, # blocks 1) of control file
ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
alert log:
Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group 2 on disk 1 allocation unit 78
Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 2 on disk 2 allocation unit 76
Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 3 of virtual extent 0 logical extent 2 of file 256 in group 2 on disk 3 allocation unit 78
Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
ORA-00206: error in writing (block 1, # blocks 1) of control file
ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
ORA-221 signalled during: ALTER DATABASE MOUNT...
trace file:
Trace file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
ORACLE_HOME = /rdbms1/app/oracle/product/11.2.0/db_home/
System name: Linux
Node name: RAC-NODE1.vod.com
Release: 2.6.18-128.el5
Version: #1 SMP Wed Dec 17 11:41:38 EST 2008
Machine: x86_64
Instance name: finance1
Redo thread mounted by this instance: 0 <none>
Oracle process number: 28
Unix process pid: 11821, image: [email protected] (TNS V1-V3)
*** 2013-04-27 00:02:39.859
*** SESSION ID:(1.3) 2013-04-27 00:02:39.859
*** CLIENT ID:() 2013-04-27 00:02:39.859
*** SERVICE NAME:() 2013-04-27 00:02:39.859
*** MODULE NAME:([email protected] (TNS V1-V3)) 2013-04-27 00:02:39.859
*** ACTION NAME:() 2013-04-27 00:02:39.859
ORA-27041: unable to open file
WARNING: IO Failed. group:2 disk(number.incarnation):1.0xe96d8019 disk_path:/dev/sdd2
AU:78 disk_offset(bytes):81805312 io_size:16384 operation:Write type:asynchronous
result:I/O error process_id:11821
subsys:System iop:0x2b1c84e57250 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
ORA-27041: unable to open file
WARNING: IO Failed. group:2 disk(number.incarnation):2.0xe96d801a disk_path:/dev/sdd3
AU:76 disk_offset(bytes):79708160 io_size:16384 operation:Write type:asynchronous
result:I/O error process_id:11821
subsys:System iop:0x2b1c84e57128 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
ORA-27041: unable to open file
WARNING: IO Failed. group:2 disk(number.incarnation):3.0xe96d8018 disk_path:/dev/sdd4
AU:78 disk_offset(bytes):81805312 io_size:16384 operation:Write type:asynchronous
result:I/O error process_id:11821
subsys:System iop:0x2b1c84e57000 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group 2 on disk 1 allocation unit 78
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 2 on disk 2 allocation unit 76
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 3 of virtual extent 0 logical extent 2 of file 256 in group 2 on disk 3 allocation unit 78
DDE rules only execution for: ORA 202
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
Successfully dispatched
----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
ORA-00206: error in writing (block 1, # blocks 1) of control file
ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
all the diskgroups are in mount state only
SQL> select name,state from v$asm_diskgroup;
NAME STATE
ARCLOG MOUNTED
CTRL MOUNTED
DBFILE MOUNTED
FRA MOUNTED
REDO1 MOUNTED
REDO2 MOUNTED
VOTE MOUNTED
since i did not have mirror copy or backup of current control file to replace the correpted one.
Is there any way to create new control file and transfered to ASM diskgroup and open database. or i need to drop the existing database.
if i need to drop the db, without open the db how to drop database.
kindly help on this.
Thanks in advance.

Hi,
Thanks for the replay. im able to open the db.
But can you tel me how to make my rac db to open with spfile which is on asmdiskgroup.
SQL> select name,state from v$asm_diskgroup;
NAME STATE
ARCLOG MOUNTED
CTRL MOUNTED
DBFILE MOUNTED
FRA MOUNTED
REDO1 MOUNTED
REDO2 MOUNTED
VOTE MOUNTED
Spfile:
ASMCMD [+DBFILE/FINANCE/PARAMETERFILE] > pwd
+DBFILE/FINANCE/PARAMETERFILE
ASMCMD [+DBFILE/FINANCE/PARAMETERFILE] > ls
spfile.262.813843989
i shutdown the db and up the same but it can't take the spfile.
SQL> show parameter spfile
NAME TYPE VALUE
spfile string
Thanks in advance.

ORACLE 8.0.5 on SuSE 5.3 and 6.0 - Corrupt Block

I do some heavy loading (Designer 2000) and I do get similar
errors on 2 different computer with mirrored disks -different
systems - on each one. So I'd like to exclude hardware problems.
it's experimental - so I do not run archives -
Designer on W95 crashes quite often but this should never lead
to corrupted data blocks.
Linux was hanging too - and disk-cache might not have been
written to disk ????? could this be a reason ???
Corrupt block relative dba: 0x01003aa8 file=4. blocknum=15016.
Fractured block found during buffer read
Data in bad block - type:6. format:2. rdba:0x01003aa8
last change scn:0x0000.00014914 seq:0x3 flg:0x00
consistancy value in tail 0x496b0605
check value in block header: 0x0, check value not calculated
spare1:0x0, spare2:0x0, spare2:0x0
would be happy to get some feedback
null

Ferdinand Gassauer (guest) wrote:
: I do some heavy loading (Designer 2000) and I do get similar
: errors on 2 different computer with mirrored disks -different
: systems - on each one. So I'd like to exclude hardware
problems.
: it's experimental - so I do not run archives -
: Designer on W95 crashes quite often but this should never lead
: to corrupted data blocks.
: Linux was hanging too - and disk-cache might not have been
: written to disk ????? could this be a reason ???
: Corrupt block relative dba: 0x01003aa8 file=4. blocknum=15016.
: Fractured block found during buffer read
: Data in bad block - type:6. format:2. rdba:0x01003aa8
: last change scn:0x0000.00014914 seq:0x3 flg:0x00
: consistancy value in tail 0x496b0605
: check value in block header: 0x0, check value not calculated
: spare1:0x0, spare2:0x0, spare2:0x0
: would be happy to get some feedback
Please check first /var/log/messages for any linux errors. It is
likely that if linux crashes and cannot sync to disk that there
might be some corruption problems. For this reason lts of people
would like to see raw device support but apparently Linus is not
willing for some reason...
I assume some hardware relevant problems though
Marcus
null

Corrupt block relative dba: 0x0041470c

Corrupt block relative dba: 0x0041470c (file 1, block 83724)
Fractured block found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x0041470c
last change scn: 0x0009.90b485ad seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000000
check value in block header: 0x3092
computed block checksum: 0x19de
Wed Oct 03 09:58:32 GMT-4 2012
Reread of rdba: 0x0041470c (file 1, block 83724) found same corrupted data
Wed Oct 03 09:58:32 GMT-4 2012
Errors in file /opt/oracle/admin/IXP/bdump/ixp_smon_19661.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-08103: object no longer exists

962800 wrote:
Corrupt block relative dba: 0x0041470c (file 1, block 83724)
Fractured block found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x0041470c
last change scn: 0x0009.90b485ad seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000000
check value in block header: 0x3092
computed block checksum: 0x19de
Wed Oct 03 09:58:32 GMT-4 2012
Reread of rdba: 0x0041470c (file 1, block 83724) found same corrupted data
Wed Oct 03 09:58:32 GMT-4 2012
Errors in file /opt/oracle/admin/IXP/bdump/ixp_smon_19661.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-08103: object no longer exists
Its not a corrupted block but a fractured block and also the object is not there anymore. So there is nothing that you are supposed to do.
Aman....

Corrupt block error + valid data found ???

Hi,
I am getting a peculiar block corruption error in my production database (9.2.0.8).
It also says "valid data found". I am able to analyze the suspect table without any reported issues. Can any one please suggest?
Details from Alertlog below:-
Corrupt block relative dba: 0x01463cbf (file 5, block 408767)
Bad header found during user buffer read
Data in bad block -
type: 50 format: 0 rdba: 0x3a383020
last change scn: 0x0338.303a3630 seq: 0xc2 flg: 0x38
consistency value in tail: 0x36302036
check value in block header: 0x3c27, block checksum disabled
spare1: 0x30, spare2: 0x36, spare3: 0x1502
Reread of rdba: 0x01463cbf (file 5, block 408767) found valid data
Hex dump of Absolute File 5, Block 408768 in trace file d:\oracle\admin\fm\udump\fm_ora_5236.trc
---------------------------------------------------------------------------------------------

Hi,
May be this will help
Data block corruption…..
Regards
Jafar

ORA-00202: control file: '/u01/app/oracle/product/11.2.0.2/db_1/dbs/snapcf_

RMAN> register database;
database registered in recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03008: error while performing automatic resync of recovery catalog
ORA-00206: error in writing (block 29824, # blocks 64) of control file
ORA-00202: control file: '/u01/app/oracle/product/11.2.0.2/db_1/dbs/snapcf_bibp1.f'
ORA-27072: File I/O error
Additional information: 4
Additional information: 29824
Additional information: 200704
I have created catalog server and want to configure on both node.its RAC env. bibp1 and bibp2
when am trying to register the database when give me above error.

In 11.2.0.2, the Snapshot Control file must be on a Clustered File System or ASM. It cannot be on a local filesystem.
See Oracle Support Notes
RMAN Snapshot Controlfile Must Reside on Shared Device for RAC database in 11G [ID 1263621.1]
In RAC environment from 11.2 onwards Backup Or Snapshot controlfile needs to be in shared location [ID 1472171.1]
You need to :
CONFIGURE SNAPSHOT CONTROLFILE NAME TO <shared_location_file>;Hemant K Chitale

Corrupt block detected in control file

Similar Messages

Maybe you are looking for