Corrupt Block Found

Hi,
on 10g R2, Win server 2003, I have this error :
Corrupt Block Found
         TSN = 2, TSNAME = SYSAUX
         RFN = 3, BLK = 36473, RDBA = 12619385
         OBJN = 150506, OBJD = 150506, OBJECT = MGMT_METRICS_RAW_PK, SUBOBJECT =
         SEGMENT OWNER = SYSMAN, SEGMENT TYPE = Index SegmentHow to identify this corrupted block ?
How to remedy ?
Thank you.

There're many solutions to resolve block corruption. One of them is by using DBMS_REPAIR
Look at this link http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#i1006090
Kamran Agayev A. (10g OCP)
http://kamranagayev.wordpress.com

Similar Messages

Corrupt block relative dba: in alert log

hi,
In our recovery database,I've found following error in alert log.
Thu Mar 27 07:05:57 2008
Hex dump of (file 3, block 30826) in trace file /u01/app/oracle/admin/catdb/bdump/catdb_m000_21795.trc
Corrupt block relative dba: 0x00c0786a (file 3, block 30826)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x00c0786a
last change scn: 0x0000.0013ed4d seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xed4d0601
check value in block header: 0x937c
computed block checksum: 0x8000
Reread of rdba: 0x00c0786a (file 3, block 30826) found same corrupted data
Thu Mar 27 07:05:59 2008
Corrupt Block Found
TSN = 2, TSNAME = SYSAUX
RFN = 3, BLK = 30826, RDBA = 12613738
OBJN = 8964, OBJD = 8964, OBJECT = WRH$_ENQUEUE_STAT, SUBOBJECT =
SEGMENT OWNER = SYS, SEGMENT TYPE = Table Segment
Now, how solve this error?
Thanks in advance.
Leo

Refer to metalink Note:77587.1. You may need to do further sanity block checking by placing the following parameters in the database instance init.ora parameter file:
db_block_checking=true
db_block_checksum=true
dbblock_cache_protect= true
Consult Oracle support before changing hidden parameters.

Finding Total Number Of Corrupted Blocks

Hello,
I just browsed several websites including RMAN documentation and information on how to identifiy corrupted blocks.
I´m in the middle of reorganizing production backups and their restore tests by duplication, which should (in my opinion) be followed by an analysis for corrupted blocks.
I found RMAN command BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL; to fit my needs. Recently I read the validate command only writes NEWLY found corrupted blocks to View V$DATABASE_BLOCK_CORRUPTION.
1. How do I check the WHOLE database for its TOTAL physical and logical corrupted blocks?
2.Under which circumstances is it NOT necesssary to check the database after the restore? In other words is there a way to ensure the backup cancels immediately when finding a corrupted block?
3. Is it necessary to set maxcorrupt to "0" during the Backup to get it cancelled for every corrupted block found?
4. What does dbv in contrast to backup validation?
Please be so kind to post me some short hints.
Regards
Dominik

Hi,
thanks for your feedback again.
Yesterday I "accidently" faced the situation to work with a block corrupted database during a restore test.
So I had the chance to run both backup validate and dbv against its corrupted files.
dbv worked fine, recognized all corrupted blocks and reported them in its output.
Disappointingly backup validate neither reportted any corrupt withtin the whole database (there are several datafiles with corrupted blocks), nor posted them to V$DATABASE_BLOCK_CORRUPTION. There I could only find a hand full, but not all of them.
I´m very consufed now, what would I need backup validate for anymore??? :-/
I built myself a script to check the whole database with dbverify. Regarding production databases we cannot live with uncertainties like that
Regards
Dominik

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

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

Recovery is repairing media corrupt block x of file x in standby alert log

Hi,
oracle version:8.1.7.0.0
os version :solaris 5.9
we have oracle 8i primary and standby database. i am getting erorr in alert log file:
Thu Aug 28 22:48:12 2008
Media Recovery Log /oratranslog/arch_1_1827391.arc
Thu Aug 28 22:50:42 2008
Media Recovery Log /oratranslog/arch_1_1827392.arc
bash-2.05$ tail -f alert_pindb.log
Recovery is repairing media corrupt block 991886 of file 179
Recovery is repairing media corrupt block 70257 of file 184
Recovery is repairing media corrupt block 70258 of file 184
Recovery is repairing media corrupt block 70259 of file 184
Recovery is repairing media corrupt block 70260 of file 184
Recovery is repairing media corrupt block 70261 of file 184
Thu Aug 28 22:48:12 2008
Media Recovery Log /oratranslog/arch_1_1827391.arc
Thu Aug 28 22:50:42 2008
Media Recovery Log /oratranslog/arch_1_1827392.arc
Recovery is repairing media corrupt block 500027 of file 181
Recovery is repairing media corrupt block 500028 of file 181
Recovery is repairing media corrupt block 500029 of file 181
Recovery is repairing media corrupt block 500030 of file 181
Recovery is repairing media corrupt block 500031 of file 181
Recovery is repairing media corrupt block 991837 of file 179
Recovery is repairing media corrupt block 991838 of file 179
how i can resolve this.
[pre]
Thanks
Prakash
Edited by: user612485 on Aug 28, 2008 10:53 AM

