SYSTEM Tablespace corrupt blocks !!!!!!!!!

Hi,
Oracle version 10gR2 - 10.2.0.1.0
The database which i am running in 10g is having few corrupt data blocks in system data files. I have no backup of full database and neither the database is in archive log mode. I know the situation of my development database has very less chance of getting to open mode.
I have checked in metalink in for any hidden parameters, But my funny questions do u think there is any hidden parameter to get out of this issue. please suggest any metalink doc or any parameter to overcome this issue :-)
Thanks
Edited by: user11981262 on Dec 15, 2011 8:41 AM

I don't know any helping secret parameter for you. As I see this your data is lost.
What you can do is documented in [url https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=BULLETIN&id=28814.1]Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g ID 28814.1 Read carefully and try database recovery (from online logs)... submit your results here.

Similar Messages

Recover database after lossing system tablespace without backup

Hi
My database fail because of hardware failure and then system tablespace corrupted. other tablespaces and control files are OK. Can I recover my database without backup of system tablespace?

hi,
if you have not taken the physical backup (inconsistent or consistent) then you can not recocver it. you need to have some backup up strategy with RMAN or Manual. Do you have hardware (Disk) Mirroring to cover the media failure??
Atleast if you have the logical backups?? then create the database and import it..
Thanks
--Raman.

Block Corruption in SYSTEM Tablespace

Hi,
well it´s just a test database without a backup, but i would like to repair it anyway :-)
Here are the facts:
Errors in file c:\oracle\admin\o10g\bdump\o10g_smon_1404.trc:
ORA-01578: ORACLE data block corrupted (file # 1, block # 50187)
ORA-01110: data file 1: 'C:\ORACLE\ORADATA\O10G\SYSTEM01.DBF'
1. I found the object: It´s a Cluster named SYS.C_TOID_VERSION#
containing a lot of table stuff (type$,parameter$, ...)
i tried to repair it with dbms_repair:
BEGIN SYS.DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => 'SYS',
OBJECT_NAME => 'C_TOID_VERSION#',
OBJECT_TYPE => dbms_repair.cluster_object,
FLAGS => dbms_repair.skip_flag);
END;
No error, but the same block corruption message in the alert.log 1 minute later.
i can select the tables in the cluster.
Has anyboby another trick to repair a cluster?
Thanks
Marco

Hi,
if you have rman backup then this problem become resolved by only one command.
BLOCKRECOVER DATAFILE 1 BLOCK 3 DATAFILE 50187;
otherwise restore system tablespace from backup and recover it.
and one more thing
**Don't fix the block in system tablespace it may create problem if that block contain some useful information of oracle(internal information).
Thanks
Kuljeet Pal Singh

SYSTEM TS Corruption - Zero Blocks

