Question on fixing a corrupt block with dbms_repair?

I am not using RMAN.
Can I fix a corrupt block with dbms_repair.
I know the table, file, block id.
FILE_ID = 3
Block ID = 1555205
Table: ARFCSDATA

1) This is what I did so far
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'PSAPD3P');
END;
SET SERVEROUTPUT ON
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'SAPD3P',
OBJECT_NAME => 'ARFCSDATA',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
CORRUPT_COUNT => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
It is still running after an hour.
2) What does FIX_CORRUPT_BLOCKS actually do?

Similar Messages

Help Fix 26473 Corrupt blocks in system09.dbf

How to Format Corrupted Block Not Part of Any Segment [ID 336133.1]
I'm following the above doc to fix 26K corrupt blocks in system09.dbf
in Step 7 of the Doc it says:
+" First find the *extent size* by querying dba_free_space "+
+65536 = If its 64 K+
+1048576 = 1M+
I'm getting 891559936 with the following query:
SQL> Select bytes from dba_free_space where file_id= 352 and 192128 between block_id and block_id + blocks -1;
BYTES
891559936
What will be my extent size?
I'm lost on how to proceed with the following steps:
BEGIN
for i in 1..1000000 loop
EXECUTE IMMEDIATE 'alter table apps.s allocate extent (DATAFILE '||'''/oracle/KPSO/db/apps_st/data/system09.dbf''' ||'SIZE 64K) ';
end loop;
end ;
+/+
Note you need to change accordingly the size (1M ,64K or 128k) and the value of for loop
can be changed as per requirement.
Thanks.
-Joey-

>
currently doing another round of steps 5-9 to see if it will wipe out all the corrupt blocks.Just want to give an update:
Datafile was completely free of corruption after 2 more passes ..
$ dbv file=/oracle/KPSO/db/apps_st/data/system09.dbf blocksize=8192
DBVERIFY: Release 11.1.0.7.0 - Production on Thu Mar 22 05:08:56 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle/KPSO/db/apps_st/data/system09.dbf
DBVERIFY - Verification complete
Total Pages Examined : 192128
Total Pages Processed (Data) : 160979
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 26455
Total Pages Failing (Index): 0
Total Pages Processed (Other): 2124
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2570
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 3757005752 (1388.3757005752)

Corrupt blocks with RH6.2 and 8.1.7

Hi
We have following problem: while running Oracle 8.1.7 on a Compqa DL580 with Smartarray controller 5304 on RedHat 6.2 system we encounter corrupt data blocks after a certain time.
We can see corrupt data blocks e.g after reboot, but also during normal operation. This happens again and again after some weeks after we had reinstalled the database. Oracle support lead us to install RH6.2 (after having the problems on 7.1), but it crashed again ...
Any tips?
System details:
kernel 2.2.19-6.2.7
glibc 2.1.3-22
mount 2.10r-0.6.x
fs.file-max=8192 (in /etc/sysctl.conf)
Dietmar

Hi
I work with linux RH (6.2, 7.0, 7.1) and 8i (8.1.5 since 8.1.7.0.1) and 9i and I only two times I find just a block corruption warning, but database keeps working fine.
This data corruption affects only Oracle? You can turn extra CRC check into oracle data blocks (of course it slows all process ;)
Maybe the linux RAID drivers have some bug, a simple solution is to install one datafile of the tablespace in a nother disk (IDE for example) and check if this datafile is corrupted too.
Anyway just make a simple script (using dd or random) or C, Perl.. program that writes/reads intensively (one week ir more) "1" on a big file (at least 1G) and check if you get some error. Oracle just calls system I/O, so if one crashes, other must too.
A10!

Hello every body .. my ipad blocked with icloud and i dont remember the email or even birthday i've wrote I just remember the security question ... what can i do in this case to restor my email working ?? thx

hello every body .. my ipad blocked with icloud and i dont remember the email or even birthday i've wrote I just remember the security questions ... what can i do in this case to restor my email back ?? thx