Dear satish kandi,
recently we have created index for one table with nologgign option, i think for that reason i am getting that error.
if i run dbv utility on the files which are shown in alert log file i am getting the following results.
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx055.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:18:27 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx053.dbf
Block Checking: DBA = 751593895, Block Type =
Found block already marked corrupted
Block Checking: DBA = 751593896, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 1036952
Total Pages Failing (Index): 0
Total Pages Processed (Other): 7342
Total Pages Empty : 4282
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx053.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:23:12 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx054.dbf
Block Checking: DBA = 759492966, Block Type =
Found block already marked corrupted
Block Checking: DBA = 759492967, Block Type =
Found block already marked corrupted
Block Checking: DBA = 759492968, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 585068
Total Pages Failing (Index): 0
Total Pages Processed (Other): 8709
Total Pages Empty : 454799
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx054.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:32:28 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx055.dbf
Block Checking: DBA = 771822208, Block Type =
Found block already marked corrupted
Block Checking: DBA = 771822209, Block Type =
Found block already marked corrupted
Block Checking: DBA = 771822210, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 157125
Total Pages Failing (Index): 0
Total Pages Processed (Other): 4203
Total Pages Empty : 887248
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
My doubts are :
1.if i drop the index and recreate the index with logging option will this error won't repeat in alert log file
2.in future if i activate the standby database will database is going to open without any error.
Thanks
Prakash
.

ORA-19566: exceeded limit of 999 corrupt blocks for file

Hi All,
I am new to Oracle RMAN & RAC Administration. Looking for your support to solve the below issue.
We have 2 disk groups - +ETDATA & +ETFLASH in our 3 node RAC environments in which RMAN is configured in node-2 to take backup. We do not have RMAN catalog and the RMAN is fetching information from control file.
Recently, the backup failed with the error ORA-19566: exceeded limit of 999 corrupt blocks for file +ETFLASH/datafile/users.6187.802328091.
We found that the datafiles are present in both disk groups and from the control file info, we got to know that the datafiles in +ETDATA are currently in use and +ETFLASH is having old datafiles.
RMAN> show all;
RMAN configuration parameters for database with db_unique_name LABWRKT are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ETFLASH/CONTROLFILE/snapcf_LABWRKT.f';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ETFLASH/controlfile/snapcf_labwrkt.f';
Above configuration shows that SNAPSHOT CONTROLFILE is pointing to +ETFLASH. So I changed the configuration with the SNAPSHOT CONTROLFILE points to '+ETDATA/controlfile/snapcf_labwrkt.f'. At the end of backup, SNAPSHOT file was created in +ETDATA and I was expecting it to be the copy of control file being used which has dbf located in +ETDATA. But still the backup was pointing to old datafiles in +ETFLASH. Since we dont have RMAN catalog, resync also is not possible.
When I ran it manually, it was successfull without any error and was pointing to the exisiting datafiles.
RMAN> backup database plus archivelog all;
I hope the issue will get resolved if the RMAN points only to the datafiles present in +ETDATA. If I am correct, please let me know how can i make it possible? Also please explain me why the newly created snapshot file does not reflect the existing control file info?