One of our production instances use operating system level COPY as backup method. When we tried to implement rman backups, we came to know there are some zero blocks in system tablespace. after doing a DBV on the datafile noted by rman, we found there are 12 corrupt/zero pages in system03.dbf.
We cannot go to a backup and roll forward, because we dont know since when this system03 is corrupt. The only option that comes to mind is a full export and rebuild of the database. This is an oracle applications db and pretty critical. The size is around 300GB. We cant afford that much downtime on production.
Any ideas ? so far we didnt have any reported issues due to this corruption. The corrupted object in SYS.IDL_UB1$.
++DBV LOG :-++
DBVERIFY: Release 10.2.0.3.0 - Production on Thu Dec 11 11:00:26 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = system03.dbf
Page 191938 is influx - most likely media corrupt
Corrupt block relative dba: 0x00c2edc2 (file 3, block 191938)
Fractured block found during dbv:
Data in bad block:
type: 0 format: 2 rdba: 0x00c2edc2
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000000
check value in block header: 0xea00
computed block checksum: 0x1
Page 191939 is marked corrupt
Corrupt block relative dba: 0x00c2edc3 (file 3, block 191939)
Completely zero block found during dbv:
Page 191940 is marked corrupt
Corrupt block relative dba: 0x00c2edc4 (file 3, block 191940)
Completely zero block found during dbv:
Page 191941 is marked corrupt
Corrupt block relative dba: 0x00c2edc5 (file 3, block 191941)
Completely zero block found during dbv:
Page 191942 is marked corrupt
Corrupt block relative dba: 0x00c2edc6 (file 3, block 191942)
Completely zero block found during dbv:
Page 191943 is marked corrupt
Corrupt block relative dba: 0x00c2edc7 (file 3, block 191943)
Completely zero block found during dbv:
Page 191944 is marked corrupt
Corrupt block relative dba: 0x00c2edc8 (file 3, block 191944)
Completely zero block found during dbv:
Page 191945 is marked corrupt
Corrupt block relative dba: 0x00c2edc9 (file 3, block 191945)
Completely zero block found during dbv:
Page 191946 is marked corrupt
Corrupt block relative dba: 0x00c2edca (file 3, block 191946)
Completely zero block found during dbv:
Page 191947 is marked corrupt
Corrupt block relative dba: 0x00c2edcb (file 3, block 191947)
Completely zero block found during dbv:
Page 191948 is marked corrupt
Corrupt block relative dba: 0x00c2edcc (file 3, block 191948)
Completely zero block found during dbv:
Page 191949 is influx - most likely media corrupt
Corrupt block relative dba: 0x00c2edcd (file 3, block 191949)
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: 0x00000001
check value in block header: 0x0
block checksum disabled
DBVERIFY - Verification complete
Total Pages Examined : 256000
Total Pages Processed (Data) : 128521
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 52973
Total Pages Failing (Index): 0
Total Pages Processed (Other): 493
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 74001
Total Pages Marked Corrupt : 12
Total Pages Influx : 2
Highest block SCN : 1191398275 (1.1191398275)
Edited by: Lakshmi Pavuluri on Dec 11, 2008 11:30 AM

I think Oracle support is playing it safe. With damaged system tablespace without backup, that's logical conclusion.
Did you try run hcheck.sql to get a report?
"hcheck.sql" script to check for known problems in Oracle8i,Oracle9i, Oracle10g and Oracle 11g
Doc ID: Note:136697.1
Do some DML on table SYS.IDL_UB1$ see you get any error.
This metalink doc has some info on fixing damaged database dictionary.
ORA-8103 Diagnostics and Solution
Doc ID: Note:268302.1
The error just mean the block has been zeroed out a common type of corruption.

System tablespace gets corrupted.

Hi,
My system tablespace gets corrupted. My Database is not running in archivelog mode and also i dont have any backup. Is there is any solution to recover corrupted blocks in system tablespace;

had the same few weeks ago at one of our customers
SYSTEM tablespace (SYSTEM01.DBF) got corrupted due to power outage/disk error
no archiving, no backup (database for testing purposes, which they update periodically with data from the production database)
tried recovery (as Rafi suggested above), but it didnt work, it said SYSTEM01.DBF needs further recovery, thus open resetlogs wont work
and it was right, resetlogs didnt work :)
so the options:
1. recovery/restore - not possible
2. Oracle has a private tool called Oracle Data Unloader that can get the data from the datafiles - just a test database, doesnt worth the work/time/money
3. open the database with the allowresetlogs_corruption=TRUE hidden parameter, and try a full export
database could be opened with resetlogs by using this parameter
the reward for this action: several ORA-600s per second, instance crashed in 30-60 seconds
at the end we dropped the database and duplicated the production one

How to identify corrupted block in Particular tablespace?

Hi,
i am getting lot of block corruption error from particular tablesapce datafile. i couldn't able to use DBVerify utility .bcz datafiles not created using .dbf format.
how to idetify corrupted blocks?