Do you mean that the iPad is on the activation screen ? If it is then does it not show the first letter of your email address and the provider e.g. similar to :
If that is what you are seeing then you don't remember any email account that you had starting with that letter with that provider ? If not then do you know if you have any of the account's downloads in your computer's iTunes library : Recovering a forgotten iTunes Store account name ?
Or see if you can find it via http://appleid.apple.com : Apple ID: How to find your Apple ID
If you cant remember or find your id then you won't be able to use your iPad

Corrupt Block Diagram With Infinite Wires

Hi,
Has anyone every seen a corrupt Block Diagram as shown in the pic? Almost all my wires have stretched to infinity!
I used "Clean up wire" on these wires, but that did nothing.
Ironically, the VI runs -- but I can't develop further with the BD in this state.
Any ideas, please
THANKS PEEPS!
Attachments:
Screenshot 2015-03-26 18.16.56.png ‏78 KB

There is a maximum size that the BD or FP can be. If you are getting close to that size and the cleanup tries to make it bigger odd things can happen. This might explain why nothing happens when you try to clean it up.
http://digital.ni.com/public.nsf/allkb/62D66358BBF8A87186256FC50077FA17
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Blocks corrupted always with the same checksum 0x400

Hello Oracle gurus,
Need your help with finding source of block corruption errors that we observe repeatedly on one system. See the error below.
Location of the corrupted block is always different, but the computed checksum is always 0x400. Only one block gets corrupted after a couple of days of stress testing. We completely re-install OS (RHEL4) and re-create DB. Still the same error with the same checksome appears, but in a different location. This happened 3 times already.
Does anybody know what 0x400 corresponds to? Is it all zeroes?
In my understanding, if the corruption was caused by a drive error, such as a single bit flip or several sectors corruption, then the computed checksum would be always different.
Is this correct? Any other ideas what can be the reason for such corruption?
Thanks a lot.
Hex dump of (file 9, block 357024) in trace file /u01/app/oracle/admin/pndb/udump/pndb_ora_13828.trc
Corrupt block relative dba: 0x024572a0 (file 9, block 357024)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x024572a0
last change scn: 0x0000.00b31c70 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x1c700601
check value in block header: 0xfcd0
computed block checksum: 0x400
Reread of rdba: 0x024572a0 (file 9, block 357024) found same corrupted data
Fri Apr 27 04:09:32 2007
Corrupt Block Found
TSN = 9, TSNAME = PN_TABL
RFN = 9, BLK = 357024, RDBA = 38105760
OBJN = 40738, OBJD = 40738, OBJECT = PN_EVENT_SESSION_1, SUBOBJECT =
SEGMENT OWNER = PNADMIN, SEGMENT TYPE = Table Segment

Well I understand that, however Oracle is running on higher level (application level).
It's hard to trace a potential lower level ( hardware level) problem in high level application.
The least thing you can try is find out which object this corrupted block belong if it's always same object or some pattarn you can tell then there might have something to do with Oracle.
If it's totally random then it's hard to say.
select segment_name,segment_type,owner
from sys.dba_extents
where file_id=(9)
and (357024) between block_id and block_id + blocks -1;

Rman backup with corrupted block

