V$DATABASE_BLOCK_CORRUPTION and MAXCORRUPT
Hi,
I am a little confused,
from Oracle 9i doc, when using the backup command, Oracle will populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges.
is it necessary to set MAXCORRUPT, to allow oracle populating the V$DATABASE_BLOCK_CORRUPTION view ?
the default limit for MAXCORRUPT is zero, and if I need to change it I would need to set MAXCORRUPT for each datafile.
Thanks
The documentation seems to contradict this:
RMAN Reference
If the sum of physical and logical corruptions detected for a file remain below
its MAXCORRUPT setting, then the RMAN command completes and Oracle
populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges. If
MAXCORRUPT is exceeded, then the command terminates without populating
the views.
Recovery Manager Users Guide
Provided the sum of physical and logical corruptions for a file remains below its
MAXCORRUPT setting, the RMAN command completes and Oracle populates
V$BACKUP_CORRUPTION and V$COPY_CORRUPTION with corrupt block ranges. If
MAXCORRUPT is exceeded, the command terminates without populating the views.This would lead me to believe that MAXCORRUPT must be greater than 0 and the number of corruptions does not exceed the limit. I have not tested this so I can't confirm this.
Similar Messages
-
V$DATABASE_BLOCK_CORRUPTION vs V$BACKUP_CORRUPTION
What is difference between V$DATABASE_BLOCK_CORRUPTION AND V$BACKUP_CORRUPTION?
both are same?During a RMAN backup or RMAN 'backup validate' every block currently used or previously used is read into memory then written to another portion of memory. During this memory to memory write the block is checked for corruption. Therefore RMAN's BACKUP command with the VALIDATE and CHECK LOGICAL clauses allow a Database Adminstrator to quickly check for both physical and logical corruption.
The view gets populated when u do RMAN backup .While backing up the RMAN checks the blocks it backs up and populates these views (v$backup_corruption,v$copy_corruption,v$database_block_corruption. it's not abour "after the last backup" but better to say "during the last RMAN back up.
you can search the metalink for more precise information
See Note 283053.1
ref:-http://www.dbasupport.com/forums/archive/index.php/t-55234.html -
Backup Mode and Error Checking
If I use RMAN why would I want to set the database to backup mode? Is there a way to monitor if RMAN fails or has errors? Can RMAN do compression?
RMAN does not require the database to be in "backup mode". That's one of the benefits of RMAN.
RMAN offers a LOG option that can be used to log RMAN's actions during it's operations. In addition to this log, several views exist that maintain corruption information (V$BACKUP_CORRUPTION, V$DATABASE_BLOCK_CORRUPTION and V$COPY_CORRUPTION). If you are using a recovery catalog, these views correspond to RC_BACKUP_CORRUPTION, RC_DATABASE_BLOCK_CORRUPTION and RC_COPY_CORRUPTION.
10g has RC_RMAN_STATUS & V$RMAN_STATUS and some additional views if you are using RMAN with OEM. -
Oracle 10g corruption type 'unknown'
I don't see unknown listed in the oracle docs as a corruption type.
10.2.0.3
DB in archivelog mode with weekly full backups
We only keep 1 backup. No tape backups (no space. no budget for tape. Its a development environment. )
All DBs are run from vmware. Not sure that matters
OS: Solaris.
checked both: v$database_block_corruption and v$backup_corruption
What is corruption_type = 'UNKNOWN' its not in the docs? All of my corrupt blocks in both views say 'unknown'
This is not production. Its development. So loss of data is not a big issue. Just trying to understand the situation.
It has been a number of years since I have had to repair block corruption. Please let me know if I am interpreting my findings correctly.
v$backup_corruption: I have corruption in my backups
v$database_block_corruption: corruption in my current DB
I only have 1 backup. (no space. No budget for tape backups... this is not production. working off of VMs. not exactly high end hardware).
Here are some additional questions:
1. Tried running a blockrecover. Did not expect it to work since the backups appear to be corrupted too. However, I did expect RMAN to tell me that I can't fix the blocks. dd thing is I didnt get any errors. I didn't expect the blocks to be repaired since the backups are corrupted. However, I did expect some kind of message or exception. How come oracle didn't say 'hey we can't repair this'
surprised that oracle is not telling me, I can't repair these? They dont get repaired almost certainly because the backup has corruption. Did I do something wrong or is this expected? After running this I checked v$database_block_corruption and nothing changed.
[code]
RMAN> blockrecover datafile 15 block 19621,19624,19608,19611,19617,19613;
Starting blockrecover at 07-AUG-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=288 devtype=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished blockrecover at 07-AUG-13
[/code]
2. I think my only other option is to use dbms_repair to flag these blocks as ignore. I know the segments involved and I can afford to ignore blocks in them. Its not the data dictionary. Is there something else I should look at?
3. If we change the rman backup command to backup validate, will this prevent the backups from running if there is corruption and generate an error? I can write a job that can look for it and send me an email.
4. would dbverify provide me with different data than what I got from rman?
Anything I am missing from my approach?How did you determine that you've corruption in your database and in your database backups ? Any ORA- errors or messages?
What is the output of the views ?
2. I think my only other option is to use dbms_repair to flag these blocks as ignore. I know the segments involved and I can afford to ignore blocks in them. Its not the data dictionary. Is there something else I should look at?
did you try to create the corrupted segments using CTAS ?
Backup validate will only validate, by default RMAN should fail if it encounters corruption (unless specified otherwise). And I think, RMAN/dbv will provide the same output. -
Logical data corrupton in alert log
Thanks for taking my question! I am hoping someone can help me because I am really in a bind. I had some issues restoring my database the other day. I thought I recovered everything but now I am seeing more errors in the alert log and I have no idea how what to do. Any help would be greatly appreciate!!!!!
I listed alert log errors at the end and I am 11g windows 2008 .
My first mistake was stop archive logging while a large job ran to save some time.
After the job completed I restarted the archive logging and then backed up the database and took an scn.
I then recovered back to the scn above and it appeared to go ok excetp I then noticed I had (2) v%database_block_corruptions.
I then decided to recover back several days and restore an the prd schema via an export takien before 1st restor.
I changed the incarniation back 1 and recovered and imported schema back.
I checheck v$database_block_corruption and it as empty. I am thinking ai am good.
I restart several batch jobs which finished ok.
I backup and it is good.
I now have the below logical errors in the alert log. They appeared inbetween the nightly rman backup and export.
Help! What is causing this and how do I fix it?
Kathie
export taken at 9:30
Wed Jul 22 22:00:03 2009
Error backing up file 2, block 47924: logical corruption
Error backing up file 2, block 47925: logical corruption
Error backing up file 2, block 47926: logical corruption
Error backing up file 2, block 47927: logical corruption
Error backing up file 2, block 71194: logical corruption
Error backing up file 2, block 78234: logical corruption
Error backing up file 2, block 78236: logical corruption
Error backing up file 2, block 78237: logical corruption
Error backing up file 2, block 78238: logical corruption
Error backing up file 2, block 78239: logical corruption
Error backing up file 2, block 78353: logical corruption
Error backing up file 2, block 78473: logical corruption
Error backing up file 2, block 79376: logical corruption
Error backing up file 2, block 79377: logical corruption
Error backing up file 2, block 79378: logical corruption
Error backing up file 2, block 81282: logical corruption
Error backing up file 2, block 81297: logical corruption
Error backing up file 2, block 81305: logical corruption
Error backing up file 2, block 81309: logical corruption
Error backing up file 2, block 81313: logical corruption
Error backing up file 2, block 81341: logical corruption
Error backing up file 2, block 81370: logical corruption
Error backing up file 2, block 81396: logical corruption
Error backing up file 2, block 82115: logical corruption
Error backing up file 2, block 82116: logical corruption
Error backing up file 2, block 82117: logical corruption
Error backing up file 2, block 82118: logical corruption
Error backing up file 2, block 82119: logical corruption
Error backing up file 2, block 85892: logical corruption
Error backing up file 2, block 85897: logical corruption
Error backing up file 2, block 85900: logical corruption
Error backing up file 2, block 85901: logical corruption
Error backing up file 2, block 85904: logical corruption
Error backing up file 2, block 85905: logical corruption
Error backing up file 2, block 85906: logical corruption
Error backing up file 2, block 85909: logical corruption
Error backing up file 2, block 85910: logical corruption
Error backing up file 2, block 85913: logical corruption
Error backing up file 2, block 85917: logical corruption
Error backing up file 2, block 85918: logical corruption
Error backing up file 2, block 85925: logical corruption
Error backing up file 2, block 85937: logical corruption
Error backing up file 2, block 85943: logical corruption
Error backing up file 2, block 85944: logical corruption
Error backing up file 2, block 85947: logical corruption
Error backing up file 2, block 85949: logical corruption
Error backing up file 2, block 85951: logical corruption
Error backing up file 2, block 85953: logical corruption
Error backing up file 2, block 85956: logical corruption
Error backing up file 2, block 85958: logical corruption
Error backing up file 2, block 85965: logical corruption
Error backing up file 2, block 85976: logical corruption
Error backing up file 2, block 85977: logical corruption
Error backing up file 2, block 85980: logical corruption
Error backing up file 2, block 85981: logical corruption
Error backing up file 2, block 85988: logical corruption
Error backing up file 2, block 85989: logical corruption
Error backing up file 2, block 85995: logical corruption
Error backing up file 2, block 86001: logical corruption
Error backing up file 2, block 86003: logical corruption
Error backing up file 2, block 86005: logical corruption
Error backing up file 2, block 86012: logical corruption
Error backing up file 2, block 86013: logical corruption
Error backing up file 2, block 86015: logical corruption
Error backing up file 2, block 93961: logical corruption
Error backing up file 2, block 93965: logical corruption
Error backing up file 2, block 93968: logical corruption
Error backing up file 2, block 93971: logical corruption
Error backing up file 2, block 93975: logical corruption
Error backing up file 2, block 93979: logical corruption
Error backing up file 2, block 93983: logical corruption
Error backing up file 2, block 93984: logical corruption
Error backing up file 2, block 93987: logical corruption
Error backing up file 2, block 93988: logical corruption
Error backing up file 2, block 93992: logical corruption
Error backing up file 2, block 93996: logical corruption
Error backing up file 2, block 94008: logical corruption
Error backing up file 2, block 94022: logical corruption
Error backing up file 2, block 94026: logical corruption
Error backing up file 2, block 94027: logical corruption
Error backing up file 2, block 94030: logical corruption
Error backing up file 2, block 94031: logical corruption
Error backing up file 2, block 94034: logical corruption
Error backing up file 2, block 94038: logical corruption
Error backing up file 2, block 94041: logical corruption
Error backing up file 2, block 94042: logical corruption
Error backing up file 2, block 94047: logical corruption
Error backing up file 2, block 94074: logical corruption
Error backing up file 2, block 94077: logical corruption
Error backing up file 2, block 118881: logical corruption
Error backing up file 2, block 118882: logical corruption
Error backing up file 2, block 118883: logical corruption
Error backing up file 2, block 118884: logical corruption
Wed Jul 22 22:00:27 2009
Thread 1 advanced to log sequence 279 (LGWR switch)
Current log# 3 seq# 279 mem# 0: F:\ORACLE\11.1.0\ORADATA\CS90QAP\REDO03.LOG
Current log# 3 seq# 279 mem# 1: E:\ORACLE\11.1.0\ORADATA\CS90QAP\REDO03A.LOG
Wed Jul 22 22:04:29 2009
Thread 1 advanced to log sequence 280 (LGWR switch)
Current log# 4 seq# 280 mem# 0: F:\ORACLE\11.1.0\ORADATA\CS90QAP\REDO04.LOG
Current log# 4 seq# 280 mem# 1: E:\ORACLE\11.1.0\ORADATA\CS90QAP\REDO04A.LOG
Wed Jul 22 22:37:15 2009
ALTER SYSTEM ARCHIVE LOG -this is the nightly backup.
Edited by: user579885 on Jul 23, 2009 7:36 AMIf the index is part of EM why wait? How many EM users can you have? It should just be the DBA's.
Being the object is a PK there could be FK that references it. If there are FK to the PK I would try the alter index rebuild to see if that 1- works and 2- fixes the issue before I resorted to drop/create since the rebuild can be done without having to disable and re-enable the FK.
Also note that under certain conditions such as if the index status is INVALID the alter index rebuild will read the table rather than just read the index for its data.
HTH -- Mark D Powell -- -
Block corruptioin after rman restore/recovery
Thanks for taking my question!
Oracle Enterprise Edition 11.1.0.7 on Windows 2008. Using Rman on-line backups COMPRESSED.
Can anyone give me any ideas on why SYSAUX data block corruption should occur after a rman recovery?
Below is my script. Am I missing something? Should I be physically removing the redo? Any ideas welcome?
Thanks!
Kathie
rman> restore until seq = 123
recover until seq = 123
alter database open resetlogs;
Background:
I had to do a rman recovery the other day to restore our database back to the previous day. After the recovery the sysaux table became logically corrupted. I tried to fix data corruption with rman but it said it couldn't after reading thru 6 days of backups. I ended up deleting the database, recreating the database and restoring from an export takien a few hours prior.
I now have a database to test rman recovery. Database has been up and rman backups (compressed) running for several days. I tried to recover back to previouse day and again SYSAUX has logical corruption. I tried to use Rman to recover data corruption but it failed.
I deleted database and recreated it. Took several rman on-line backups (this time not compressed). Did 3rd recovery this time only a few hours back. This time everything worked - no sysaux block corruption but why? The only difference is the recovery used non compressed backups and recovery was a shorter time frame. why ???I agree the errors are not identical but I am going to stop performing compressed backups until I am sure that is not the issue.
My first two recoveries had logical block corruption and this last one without compression set had no block corruption. I performed the same recovery process for all recoveries and the big difference was the successfull recovery did not have compressed backups. I checked v$database_block_corruption and it shows no errors. I also, performed a backup and verify to double check.
The only issue I can see is below. I am hoping someone can confirm this is normal after "alter database open resetlogs". Can anyone verify that?
Thanks!
Kathie
Thu Aug 27 10:17:49 2009
alter database open resetlogs
RESETLOGS after incomplete recovery UNTIL CHANGE 3587892
Resetting resetlogs activation ID 3129052671 (0xba818dff)
Thu Aug 27 10:17:50 2009
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO01.LOG'
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 2 of thread 1, type 0 in header is not log file
ORA-00312: online log 2 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO02.LOG'
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 3 of thread 1, type 0 in header is not log file
ORA-00312: online log 3 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO03.LOG'
Thu Aug 27 10:17:53 2009
Setting recovery target incarnation to 3 -
Hi All,
This is my requirement. I want to execute below rman script in all the databases we monitor. After that we are thinking of creating UDM to poll against v$database_block_corruption and alert for any corruption.
RMAN> backup validate check logical database;
Would like to know best way to implement in OEM. Pls advise.
Regards,
Satheesh Shanmugam
http://borndba.comRob, I tried something like this to force archive backup during specific time of the day. So thinking of doing something similar here.
You should be knowing only corrective action requires host credential, the agent response action script doesn't require host credential.
In the host target keep the required rman script, which can be invoked via agent response action. Then create a UDM in such a way that it raises alert during specific time of a day. Say every sunday between 8-10am, the UDM returns 1 which will match the critical threshold. Invoke the agent response action script in the critical threshold.
Regards,
Satheesh Shanmugam
http://borndba.com -
System datafile block corruption - no backups and database in NOARCHIVELOG mode
Dear All,
Database version - oracle 11.1 Enterprise
OS - RHELinux 5.8
What are the options of recovering from physical block corruption when there are no backup available to perform block media recovery?
V$DATABASE_BLOCK_CORRUPTION reports two segments corrupted (please see attached image for details).
1 table in system datafile - sys_fba_barrierscn
1 index - (applicaiton index)
What are my options?
I know there is a possibility that the database will not restart after a shutdown due to corruption in system tablespace.
Database is in noarchivelog mode. So online backups are not possible and there aren't any full backups either.
I am thinking of below,
1. Run dbms_repair with fix_block_corruption. - Still database startup might fail?
2. Shutdown the database and take offline full backup with RMAN MAXCorrupt option.
Appreciate your suggestions and advises.
Thanks
StefanThanks Sybrand,
Agree with your first two suggestions .
Also scheduled a expdp job tonight. (Only backup like thing they had was a expdp cron, but until today all the large tables were failing due to small undo_retention).
Yes. Flashback is not used. So hopefully it will not affect the a database restart i guess?
Related to dbms_repair, I was referring to - http://askdba.org/weblog/2010/08/physical-corruption-ora-1578-part-3/.
Where DBMS_REPAIR.FIX_CORRUPT_BLOCKS and DBMS_REPAIR.SKIP_CORRUPT_BLOCKS used.
Which i think will not use any redo.
Thanks
Stefan -
NEED TO RECOVER A DATABASE USING RMAN with CONTROL FILE AND NO RMAN CATALOG, DISK FAILURE..
Hello All,
The disk failure caused our production data on the disk to be resotred with the backup data available and recovered through RMAN with cotrolfile , and no catalog DB is configured.
I had the restored the spfile and control file then recovered the database,
startup nomount;
RESTORE SPFILE FROM ' path ' ;
Shutdown immediate;
startup nomount
Restore controfile from autobackup;
restore database;
[AT POINT , A MESSAGE PROMPTED LIKE " failur of restored command - some targets not found" (thinking may be few archives are not found, i proceeded to incomeplete recovery of DB) ]
recover database;
Finished reocvery .
Now in the Grid control i see that 60 blocks of a particular datafile are corrupted and needs recovery. Do i need to get the data file resotred again and recover it or any simple way to recover this data file
When i perform the block recovery , it says recovery failed and when i run the data file recovery it succeeds. Please provide you inputs to recover the database as it is production BI database and pretty critical to our client.
Thanks for your valuable time in advance.
Regards,
Ran G.These is a common problem if the object are created due to NOLOGGIN option. If you check most of the object which are facing block corruption is indexes .
Use the below query to check the objects :
It will map each block from v$database_block_corruption to either a segment or if the block is free.
$ sqlplus / as sysdba
set pagesize 2000
set linesize 250
SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
- greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks - 1
AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
, header_block corr_start_block#
, header_block corr_end_block#
, 1 blocks_corrupted
, 'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
, greatest(f.block_id, c.block#) corr_start_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
- greatest(f.block_id, c.block#) + 1 blocks_corrupted
, 'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks - 1
AND f.block_id + f.blocks - 1 >= c.block#
order by file#, corr_start_block#;
Below oracle support note will help you :
ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING - Error explanation and solution (Doc ID 794505.1)
The Gains and Pains of Nologging Operations (Doc ID 290161.1)
SQL> select d.NAME as DBF_NAME, t.NAME as TS_NAME, d.UNRECOVERABLE_CHANGE# as NOLOG_CHNG#, to_char(d.UNRECOVERABLE_TIME, 'Dy DD-Mon-YYYY HH24:MI:SS') as NOLOG_TIME from V$DATAFILE d join V$TABLESPACE t on d.TS# = t.TS# order by t.NAME;
Thanks,
gssdba.wordpress.com -
Integrity check of tables between Oracle 9i and Oracle 11g
Hi,
|Is there a tool or a way to check the integrity of data in the tables after migrating data from an Oracle 9i database to an Oracle 11g database?
Thanks for you help.Hi,
How do you want to proceed for your migration ? Assuming everything was OK in your 9i database normally things should go well whatever the method.
For example as the previous posters mentioned if you use exp/imp and if you have "successfully without warnings" at the end of the operations you can trust those messages. Physical corruption is not the only possible problem and with exp/imp some things not to forget :
- checking the compatibility of the source and target database charactersets and positioning correctly the NLS_LANG variables for exp and imp
- activity on the source at the time of your export ? Your export has to be "logically" consistent.
Oh and about block integrity do a good full rman backup on your 11g database after the migration and check v$database_block_corruption after the backup. RMAN is your friend about physical integrity. Even after an incremental rman backup if a query on this view gives 0 result you can be sure you have no block corruption (at least if block_change_tracking is not used)
Best regards
Phil -
System and sysaux file block corruption
Errors in file /u01/app/oracle/diag/rdbms/pdent/pdent/trace/pdent_smon_3135.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 91607)
ORA-01110: data file 1: '/u01/app/oracle/oradata/pdent/system01.dbf'
I am unable to take r man backup, as well as export using datapump. i tried to recover it using rman blockrecover but still same. here is detail
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
1 91607 1 0 CHECKSUM
2 58710 1 0 CHECKSUM
5 1202316 1 0 CHECKSUM
SQL> SELECT
tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id = 1
AND BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
TABLESPACE_NAME SEGMENT_TYPE OWNER
SEGMENT_NAME
SYSTEM INDEX SYS
I_OBJ2
alter system dump datafile 1 block 344;
SQL> SELECT
tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id = 2
AND 58710 BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
TABLESPACE_NAME SEGMENT_TYPE OWNER
SEGMENT_NAME
SYSAUX INDEX PARTITION SYS
WRH$_OSSTAT_PK
SQL> ALTER INDEX I_OBJ2 REBUILD ONLINE;
ALTER INDEX I_OBJ2 REBUILD ONLINE
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered
need immediate help.
thanks in advanceuser11914238 wrote:
Errors in file /u01/app/oracle/diag/rdbms/pdent/pdent/trace/pdent_smon_3135.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 91607)
ORA-01110: data file 1: '/u01/app/oracle/oradata/pdent/system01.dbf'
I am unable to take r man backup, as well as export using datapump. i tried to recover it using rman blockrecover but still same. here is detail
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
1 91607 1 0 CHECKSUM
2 58710 1 0 CHECKSUM
5 1202316 1 0 CHECKSUM
SQL> SELECT
tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id = 1
AND BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
TABLESPACE_NAME SEGMENT_TYPE OWNER
SEGMENT_NAME
SYSTEM INDEX SYS
I_OBJ2
alter system dump datafile 1 block 344;
SQL> SELECT
tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id = 2
AND 58710 BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
TABLESPACE_NAME SEGMENT_TYPE OWNER
SEGMENT_NAME
SYSAUX INDEX PARTITION SYS
WRH$_OSSTAT_PK
SQL> ALTER INDEX I_OBJ2 REBUILD ONLINE;
ALTER INDEX I_OBJ2 REBUILD ONLINE
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered
need immediate help.
Immediate help can be only provided by Oracle Support Services. So if you need that, please raise a Sev1 SR . For your issue, as others have suggested already, if you have a valid backup and you are in the archive log mode, using RMAN's BMR(Block Media Recovery) , the issue can be resolved provided there is nothing wrong with the hardware of yours. If that's the case, recovery wouldn't yield any benefits.
Aman.... -
Block corruption problem in alert and rman/dbv no show errors
Hello, I'm new in Oracle's world. I have one problem with Oracle 10.2.0.4 (RHEL 5.6) x64. Archive redo-log enable
In the alert.log, three days ago show (the server have kernel panic & rebooted):
Mon Sep 24 18:18:17 2012
Hex dump of (file 17, block 669888) in trace file xxxxxxxxxx.trc
Corrupt block relative dba: 0x044a38c0 (file 17, block 669888)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x044a38c0
last change scn: 0x0000.14eb5309 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x53090601
check value in block header: 0x6ea3
computed block checksum: 0x2
Reread of rdba: 0x044a38c0 (file 17, block 669888) found same corrupted data
Mon Sep 24 18:18:19 2012
Corrupt Block Found
TSN = 23, TSNAME = TABLE_TSD1
RFN = 17, BLK = 669888, RDBA = 71973056
OBJN = 86908, OBJD = 86908, OBJECT = SYS_C0040110, SUBOBJECT =
SEGMENT OWNER = SCHEMA1, SEGMENT TYPE = Index Segment
Yesterday, we detected this error because SQL don't execute.
The error repeat 47times and there is 6 different file-block combination (4 index of schemas, 1 of sys and ¡2 tables!)
First, I launched expdp and exp of the one problematic schema. The export was fine, no errors while exporting, but in the alert.log show one block corruption. Should exp and expd show error and stop?
Next, I used dbv and verify all dbfs. Only show 2 blocks error in two datafiles (indexes).
Next, I used RMAN:
A) check database: no error.
B) validate database: error in two blocks (logical error) and different from the 6 in alert.log. This two blocks are indexes.
I re-create this two indexes. When i re-create, the block error disappear (not inmediate, suppose that disappear when block was rewrite). Now dbv and rman show no error.
I have read one note about types of error, other about procedures if db is in archivelog/noarchivelog. Also if object is index or table. But I find anything about auto-repair corrupt blocks in Oracle or why now the 6 block error are solved. I don't know if two tables with two block corrupt lost rows or not.
Appreciate any help.
RegardsHello Fran. Result of query before rebuild problematic INDEXES:
SQL> select * from V$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 98857 1 390928740 LOGICAL
9 48632 1 390325900 LOGICAL
When I ran RMAN first time to check blocks, it filled V$database_block_corruption with two bad blocks. Different from the 6 errors from alert.:
RMAN> backup validate check logical database;
Error backing up file 9, block 48632: logical corruption
Error backing up file 3, block 98857: logical corruption
I extracted index name from each block and I re-created it. Also, I created a temporary table in tablespace's datafile to fill blocks empty. Problem solved. Rman / dbv show no error.
I'm searching for similar experiences and found: Re: Data in bad block
First 6 bad checksum errors in alert.log disappear with any visible problem?
Can I sure that DB is fine if RMAN and DBV show no errors?
Thank you very much
Edited by: user7755509 on 27-sep-2012 5:43 -
How to diagnose and recover corrupted datafile?
DBMS: Oracle v.9.2.0.1.0
OS: MS Server 2003 R2 SP2 x86
Problem: Database begin to stop every few minutes. I start to check and found that one and the largest of two datafiles is probably corrupted. Now I have no idea how to repair that datafile.
Firstly, I look into the alert.log and see that^
Mon Jul 29 11:02:03 2013
SMON: enabling tx recovery
Mon Jul 29 11:02:03 2013
Database Characterset is CL8MSWIN1251
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open
Mon Jul 29 11:02:42 2013
KCF: write/open error block=0x3c009f online=1
file=4 F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
error=27069 txt: 'OSD-04026: Invalid parameter passed. (OS 3932319)'
Mon Jul 29 11:02:42 2013
Errors in file c:\oracle\admin\orcl\bdump\orcl_dbw0_3604.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01114: IO error writing block to file 4 (block # 3932319)
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 3932319)
DBW0: terminating instance due to error 1242
Instance terminated by DBW0, pid = 3604
Dump file c:\oracle\admin\orcl\bdump\alert_orcl.log
So, I turned archivelog on and open database but it continue to stop when somebody calls to some DB objects.
Then, I check v$headers:
SQL> select file#, status, recover, fuzzy, tablespace_name, to_char(CHECKPOINT_CHANGE#), name from v$datafile_header;
FILE# STATUS REC FUZ TABLESPACE_NAME TO_CHAR(CHECKPOINT_CHANGE#) NAME
1 ONLINE NO YES SYSTEM 9679059694215 F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
2 ONLINE NO YES UNDO 9679059694215 F:\ORACLE\ORADATA\ORCL\UNDO.ORA
3 ONLINE NO YES USERS 9679059694215 F:\ORACLE\ORADATA\ORCL\USERS.ORA
4 OFFLINE YES YES USERS 9679059697551 F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
For some reason, USERS in USERS_1.ORA is offline and marked as requiring recovery.
I tried to recover datafile, but get some errors:
SQL> recover datafile 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA';
ORA-00283: recovery session canceled due to errors
ORA-01115: IO error reading block from file 4 (block # 3932319)
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 3932319)
That have looking creepy for me.
I tries to verify datafile:
dbv file=F:\oracle\oradata\orcl\users_1.ora blocksize=16384 logfile=F:\oracle\oradata\orcl\dbvlog.txt
The result of verification was unexpectedly clean:
DBVERIFY: Release 9.2.0.1.0 - Production on Tue Jul 30 05:03:26 2013
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = F:\oracle\oradata\orcl\users_1.ora
DBVERIFY - Verification complete
Total Pages Examined : 3932320
Total Pages Processed (Data) : 94051
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 19378
Total Pages Failing (Index): 0
Total Pages Processed (Other): 3753059
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 65832
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Now I have that offlined tablespace in the probably not corrupted datafile and no idea how to get DB into the normal state.
Upd: I did database validation by RMAN:
RMAN> BACKUP VALIDATE DATABASE;
Starting backup at 30-JUL-13
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00004 name=F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
input datafile fno=00002 name=F:\ORACLE\ORADATA\ORCL\UNDO.ORA
input datafile fno=00003 name=F:\ORACLE\ORADATA\ORCL\USERS.ORA
input datafile fno=00001 name=F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
channel ORA_DISK_1: backup set complete, elapsed time: 00:33:06
Finished backup at 30-JUL-13
That would been check my DB and put information of corrupted blocks to a V$DATABASE_BLOCK_CORRUPTION, but no! There's nothing:
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
no rows selected
Nevertheless, database doesn't open, until I switch bad datafile to offline^
SQL> alter database datafile 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA' online;
Database altered.
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
Message was edited by: Llywelyn.yvDoes it diferents from below?
RMAN> BACKUP VALIDATE DATABASE;
Starting backup at 30-JUL-13
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00004 name=F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
input datafile fno=00002 name=F:\ORACLE\ORADATA\ORCL\UNDO.ORA
input datafile fno=00003 name=F:\ORACLE\ORADATA\ORCL\USERS.ORA
input datafile fno=00001 name=F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
channel ORA_DISK_1: backup set complete, elapsed time: 00:33:06
Finished backup at 30-JUL-13 -
Hello,
I am running a backup and checking for any logical corruption -
RMAN> backup check logical database;
Starting backup at 03-MAR-10
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=135 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Data Protection for Oracle: version 5.5.1.0
allocated channel: ORA_SBT_TAPE_2
channel ORA_SBT_TAPE_2: SID=137 device type=SBT_TAPE
channel ORA_SBT_TAPE_2: Data Protection for Oracle: version 5.5.1.0
allocated channel: ORA_SBT_TAPE_3
channel ORA_SBT_TAPE_3: SID=138 device type=SBT_TAPE
channel ORA_SBT_TAPE_3: Data Protection for Oracle: version 5.5.1.0
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00014 name=/oracle1/data01/TESTDB/TESTDB_compress_test_01.dbf
input datafile file number=00006 name=/oracle/TESTDB/data01/TESTDB_shau_01.dbf
input datafile file number=00015 name=/oracle/product/11.1/dbs/ILM_TOOLKIT_IML_TEST_TAB_A.f
channel ORA_SBT_TAPE_1: starting piece 1 at 03-MAR-10
channel ORA_SBT_TAPE_2: starting full datafile backup set
channel ORA_SBT_TAPE_2: specifying datafile(s) in backup set
input datafile file number=00003 name=/oracle/TESTDB/data02/TESTDB_undo_01.dbf
input datafile file number=00013 name=/oracle/TESTDB/data01/TESTDB_roop_01.dbf
input datafile file number=00012 name=/oracle/TESTDB/data01/TESTDB_example_01.dbf
input datafile file number=00005 name=/oracle/TESTDB/data01/TESTDB_sysaud_tab_1m_01.dbf
channel ORA_SBT_TAPE_2: starting piece 1 at 03-MAR-10
channel ORA_SBT_TAPE_3: starting full datafile backup set
channel ORA_SBT_TAPE_3: specifying datafile(s) in backup set
input datafile file number=00004 name=/oracle/TESTDB/data01/TESTDB_users_01.dbf
input datafile file number=00001 name=/oracle/TESTDB/data01/TESTDB_system_01.dbf
input datafile file number=00002 name=/oracle/TESTDB/data01/TESTDB_sysaux_01.dbf
input datafile file number=00025 name=/oracle/export_files/TESTDB_users_02.dbf
channel ORA_SBT_TAPE_3: starting piece 1 at 03-MAR-10
channel ORA_SBT_TAPE_3: finished piece 1 at 03-MAR-10
piece handle=5ul7ltsd_1_1 tag=TAG20100303T204356 comment=API Version 2.0,MMS Version 5.5.1.0
channel ORA_SBT_TAPE_3: backup set complete, elapsed time: 00:05:15
channel ORA_SBT_TAPE_2: finished piece 1 at 03-MAR-10
piece handle=5tl7ltsd_1_1 tag=TAG20100303T204356 comment=API Version 2.0,MMS Version 5.5.1.0
channel ORA_SBT_TAPE_2: backup set complete, elapsed time: 00:06:56
channel ORA_SBT_TAPE_1: finished piece 1 at 03-MAR-10
piece handle=5sl7ltsd_1_1 tag=TAG20100303T204356 comment=API Version 2.0,MMS Version 5.5.1.0
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:08:16
Finished backup at 03-MAR-10
Starting Control File and SPFILE Autobackup at 03-MAR-10
piece handle=c-2109934325-20100303-0c comment=API Version 2.0,MMS Version 5.5.1.0
Finished Control File and SPFILE Autobackup at 03-MAR-10
Question: By looking at the output, how can I say that RMAN did an Logical Check for the corruption? This output looks same as a simple backup without logical corruption check. Please advice how to check about this?
Thanks!hi
I think you won't see any summary on this, only when corruption is found.
There is also one related setting that can be incorporated here - see example:
Example 2-25 Specifying Corruption Tolerance for Datafile Backups
This example assumes a database that contains 5 datafiles. It uses the SET MAXCORRUPT command to indicate than no more than 1 corruption should be tolerated in each datafile. Because the CHECK LOGICAL option is specified on the BACKUP command, RMAN checks for both physical and logical corruption.
RUN
+{+
SET MAXCORRUPT FOR DATAFILE 1,2,3,4,5 TO 1;
BACKUP CHECK LOGICAL
DATABASE;
+}+
use this to see clear output:
-- Check for physical corruption of all database files.
VALIDATE DATABASE;
-- Check for physical and logical corruption of a tablespace.
VALIDATE CHECK LOGICAL TABLESPACE USERS;
eg.
List of Datafiles
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
+1 FAILED 0 3536 57600 637711+
File Name: /disk1/oradata/prod/system01.dbf
Block Type Blocks Failing Blocks Processed
Data 1 41876
Index 0 7721
Other 0 4467 -
Urgent- block corruption on standby and recovery thru physical copy file
Hi all,
We have a ORacle 9.2.0.6 DB and we have manula physical standby DB.
We got a block corruption on standby and I got to know thru metalink that we have to copy the data file from primary to standby but
my question is when we copy the datafile from primary to standby, will i be able to do the same because I think the SCN may varies ,as when i down the standby to copy the datafile ,oracle server wrtie a SCN to the control file of standby and when i will open it it will throw an error....
Please suggest me....we are having n numbers od block corruption so what should be the exact value in
alter database recover automatic standby database allow *1* corruptionpls suggeest me
select * from v$backup_corruption;
RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MARKED_CORRUPT CORRUPTION_TYPE
1 679059926 679058677 54 1 3 299997 12 1790569359 NO LOGICAL
2 679059926 679058677 54 1 3 300010 15 1790569374 NO LOGICAL
3 679059926 679058677 54 1 3 300026 15 1790569389 NO LOGICAL
4 679059926 679058677 54 1 3 300042 7 1790569404 NO LOGICAL
5 679059926 679058677 54 1 3 300433 8 1790569404 NO LOGICAL
6 679059926 679058677 54 1 3 300442 15 1790569419 NO LOGICAL
7 679059926 679058677 54 1 3 300458 15 1790569434 NO LOGICAL
8 679059926 679058677 54 1 3 300690 15 1790569450 NO LOGICAL
9 679059926 679058677 54 1 3 300930 7 1790569465 NO LOGICAL
10 679059926 679058677 54 1 3 2427217 64 1545959567 NO LOGICAL
11 679059926 679058677 54 1 3 3078291 126 1790569473 NO LOGICAL
12 679059926 679058677 54 1 3 3236929 8 1790569465 NO LOGICAL
13 679059926 679058677 54 1 3 3236941 12 1790464761 NO LOGICAL
14 679059926 679058677 54 1 3 3236954 15 1790464776 NO LOGICAL
15 679059926 679058677 54 1 3 3236970 15 1790464792 NO LOGICAL
16 679059926 679058677 54 1 3 3236986 15 1790464807 NO LOGICAL
17 679059926 679058677 54 1 3 3237002 7 1790464822 NO LOGICAL
18 679059926 679058677 54 1 3 3242641 8 1790464822 NO LOGICAL
19 679059926 679058677 54 1 3 3242650 15 1790464837 NO LOGICAL
20 679059926 679058677 54 1 3 3242666 15 1790464852 NO LOGICAL
21 679059926 679058677 54 1 3 3242682 15 1790464867 NO LOGICAL
22 679059926 679058677 54 1 3 3242771 40 1790464875 NO LOGICAL
23 679059926 679058677 54 1 3 3242899 126 1790569482 NO LOGICAL
24 679059926 679058677 54 1 3 3243027 126 1790569491 NO LOGICAL
25 679059926 679058677 54 1 3 3243155 126 1790569500 NO LOGICAL
26 679059926 679058677 54 1 3 3243283 126 1790569509 NO LOGICAL
27 679059926 679058677 54 1 3 3243411 126 1790569518 NO LOGICAL
28 679059926 679058677 54 1 3 3243539 126 1790569527 NO LOGICAL
29 679059926 679058677 54 1 3 3243667 126 1790569536 NO LOGICAL
30 679059926 679058677 54 1 3 3243795 126 1790569545 NO LOGICAL
31 679059926 679058677 54 1 3 3243923 126 1790569554 NO LOGICAL
32 679059926 679058677 54 1 3 3244051 126 1790569564 NO LOGICAL
33 679059926 679058677 54 1 3 3244179 126 1790569573 NO LOGICAL
34 679059926 679058677 54 1 3 3244307 126 1790569582 NO LOGICAL
35 679059926 679058677 54 1 3 3244435 126 1790569591 NO LOGICAL
36 679059926 679058677 54 1 3 3244563 126 1790569600 NO LOGICAL
37 679059926 679058677 54 1 3 3244691 126 1790569609 NO LOGICAL
38 679059926 679058677 54 1 3 3244819 126 1790569618 NO LOGICAL
39 679059926 679058677 54 1 3 3244947 126 1790569627 NO LOGICAL
40 679059926 679058677 54 1 3 3245075 126 1790569637 NO LOGICAL
41 679059926 679058677 54 1 3 3245203 126 1790569646 NO LOGICAL
42 679059926 679058677 54 1 3 3245331 126 1790569655 NO LOGICAL
43 679059926 679058677 54 1 3 3245459 126 1790569664 NO LOGICAL
44 679059926 679058677 54 1 3 3245587 126 1790569673 NO LOGICAL
45 679059926 679058677 54 1 3 3245715 126 1790569683 NO LOGICAL
46 679059926 679058677 54 1 3 3245843 126 1790569692 NO LOGICAL
47 679059926 679058677 54 1 3 3245971 126 1790569701 NO LOGICAL
48 679059926 679058677 54 1 3 3246099 126 1790569710 NO LOGICAL
49 679059926 679058677 54 1 3 3246227 126 1790569719 NO LOGICAL
50 679059926 679058677 54 1 3 3246355 126 1790569728 NO LOGICAL
51 679059926 679058677 54 1 3 3246483 126 1790569737 NO LOGICAL
52 679059926 679058677 54 1 3 3246611 126 1790569746 NO LOGICAL
53 679059926 679058677 54 1 3 3246739 126 1790569755 NO LOGICAL
54 679059926 679058677 54 1 3 3246867 126 1790569764 NO LOGICAL
55 679059926 679058677 54 1 3 3246995 126 1790569773 NO LOGICAL
56 679059926 679058677 54 1 3 3247123 126 1790569782 NO LOGICAL
57 679059926 679058677 54 1 3 3247251 126 1790569791 NO LOGICAL
58 679059926 679058677 54 1 3 3247379 126 1790569801 NO LOGICAL
59 679059926 679058677 54 1 3 3247507 126 1790569811 NO LOGICAL
60 679059926 679058677 54 1 3 3247635 126 1790569820 NO LOGICAL
61 679059926 679058677 54 1 3 3247763 126 1790569829 NO LOGICAL
62 679059926 679058677 54 1 3 3247891 126 1790569838 NO LOGICAL
63 679059926 679058677 54 1 3 3248019 126 1790569847 NO LOGICAL
64 679059926 679058677 54 1 3 3248147 126 1790569856 NO LOGICAL
65 679059926 679058677 54 1 3 3248275 126 1790569865 NO LOGICAL
66 679059926 679058677 54 1 3 3248403 126 1790569874 NO LOGICAL
67 679059926 679058677 54 1 3 3248531 126 1790569883 NO LOGICAL
68 679059926 679058677 54 1 3 3248659 126 1790569892 NO LOGICAL
69 679059926 679058677 54 1 3 3248787 126 1790569901 NO LOGICAL
70 679059926 679058677 54 1 3 3248915 126 1790569910 NO LOGICAL
71 679059926 679058677 54 1 3 3249043 126 1790569920 NO LOGICAL
72 679059926 679058677 54 1 3 3249171 126 1790569929 NO LOGICAL
73 679059926 679058677 54 1 3 3249299 126 1790569938 NO LOGICAL
74 679059926 679058677 54 1 3 3249427 126 1790569947 NO LOGICAL
75 679059926 679058677 54 1 3 3249555 126 1790569956 NO LOGICAL
76 679059926 679058677 54 1 3 3249683 126 1790569965 NO LOGICAL
77 679059926 679058677 54 1 3 3249811 126 1790569974 NO LOGICAL
78 679059926 679058677 54 1 3 3249939 126 1790569984 NO LOGICAL
79 679059926 679058677 54 1 3 3250067 126 1790569993 NO LOGICAL
80 679059926 679058677 54 1 3 3250195 126 1790570002 NO LOGICAL
81 679059926 679058677 54 1 3 3250323 126 1790570011 NO LOGICAL
82 679059926 679058677 54 1 3 3250451 126 1790570020 NO LOGICAL
83 679059926 679058677 54 1 3 3250579 126 1790570029 NO LOGICAL
84 679059926 679058677 54 1 3 3250706 127 1790570039 NO LOGICAL
85 679059926 679058677 54 1 3 3250837 1020 1790570048 NO LOGICAL
86 679059926 679058677 54 1 3 3251861 1020 1790570057 NO LOGICAL
87 679059926 679058677 54 1 3 3252885 1020 1790570067 NO LOGICAL
88 679059926 679058677 54 1 3 3253909 1020 1790570076 NO LOGICAL
89 679059926 679058677 54 1 3 3254933 1020 1790570086 NO LOGICAL
90 679059926 679058677 54 1 3 3255957 1020 1790570095 NO LOGICAL
91 679059926 679058677 54 1 3 3256981 1020 1790570104 NO LOGICAL
92 679059926 679058677 54 1 3 3258005 1020 1790570114 NO LOGICAL
93 679059926 679058677 54 1 3 3259029 1020 1790570123 NO LOGICAL
94 679059926 679058677 54 1 3 3260053 1020 1790570133 NO LOGICAL
95 679059926 679058677 54 1 3 3261077 486 1790570142 NO LOGICAL NO LOGICAL
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 299997 12 1790569359 LOGICAL
3 300010 15 1790569374 LOGICAL
3 300026 15 1790569389 LOGICAL
3 300042 7 1790569404 LOGICAL
3 300433 8 1790569404 LOGICAL
3 300442 15 1790569419 LOGICAL
3 300458 15 1790569434 LOGICAL
3 300690 15 1790569450 LOGICAL
3 300930 7 1790569465 LOGICAL
3 2427217 64 1545959567 LOGICAL
3 3078291 126 1790569473 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3236929 8 1790569465 LOGICAL
3 3236941 12 1790464761 LOGICAL
3 3236954 15 1790464776 LOGICAL
3 3236970 15 1790464792 LOGICAL
3 3236986 15 1790464807 LOGICAL
3 3237002 7 1790464822 LOGICAL
3 3242641 8 1790464822 LOGICAL
3 3242650 15 1790464837 LOGICAL
3 3242666 15 1790464852 LOGICAL
3 3242682 15 1790464867 LOGICAL
3 3242771 40 1790464875 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3242899 126 1790569482 LOGICAL
3 3243027 126 1790569491 LOGICAL
3 3243155 126 1790569500 LOGICAL
3 3243283 126 1790569509 LOGICAL
3 3243411 126 1790569518 LOGICAL
3 3243539 126 1790569527 LOGICAL
3 3243667 126 1790569536 LOGICAL
3 3243795 126 1790569545 LOGICAL
3 3243923 126 1790569554 LOGICAL
3 3244051 126 1790569564 LOGICAL
3 3244179 126 1790569573 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3244307 126 1790569582 LOGICAL
3 3244435 126 1790569591 LOGICAL
3 3244563 126 1790569600 LOGICAL
3 3244691 126 1790569609 LOGICAL
3 3244819 126 1790569618 LOGICAL
3 3244947 126 1790569627 LOGICAL
3 3245075 126 1790569637 LOGICAL
3 3245203 126 1790569646 LOGICAL
3 3245331 126 1790569655 LOGICAL
3 3245459 126 1790569664 LOGICAL
3 3245587 126 1790569673 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3245715 126 1790569683 LOGICAL
3 3245843 126 1790569692 LOGICAL
3 3245971 126 1790569701 LOGICAL
3 3246099 126 1790569710 LOGICAL
3 3246227 126 1790569719 LOGICAL
3 3246355 126 1790569728 LOGICAL
3 3246483 126 1790569737 LOGICAL
3 3246611 126 1790569746 LOGICAL
3 3246739 126 1790569755 LOGICAL
3 3246867 126 1790569764 LOGICAL
3 3246995 126 1790569773 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3247123 126 1790569782 LOGICAL
3 3247251 126 1790569791 LOGICAL
3 3247379 126 1790569801 LOGICAL
3 3247507 126 1790569811 LOGICAL
3 3247635 126 1790569820 LOGICAL
3 3247763 126 1790569829 LOGICAL
3 3247891 126 1790569838 LOGICAL
3 3248019 126 1790569847 LOGICAL
3 3248147 126 1790569856 LOGICAL
3 3248275 126 1790569865 LOGICAL
3 3248403 126 1790569874 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3248531 126 1790569883 LOGICAL
3 3248659 126 1790569892 LOGICAL
3 3248787 126 1790569901 LOGICAL
3 3248915 126 1790569910 LOGICAL
3 3249043 126 1790569920 LOGICAL
3 3249171 126 1790569929 LOGICAL
3 3249299 126 1790569938 LOGICAL
3 3249427 126 1790569947 LOGICAL
3 3249555 126 1790569956 LOGICAL
3 3249683 126 1790569965 LOGICAL
3 3249811 126 1790569974 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3249939 126 1790569984 LOGICAL
3 3250067 126 1790569993 LOGICAL
3 3250195 126 1790570002 LOGICAL
3 3250323 126 1790570011 LOGICAL
3 3250451 126 1790570020 LOGICAL
3 3250579 126 1790570029 LOGICAL
3 3250706 127 1790570039 LOGICAL
3 3250837 1020 1790570048 LOGICAL
3 3251861 1020 1790570057 LOGICAL
3 3252885 1020 1790570067 LOGICAL
3 3253909 1020 1790570076 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3254933 1020 1790570086 LOGICAL
3 3255957 1020 1790570095 LOGICAL
3 3256981 1020 1790570104 LOGICAL
3 3258005 1020 1790570114 LOGICAL
3 3259029 1020 1790570123 LOGICAL
3 3260053 1020 1790570133 LOGICAL
3 3261077 486 1790570142 LOGICAL
95 rows selected.
SQL>
Maybe you are looking for
-
Clc.exe stops running on opening PS CC after 14.1.1 update
After updating to photoshop CC 14.1.1 I get a report as follows Problem signature: Problem Event Name: APPCRASH Application Name: clc.exe Application Version: 0.0.0.0 Application Timestamp: 4c5cc9f6 Fault
-
Getting the following error in Oracle 10g B2B reports, need help where to look into for resolution!
Hi All, I am new to B2B. I am getting following error in B2B Console please suggest what could be the reason and possible steps to resolve: Machine Info: (fcgemapptest05) Description: General Error StackTrace: Error -: AIP-50014: General Error at
-
How can I save a file in CS5 that has been created by a newer version?
How can I save a file in CS5 that has been created by a newer version?
-
Autocomplete to Combobox, where is the LOV...
Apologies for the title of the post... I am hoping I am just missing some minor item, and a push in the right direction will get me working again. A few years back, most likely under Apex 4.0, I started using Jquery - Autocomplete for looking up empl
-
I want to scan a document from my printer to my computer how do i do this
i want to scan a document from my printer to my computer. how do i do this