Detecting and Repairing Data Block Corruption
http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/repair.htm(9i)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm(10g)
Find more information “Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g” Metalink Note: 28814.1.
http://dbataj.blogspot.com/2008/04/oracle-database-block-corruption.html
http://sysdba.wordpress.com/2006/04/05/how-to-check-for-and-repair-block-corruption-with-rman-in-oracle-9i-and-oracle-10g/

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)

ORA-00704: bootstrap process failure and SYSTEM datafile corrupt

We have an Oracle 10g Express database that is getting the following error on startup.
ORA-00704: bootstrap process failure
It is also showing that the SYSTEM datafile is corrupt. And unfortunately the backups are gone. Is there any way to recover from this without a backup? Maybe some hidden undocumented parameter???
We do have some full database exports from a couple weeks ago so it is not a complete loss but would really like a full recover.

Windows XP
We have tried allowresetlogs_corruption and allowread_only_corruption and no luck so far.
ALTER DATABASE MOUNT
Thu Aug 09 08:49:28 2012
Setting recovery target incarnation to 2
Thu Aug 09 08:49:28 2012
Successful mount of redo thread 1, with mount id 2672004948
Thu Aug 09 08:49:28 2012
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Thu Aug 09 08:49:50 2012
alter database open upgrade
Thu Aug 09 08:49:50 2012
Beginning crash recovery of 1 threads
Thu Aug 09 08:49:50 2012
Started redo scan
Thu Aug 09 08:49:50 2012
Completed redo scan
0 redo blocks read, 0 data blocks need recovery
Thu Aug 09 08:49:50 2012
Started redo application at
Thread 1: logseq 84298, block 3, scn 10745981851
Thu Aug 09 08:49:50 2012
Recovery of Online Redo Log: Thread 1 Group 4 Seq 84298 Reading mem 0
Mem# 0 errs 0: D:\DATA\ORACLE\ORADATA\XE\REDO04A.LOG
Mem# 1 errs 0: D:\DATA\ORACLE\ORADATA\XE\REDO04B.LOG
Thu Aug 09 08:49:50 2012
Completed redo application
Thu Aug 09 08:49:50 2012
Completed crash recovery at
Thread 1: logseq 84298, block 3, scn 10746001852
0 data blocks read, 0 data blocks written, 0 redo blocks read
Thu Aug 09 08:49:51 2012
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=18, OS id=2524
Thu Aug 09 08:49:51 2012
ARC0: Archival started
ARC1 started with pid=20, OS id=2956
Thu Aug 09 08:49:52 2012
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Thread 1 advanced to log sequence 84299
Thread 1 opened at log sequence 84299
Current log# 2 seq# 84299 mem# 0: D:\DATA\ORACLE\ORADATA\XE\REDO02A.LOG
Current log# 2 seq# 84299 mem# 1: D:\DATA\ORACLE\ORADATA\XE\REDO02B.LOG
Successful open of redo thread 1
Thu Aug 09 08:49:52 2012
ARC1: STARTING ARCH PROCESSES
Thu Aug 09 08:49:52 2012
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Thu Aug 09 08:49:52 2012
SMON: enabling cache recovery
Thu Aug 09 08:49:52 2012
ARC2: Archival started
Thu Aug 09 08:49:52 2012
ARC1: STARTING ARCH PROCESSES COMPLETE
ARC1: Becoming the heartbeat ARCH
ARC2 started with pid=21, OS id=3916
Thu Aug 09 08:49:54 2012
Successfully onlined Undo Tablespace 1.
Thu Aug 09 08:49:54 2012
SMON: enabling tx recovery
Thu Aug 09 08:49:54 2012
Database Characterset is WE8MSWIN1252
Thu Aug 09 08:49:56 2012
Hex dump of (file 1, block 39) in trace file c:\oraclexe\app\oracle\admin\xe\bdump\xe_smon_876.trc
Corrupt block relative dba: 0x00400027 (file 1, block 39)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x00400027
last change scn: 0x0002.7fee0b69 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x0b690601
check value in block header: 0x8f6c
computed block checksum: 0x1000
Reread of rdba: 0x00400027 (file 1, block 39) found same corrupted data
Thu Aug 09 08:49:56 2012
Stopping background process MMNL
Thu Aug 09 08:49:56 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_smon_876.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 39)
ORA-01110: data file 1: 'D:\DATA\ORACLE\ORADATA\XE\SYSTEM.DBF'
Thu Aug 09 08:49:57 2012
Stopping background process MMON
Starting background process MMON
Starting background process MMNL
MMON started with pid=11, OS id=1012
Thu Aug 09 08:49:58 2012
ALTER SYSTEM enable restricted session;
MMNL started with pid=12, OS id=3584
Thu Aug 09 08:49:58 2012
ALTER SYSTEM SET systemtrig_enabled=FALSE SCOPE=MEMORY;
Thu Aug 09 08:49:58 2012
ALTER SYSTEM SET aq_tm_processes=0 SCOPE=MEMORY;
Thu Aug 09 08:49:58 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\udump\xe_ora_324.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 39)
ORA-01110: data file 1: 'D:\DATA\ORACLE\ORADATA\XE\SYSTEM.DBF'
Thu Aug 09 08:49:58 2012
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Thu Aug 09 08:49:59 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_pmon_3120.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:49:59 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_psp0_3444.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:49:59 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_mman_2592.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:49:59 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_dbw0_932.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:49:59 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_ckpt_1156.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:50:00 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_lgwr_1508.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:50:00 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_reco_2700.trc:
ORA-00604: error occurred at recursive SQL level
Thu Aug 09 08:50:00 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\bdump\xe_smon_876.trc:
ORA-00604: error occurred at recursive SQL level