Hello,
Firstly - I have problem on non-production database 11.2.0.1.0, so I am not deeply worried about data. But I need to understand what happened with database backups and how to prevent such things in future.
So - I have EM scheduled weekly full backup and daily incremental backups. Later there was problem with hardware and some corrupted blocks in database were found. The weekly backup ran without error and obsolete backups were deleted. Now it is not possible to "recover corruption list" because no backup without corruption exists (RMAN-06023: no backup or copy of datafile 6 found to restore). I am not worried about the lost data, but I need to find out how come the backup contains corrupted block.
I have checked the data file using dbv utility
DBVERIFY - Verification starting : FILE = /opt/oracle/oradata/orcl/users03.dbf
DBV-00200: Block, DBA 27525766, already marked corrupt
csc(0x0001.7b01729f) higher than block scn(0x0000.00000000)
Page 2359942 failed with check code 6054
DBVERIFY - Verification complete
Total Pages Examined         : 3840000
Total Pages Processed (Data) : 453896
Total Pages Failing   (Data) : 1
Total Pages Processed (Index): 2959104
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 424025
Total Pages Processed (Seg) : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 2975
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 2156227446 (1.2156227446)As you can see the datafile 6 - user03.dbf has errors. Also backups now contain errors.
1) So how is it possible that the EM scheduled backup ran without problems and the backup now contains corrupted blocks. How to prevent this in future ? I know there is setting MAXCORRUPT. How can I check its current value ? How can I configure it using EM scheduled backups ?
2) Secondly, meanwhile I studied the RMAN commands. So I have suspended EM backup jobs, and executed follwing command. And backup ran without error again. How is this possible, if data file users06.dbf has corrupted block ?
Thanks !
RMAN> run {
set MAXCORRUPT for datafile 6 to 0;
backup as compressed backupset datafile 6;
2> 3> 4>
executing command: SET MAX CORRUPT
Starting backup at 07-NOV-12
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: starting piece 1 at 07-NOV-12
channel ORA_DISK_1: finished piece 1 at 07-NOV-12
piece handle=/opt/oraBackup/rman/nrnpo0sg_1_1 tag=TAG20121107T200120 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 01:13:05
Finished backup at 07-NOV-12
Starting Control File and SPFILE Autobackup at 07-NOV-12
piece handle=/opt/oraBackup/rman/c-1253245572-20121107-03 comment=NONE
Finished Control File and SPFILE Autobackup at 07-NOV-12

I have updated database to 11.2.0.3
However, the problem still persists. rman backup went ok on broken file
oracle@orcl-cluster:~> sqlplus
SQL*Plus: Release 11.2.0.3.0 Production on Tue Nov 20 09:24:11 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Enter user-name: system
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
         6    2359942          1                  0 FRACTURED
        25    1855622          1                  0 FRACTURED
oracle@orcl-cluster:~> rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Nov 20 08:04:57 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1253245572)
RMAN> backup as compressed backupset datafile 6;
Starting backup at 20-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1596 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1568 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=2357 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=2341 device type=DISK
allocated channel: ORA_DISK_5
channel ORA_DISK_5: SID=86 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: starting piece 1 at 20-NOV-12
channel ORA_DISK_1: finished piece 1 at 20-NOV-12
piece handle=/opt/oraBackup/rman/2rnqovpp_1_1 tag=TAG20121120T080513 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 01:10:35
Finished backup at 20-NOV-12
Starting Control File and SPFILE Autobackup at 20-NOV-12
piece handle=/opt/oraBackup/rman/c-1253245572-20121120-00 comment=NONE
Finished Control File and SPFILE Autobackup at 20-NOV-12
RMAN> backup validate datafile 6;
Starting backup at 20-NOV-12
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/opt/oracle/oradata/orcl/users03.dbf
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:05
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
6    OK     1              2975         3840000         6489027926
File Name: /opt/oracle/oradata/orcl/users03.dbf
Block Type Blocks Failing Blocks Processed
Data       0              453912
Index      0              2959091
Other      0              424022
Finished backup at 20-NOV-12Edited by: kamilp on Nov 20, 2012 12:23 AM

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)

Alter index ... rebuild was failing - getting corrupt blocks