Hi,
I am getting an error from the DBA Planning Calendar every time the job ...
So when was your last successfull backup of this datafile. Check if still available.
If this is some time ago, and may be you are currently without any backup, try to backup without rman at once,
to have at least something to work with in case you get additional errors right now.
Then you need to find out what object is affected. You are on the right way already. You need the statement,
that goes to dba_extents to check what object the block belongs to.
Has the DB been recovered recently, so the block might possibly belong to an index created with nologging ?
(this could be the case on BW systems).
If the last good backup of that file is still available and the redologs belonging to this backup up to current time are as well, you could try to recover that file. But I'd do this only after a good backup without rman and by not destroying the original file.
If the last good backup was an rman backup, you can do a verify restore of that datafile in advance, to check if the corruption is really not inside the file to be restored.
Check out the -w (verify) option of brrestore first, to understand how it works.
(I am not sure it this is already available in version 7.00, may be you need to switch to 7.10 or 7.20)
brrestore -c -m /oracle/SHD/sapdata4/sr3_16/sr3.data16 -b xxxxxxxx.ffr -w only_rmv
You should do a dbv check of that file as well, to check if it gets more information. I.E if more blocks are
affected. rman stops right after the first corruption, but usually you have a couple of those in line, esp. if these are
zeroed ones. (This one would also work with version 7.00 brtools)
brbackup -c -u / -t online -m /oracle/SHD/sapdata4/sr3_16/sr3.data16 -w only_dbv
Good luck.
Volker

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....

Does a truncate table solve corrupt blocks in a table

Hi Guys,
Got a question:
Does a truncate table solve corrupt blocks in a table?
I have found corrupt blocks in rman, located them, they are in 1 table.
And contacted the business, and have permission to drop and recreate the table,
but my question is does truncate table drop storage also solves my problem?
And will it let me to do a full backup without set max corrupt blocks?
To my knowledge does a truncate table moves the high watermark to 0 + 1 extend, but I am unsure how this will effect the corrupt blocks.
Thanks in advance for your advice

Hi,
Yes truncate/drop table fixes the corruption at the database level. You may like to take the backup(if you have index on it) of that table so that you may restore it later if anything goes wrong.
Note: This would not fix any corruption at the disk level (like bad sectors).
Regards
Anurag

ORA-19566: exceeded limit of 0 corrupt blocks

Hi All,
We have been encountering some issues with RMAN backup; it has been erroring out with same errors (max corrupt blocks). As of now, I ran the db verify for affected files and found that indexes are failing. When I tried to find out the indexes from extent views, I was unable to find it. Looks like these blocks are in free space as I found it and also the V$backup corruption view shows the logical corruption.
Waiting for you suggestion....
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for HPUX: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
RMAN LOG:
channel a3: starting piece 1 at 14-DEC-09
RMAN-03009: failure of backup command on a2 channel at 12/14/2009 05:43:42
ORA-19566: exceeded limit of 0 corrupt blocks for file /ub834/oradata/TERP/applsysd142.dbf
continuing other job steps, job failed will not be re-run
channel a2: starting incremental level 0 datafile backupset
channel a2: specifying datafile(s) in backupset
including current control file in backupset
channel a2: starting piece 1 at 14-DEC-09
channel a1: finished piece 1 at 14-DEC-09
piece handle=TERP_1769708180_level0_292_1_1_20091213065437.rmn tag=TAG20091213T065459 comment=API Version 2.0,MMS Version 5.0.0.0
channel a1: backup set complete, elapsed time: 01:14:45
channel a2: finished piece 1 at 14-DEC-09
piece handle=TERP_1769708180_level0_296_1_1_20091213065437.rmn tag=TAG20091213T065459 comment=API Version 2.0,MMS Version 5.0.0.0
channel a2: backup set complete, elapsed time: 00:24:54
RMAN-03009: failure of backup command on a4 channel at 12/14/2009 06:14:33
ORA-19566: exceeded limit of 0 corrupt blocks for file /ub834/oradata/TERP/applsysd143.dbf
continuing other job steps, job failed will not be re-run
released channel: a1
released channel: a2
released channel: a3
released channel: a4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on a3 channel at 12/14/2009 06:41:00
ORA-19566: exceeded limit of 0 corrupt blocks for file /ub806/oradata/TERP/icxd01.dbf
Recovery Manager complete.
Thanks,
Vimlendu
Edited by: Vimlendu on Dec 20, 2009 10:27 AM

dbv file=/ora/oradata/binadb/RAT_TRANS_IDX01.dbf blocksize=8192
The result:
DBVERIFY: Release 10.2.0.3.0 - Production on Thu Nov 20 11:14:01 2003
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE =
/ora/oradata/binadb/RAT_TRANS_IDX01.dbf
Block Checking: DBA = 75520968, Block Type = KTB-managed data block
**** row 80: key out of order
---- end index block validation
Page 23496 failed with check code 6401
DBVERIFY - Verification complete
Total Pages Examined : 34560
Total Pages Processed (Data) : 1
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 31084
Total Pages Failing (Index): 1
Total Pages Processed (Other): 191
Total Pages Empty : 3284
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Seems like I have 1 page failing. I try to run this script:
select segment_type, segment_name, owner
from sys.dba_extents
where file_id = 18 and 23496 between block_id
and block_id + blocks - 1;
No rows returned.
Then, I try to run this script:
Select tablespace_name, file_id, block_id, bytes
from dba_free_space
where file_id = 18
and 23496 between block_id and block_id + blocks - 1
Resulting 1 row.
Seems like I have the possible corrupt block on unused space.
Edited by: Vimlendu on Dec 20, 2009 2:30 PM
Edited by: Vimlendu on Dec 20, 2009 2:41 PM