FullOffline Backup - ORA-19566: exceeded limit of 0 corrupt blocks for file

Dear SAP gurus,
I am getting an error from the DBA Planning Calendar every time the job for "Full Offline backup" is run. And it is always as you can see from the log on the same file "oracle/SHD/sapdata4/sr3_16/sr3.data16".
The oracle error is the following:
ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/SHD/sapdata4/sr3_16/sr3.data16
I found the SAP Note 969192 - RMAN Backup of SYSTEM tablespace terminates with ORA-19566
but it does no apply because this is for the tablespace SYSTEM and not PSAPSR3.
Please find below the log:
BR0051I BRBACKUP 7.00 (46)
BR0055I Start of database backup: begomwsv.ffd 2011-08-17 10.01.37
BR0484I BRBACKUP log file: /oracle/SHD/sapbackup/begomwsv.ffd
BR0477I Oracle pfile /oracle/SHD/102_64/dbs/initSHD.ora created from spfile /oracle/SHD/102_64/dbs/spfileSHD.ora
BR0101I Parameters
Name                           Value
oracle_sid                     SHD
oracle_home                    /oracle/SHD/102_64
oracle_profile                 /oracle/SHD/102_64/dbs/initSHD.ora
sapdata_home                   /oracle/SHD
sap_profile                    /oracle/SHD/102_64/dbs/initSHD.sap
backup_mode                    FULL
backup_type                    offline_force
backup_dev_type                disk
backup_root_dir                /mnt/backup/oracle/SHD
compress                       no
disk_copy_cmd                  rman
cpio_disk_flags                -pdcu
exec_parallel                  0
rman_compress                  no
system_info                    shdadm/orashd eccdev01 Linux 2.6.16.60-0.87.1-smp #1 SMP Wed May 11 11:48:12 UTC 2011 x86_64
oracle_info                    SHD 10.2.0.4.0 8192 17654 1114483454 eccdev01 UTF8 UTF8
sap_info                       700 SAPSR3 0002LK0003SHD0011Y01548735220015Maintenance_ORA
make_info                      linuxx86_64 OCI_102 Jan 29 2010
command_line                   brbackup -u / -jid FLLOF20110817100136 -c force -t offline_force -m full -p initSHD.sap
BR0116I ARCHIVE LOG LIST before backup for database instance SHD
Parameter                      Value
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            /oracle/SHD/oraarch/SHDarch
Archive format                 %t_%s_%r.dbf
Oldest online log sequence     17651
Next log sequence to archive   17654
Current log sequence           17654            SCN: 1114483454
Database block size            8192             Thread: 1
Current system change number   1114501246       ResetId: 664011854
BR0118I Tablespaces and data files
BR0202I Saving /oracle/SHD/sapdata3/sr3_15/sr3.data15
BR0203I to /mnt/backup/oracle/SHD/begomwsv/sr3.data15 ...
#FILE..... /oracle/SHD/sapdata3/sr3_15/sr3.data15
#SAVED.... /mnt/backup/oracle/SHD/begomwsv/sr3.data15 #1/15
BR0280I BRBACKUP time stamp: 2011-08-17 10.28.42
BR0063I 15 of 48 files processed - 44100.117 of 121180.346 MB done
BR0204I Percentage done: 36.39%, estimated end time: 11:15
BR0001I ******************________________________________
BR0202I Saving /oracle/SHD/sapdata4/sr3_16/sr3.data16
BR0203I to /mnt/backup/oracle/SHD/begomwsv/sr3.data16 ...
BR0278E Command output of 'SHELL=/bin/sh /oracle/SHD/102_64/bin/rman nocatalog':
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Aug 17 10:28:42 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN>
RMAN> connect target *
connected to target database: SHD (DBID=1683093070, not open)
using target database control file instead of recovery catalog
RMAN> *end-of-file*
RMAN>
host command complete
RMAN> 2> 3> 4> 5> 6>
allocated channel: dsk
channel dsk: sid=223 devtype=DISK
executing command: SET NOCFAU
Starting backup at 17-AUG-11
channel dsk: starting datafile copy
input datafile fno=00019 name=/oracle/SHD/sapdata4/sr3_16/sr3.data16
released channel: dsk
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on dsk channel at 08/17/2011 10:30:30
ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/SHD/sapdata4/sr3_16/sr3.data16
RMAN>
Recovery Manager complete.
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.30
BR0279E Return code from 'SHELL=/bin/sh /oracle/SHD/102_64/bin/rman nocatalog': 1
BR0536E RMAN call for database instance SHD failed
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.30
BR0506E Full database backup (level 0) using RMAN failed
BR0222E Copying /oracle/SHD/sapdata4/sr3_16/sr3.data16 to/from /mnt/backup/oracle/SHD/begomwsv failed due to previous errors
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.34
BR0307I Shutting down database instance SHD ...
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.34
BR0308I Shutdown of database instance SHD successful
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.34
BR0304I Starting and opening database instance SHD ...
BR0280I BRBACKUP time stamp: 2011-08-17 10.30.47
BR0305I Start and open of database instance SHD successful
Do you guys have any idea on how to solve this issue??
Thanks in advance, Marc

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