Database: 9.2.0.5
OS: HPUX-ia64
Hello,
i rebuilded a index, announced from UpdatStats in DB13, and get a ORA-01114: IO error writing block to file 2045 (block # 319154) and
ORA-27072: skgfdisp: I/O error in my sqlplus session.
-> i do a alter index SAPR3."xxx~0" rebuild online parallel 4 nologging;
-> System was up and running
After that, the DBVerify marked some blocks corrupt, here one example:
BR0398E DBVERIFY detected corrupted blocks in /oracle/XXX/sapdata22/btabi_95/btabi.data95
We checked all corrupted blocks - all in free space.
So we fixed that with creating a table with next extend size from the corrupted blocksize.
I think we had not enough space in the tablespace where the index is, okay ... and what we also found, the PSAPTEMP datafiles was created as SPARSE files ...!!
-> PSAPTEMP-Datafile: 10GB in the System - 2,5GB maximum on OS-Level, no more space.
But my question is why i am getting corrupt blocks when a "alter index ... rebuild ..." is failing ?!?!
Thank you for your support.
Regards,
Markus
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:59 PM

Thany you for the answer.
I cant find any "cor" entries in the last DBVeriy log.
I think (hope) we dont' have anymore corrupted blocks in the system.
We get a response from SAP to update to 9.2.0.8.
My customer wanna do a update to oracle 10 in march/april 2009, so he send me the question if we need a update to 9.2.0.8 ASAP or can we wait for the update to oralce10.
But the important question from my customer and me is, why we get corrupt blocks after failing the alter index rebuild?
Regards,
Markus

Flashing question mark on mac book pro,with grey screen when turned on?

flashing question mark on mac book pro,with grey screen when turned on?

Press the power button down to force a emergency hardware shutdown and hold the option/alt key down and reboot
If you see your OS X boot partition, then click it and the arrow, head to System Preferences > Startup Disk and reset it. Done.
Folder with question mark issue
If that doesn't it, then do a #2 PRAM reset and try the above again.
..Step by Step to fix your Mac
If no OS X boot volume appears in Startup Manager, then OS X is corrupted.
Try more of the Steps above (like 1-8) then if that doesn't work.
Create a data recovery/undelete external boot drive
Once you got your data off, erase and reinstall OS X onto the MacintoshHD partition and then restore from TimeMachine or bootable clone if you have it. or build new and return users files from the data recovery drive.
Most commonly used backup methods
If the drive doesn't appear in Disk Utility it might be dead or there are further complications let us know for further assistance.
Install/upgrade RAM or storage drive in Mac's
My computer is not working, is my personal data lost?
https://discussions.apple.com/community/notebooks/macbook_pro?view=documents#/?p er_page=50

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

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

Skipping Corrupt Block

Hi Gurus,
My alert log was showing a block corrupt and i repaired it with dbms utility. After this oracle starts generating a trace file in udump folder every minute which shows follwing error.
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
*** 2010-04-30 19:52:51.203
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
I don't so many trace files to be gerated . Can i do something .
Please help me.

Vivek Agarwal wrote:
Hi Gurus,
My alert log was showing a block corrupt and i repaired it with dbms utility. After this oracle starts generating a trace file in udump folder every minute which shows follwing error.
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
*** 2010-04-30 19:52:51.203
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
table scan: segment: file# 19 block# 67
skipping corrupt block file# 19 block# 79161
I don't so many trace files to be gerated . Can i do something .
Please help me.Dear Vivek. If you have used DBMS_REPAIR package, it means that you've marked those blocks corrupted and ORacle will bypass those blocks in I/O
Why you haven't used RMAN Block Media Recovery? You can watch my video tutorial on this: http://kamranagayev.wordpress.com/2010/03/18/rman-video-tutorial-series-performing-block-media-recovery-with-rman/
(And please don't tell me that you haven't taken RMAN backup if it's not a production database)
It's just a informatino written to the trace files that Oracle bypasses those data blocks
Read the following article :
http://www.askthegerman.com/archives/107
My Oracle Video Tutorials - http://kamranagayev.wordpress.com/oracle-video-tutorials/

Corrupt blocks ???

During backup it appeared this error, what it can be wrong?
RMAN> RUN{
2> SHUTDOWN IMMEDIATE
3> STARTUP MOUNT
4> ALLOCATE CHANNEL disk1 TYPE DISK FORMAT 'D:\ORACLE - BKP\DF_%d_%s_%t_%U.DBF';
5> CONFIGURE CONTROLFILE AUTOBACKUP ON;
6> BACKUP DATABASE PLUS ARCHIVELOG TAG 'BACKUP FULL';
7> ALTER DATABASE OPEN;
8> }
To use the archive of control of the data base of destination in time of the catsslogo of recovery
Database closed
Database dismounted
Closing of Oracle instance
hardwired to the data base of destination (not initiated)
initiated Oracle instance
Database mounted
Total Global Area of the System 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
Channel Allocate: disk1
Channel disk1: sid=9 devtype=DISK
parameters of old configuration RMAN :
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new parameters of configuration RMAN :
CONFIGURE CONTROLFILE AUTOBACKUP ON;
The new parameters of configuration RMAN had been stored successfully
Initiating backup in 04/04/06
Specification backup in 04/04/06 does not correspond to none log of filling in the
Finished catalogue of recovery
Initiating backup in 04/04/06
channel disk1: Initiating joint of backups of the archive of data full
channel disk1: Specifying files of data in the set of backups
fno=00001 name=C:\ORACLE\ORADATA\ESTUDO\SYSTEM01.DBF of the archive of entrance data
fno=00002 name=C:\ORACLE\ORADATA\ESTUDO\UNDOTBS01.DBF of the archive of entrance data
fno=00007 name=C:\ORACLE\ORADATA\ESTUDO\XDB01.DBF of the archive of entrance data
fno=00004 name=C:\ORACLE\ORADATA\ESTUDO\INDX01.DBF of the archive of entrance data
fno=00006 name=C:\ORACLE\ORADATA\ESTUDO\USERS01.DBF of the archive of entrance data
fno=00003 name=C:\ORACLE\ORADATA\ESTUDO\DRSYS01.DBF of the archive of entrance data
fno=00005 name=C:\ORACLE\ORADATA\ESTUDO\TOOLS01.DBF of the archive of entrance data
channel disk1: initiating component 1 in 04/04/06
channel set free: disk1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 04/04/2006 13:32:36
ORA-19566: exceeded the limit of corrupt blocks 0 for archive C:\ORACLE\ORADATA\ESTUDO\INDX01.DBF

Alex , This error reports that you have block corruption in your database , and rman can't backup the corrupt blocks , You can use the rman for backup with the below workaround , but should resolve this corruption, as the file name suggests that this is an index file , so you should be able to get rid of that corrupt block easily.
To tell RMAN to permit corrupt blocks to be backed up, you must use the
SET MAXCORRUPT command (note that this goes inside the RUN command):
SET MAXCORRUPT FOR DATAFILE 'C:\ORACLE\ORADATA\ESTUDO\INDX01.DBF' TO n;
where 'n' is the number of corrupt blocks which will be allowed in the backup.

How do I fix a corrupt domain?

Hi there,
Came across this last night and, whilst not the end of the world, it's inconvenient.
I just bought a 13" MBP running SL, and am wanting to use it to update my iWeb blog instead of the iMac G5 (leopard). I copied the "domain" file from the iMac to a USB and transferred it to the corresponding folder on the MBP. Opened iWeb - hey presto, the files were all there and looking exactly as I expected.
I created a new entry, attempted to publish, and got the dreaded "Publish error: An unknown error occurred" pop-up.
Searched the interwebz for a solution, and found one to determine if the problem was with the transferred domain file - moved the domain file on the MBP to a new folder, deleted the User/Library/Preferences/com.apple.iweb.plist file, restarted, opened iWeb, created a new site and published to a local folder etc etc). A-OK, therefore problem seems to be with the transferred domain file being corrupt
My question is - How can I fix this corrupted domain file so I can use the MBP for iWeb'ing?

Chris Wever wrote:
I tried to post a new entry on my blog (on the original Mac) and still got the publishing error. Shall I admit defeat yet?
Chris ~ Not yet. Since problems with iWeb's blog are a recurring theme on these forums, it might be useful to see whether removing the Blog page on your MBP enables you to successfully publish the rest of your site...
First make a backup of your Domain file:
_Backing up your Domain file_
...then open iWeb and delete the Blog page. Then republish your website by choosing +Publish Entire Site+ from the File menu.
NOTE: If it successfully publishes, you will have determined that the problem is indeed in the Blog page. But having removed that page from your site, you may not be able to restore ANY of your blog by restoring from your backup and republishing — because you'll probably get the error again on both Macs.
By the way, for a success story using a non-iWeb blog hosted on WordPress, see this old thread:
_To blog or not to blog_

Question on fixing a corrupt block with dbms_repair?

Similar Messages

Maybe you are looking for