DB Recovery due to corrupt block in redologfile

Hello.
A block was corrupted in the redo log file # 2 and I don't have backup.
So I tried recovering the database using the RECOVER DATABASE until a specified change #. The database required me to use the RECOVER DATABASE USING BACKUP CONTROLFILE instead. This command asked for a filename of a redo logfile. I entered the filename of redo log#1 since log#2 contained the corrupted block.
The recovery wasn't successful. The error messages stated that the recovery required the sequence #333 but redo log#1 contained the sequence #332. I later found out that redo log#2 contained the sequence #333.
Basically, the scenario is this: according ora-00279, the recovery requires the sequence #333 found in redolog#2 which contains the corrupted block. When i try recovery i get the ora-01194 error plus the ora-01112: media recovery not started
is there still hope in recovering the database?
Thanks in advance

Well i think you can only recover up to scn #332 using log#1.
If your redo members are not multiplexed you have lost some data.
Acr

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

Corrupt blocks in the LOB segment 11.2.0.2

Hello,
at a dbexport we found corrupted blocks in a LOB-Segment. Then we start rman and do a backup validate check logical database, nothing, rman didn't found any corruption. meanwhile we have repaired the LOB-Segment with restore, now all is ok. But we are confused about this situation, why did rman not found the corruption ? we are making backups with rman (with parameter check logical) and we think rman found logical data corruption. should we now make daily an export to dev_null that we found any corruption.It would be very nice if someone had an answer for us.
thanks very much

As far as I know rman validate backup only check for corrupted blocks among database blocks which are used at least once(i.e. used, or free-but at least once used before). For not used blocks RMAN will not report any block corruption.
The alternate approach could be using dbv utility(Database verification utility)

WARNING: Unsed Block Found in Song

I'm now desperate -- the bugginess related to the UNDO command is reaching crisis stage. In an effort to solve the problem, I first cleaned house: consolidated MIDI tracks, deleted empty tracks, emptied the trash, and dbl-clicked on the memory indicator to invoke the Reorganize Memory function. When I did this last step I got the following error message:
=======================
Warning!
Unused Block found in song.
Please save song first.
(Code: $00000001)
=======================
Seeking advice:
a) what's this mean?
b) why has this occured?
c) how can it be prevented in the future?
More importantly...
d) under what conditions will Logic's brain get so addled such that hitting UNDO one time will result in multiple previous edits becoming undone?

Hey iSchwartz,
Just adding to the concensus here:
A) It's a big red flag that your song is on the dark road of corruption. Time to get the tracks transferred to a new session.
B) In my experience it is usually from low event memory and legacy objects in your .lso
C) Rebuilding your Autoload/Templates and keeping your enviro/objects up to date while keeping the song file as small as possible. If I am opening a song from an earlier version of Logic I have an update procedure if I plan on working in it much. Rebuilding it earlier saves time in the long run.
D) It's just general event memory and corruption. Performance differences between the old and new can also be drastic.
.lso files passing through several revs of Logic also makes it easy to set in. Some thing I started doing recently: Some of my big songs I just have a master session and then several categorized subsessions-so I don't have to do crazy editing (keeping the event memory Low and the environment easily portable) to the master session and give Logic more chance for corruption to set in. This isn't necessary for the smaller sessions but some tracks you know are just going to get enough work hours that I take this precaution.
Cheers, J

DBV corrupt block in 10G

When I create one datafile bigger of the one than 2 gb, occurs error of block corrupted in oracle10g, when I execute the DBV
This only occurs with datafiles > 1gb, therefore below of this it does not occur.
OS: Suse enterprise 9 (X86)
2 gb memory

I created for sqlplus and for the Enterprise Manager and it does not give error of creation
here it is the execution of dbv and the message of error.
Page 191883 is influx - most likely media corrupt
Corrupt block relative dba: 0x0142ed8b (file 5, block 191883)
Fractured block found during dbv:
Data in bad block:
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000000
check value in block header: 0x0
block checksum disabled

Corrupt Block Found

Similar Messages

Maybe you are looking for