System file corrupt

Hi all,
we are having 3 db in windows box oracle 9i version daily we scheduled a backup its for dev and uat database. but when i checked the same of back it shows that 2 are backed up one is not backed up due to that ora-01115 error.
then wi checked the in site they said that due to malfunction of harddisk problem.and bad sectors. so in the meantime what i did is back up controlfile and then shutdown the database and did a full consistent copy almost completing stage the system file is not copyed due to that data cyclic redundancy error. i tried twice no use same result.
is there anyway to recover that system file. or noway?
if it is not ok then i have to clone the test db and give it to dev.
is there anyway to bring that system with the help of controlfile...
pls suggest me..

If you cannot make a full export without getting an error you can still try to export all the user data and generating all stored code: packages, procedures, functions, sequences, etc ....
Is the CRC error being reported by the OS or Oracle? Because it is the system tablespace I am not sure if it can be used but have you looked into using the dbms_repair package to find, mark, and skip the corrupt blocks?
I have fixed corruption in the rdbms base tables before by identifying the corrupted object and then dropping and recreating the object. If this method will work for you will depend on what is corrupt.
If you have support opening a SR and getting support guidence on how to save your data is probably worthwhile.
Otherwise you need to restore your last good backup. But I suggest you verify the status of the backup before using it. It may in fact be bad so you might want to try alternate approaches to savalaging the data and rebuilding the database
HTH -- Mark D Powell --

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

RMAN duplicate target database for standby from active fails to create newname for system tablespace/datafile

When executing 'duplicate target database for standby from active' the system tablespace/datafile (datafile 1) is not cloned. All other datafiles clone successfully. The RMAN process aborts with the following errors while attempting to clone the system tablespace/datafile.
ORA-19558: error de-allocating device
ORA-19557: device error, device type: DISK, device name:
ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
ORA-03135: connection lost contact
Here are the details:
Primary is 11.2.0.2 RAC database on an Exadata platform
Standby is 11.2.0.2 Single Instance database (same patch level as primary) on a Red Hat Linux box
This is an ASM to ASM duplication.
This is not unique to this database. We tried another database and go the same behavior - all datafiles clone successfully with the exception of the system tablespace/datafile.
We have traced the RMAN execution and it seems to fail when it is trying to assign a NEWNAME to the system tablespace/datafile.
We even issued an explicit SET NEWNAME command but RMAN ignored it.
We also shutdown the primary and started is up in mount mode thinking that something had ahold of the System Tablespace/datafile.
We also opened up the network firewall to allow permit any,any traffic.
We increased the max_server_processes
and added TCP.NODELAY=yes to the sqlnet.ora file.
There seems to be some artifact present in our Primary System tablespace/data file that is preventing it form being cloned.
checked all alert files grid, asm, and dbhome - no abnormal messages.
We are in the process of restoring the database from a backup but we would prefer to get this working using the 'Active Database' methodology

I successfully created the standby database using RMAN backup and recovery.
I started the managed recovery. Archive logs are being sent from the primary to the standby ( I can see them in ASM), but the standby is not applying them.
I get the following messages in the standby alert log...
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:19:58 2013
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Tue Nov 26 16:20:01 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:11 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:22 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:32 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
I don't see any MRP processes:
select process,
status,
    thread#,
    sequence#,
   block#,
blocks
7     from v$managed_standby;
PROCESS   STATUS          THREAD# SEQUENCE#     BLOCK#     BLOCKS
ARCH      CLOSING               2     154363          1        132
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
RFS       IDLE                  0          0          0          0
RFS       IDLE                  1     145418        121          1
RFS       IDLE                  0          0          0          0
PROCESS   STATUS          THREAD# SEQUENCE#     BLOCK#     BLOCKS
RFS       IDLE                  0          0          0          0
12 rows selected.
SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
   THREAD# SEQUENCE# APPLIED
         2     154356 NO
         2     154357 NO
         1     145411 NO
         2     154358 NO
         2     154360 NO
         2     154361 NO
         1     145414 NO
         1     145415 NO
         2     154362 NO
         2     154363 NO
         1     145416 NO
11 rows selected.
I do have the archive logs that cover sequences 154158-154257
Crosschecked 38 objects
Crosschecked 62 objects
Finished implicit crosscheck backup at 26-NOV-13
Starting implicit crosscheck copy at 26-NOV-13
using channel ORA_DISK_1
using channel ORA_DISK_2
Crosschecked 2 objects
archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154377.344.832521989 RECID=29 STAMP=832521990
validation succeeded for archived log
archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154378.346.832521991 RECID=31 STAMP=832521993
Crosschecked 31 objects

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

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

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

SYSTEM Tablespace corrupt blocks !!!!!!!!!

Similar Messages

Maybe you are looking for