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
Similar Messages
-
V$database_block_corruption
hello experts
we has logical failures on our database for which we ran following commands to validate the instance
rman> validate check logical database;
used dbms_repair to cehck the obejct and skip corrupted blocks
we are still getting the same blocks in v$database_block_corruption
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
52 403355 37 7.0566E+10 NOLOGGING
67 393999 49 7.0566E+10 NOLOGGING
86 376770 1 7.0567E+10 NOLOGGING
92 421681 1 7.0567E+10 NOLOGGING
92 420261 1 7.0567E+10 NOLOGGING
Does it mean the blocks are still corrupted
thanxHi;
Please see below thread's Aman post
Re: V$DATABASE_BLOCK_CORRUPTION vs V$BACKUP_CORRUPTION
Regard
Helios -
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. -
Where to find the datafile corruption ?
I wonder, if we can find out the place from where, we can trace out about the name of datafile, which got corrupt and how to recover that file ? I can only see
the alert.log file in that description, but really wich to hear your views.
hare krishna
AlokIf MAXCORRUPT was set high enough during a backup, you can look in V$DATABASE_BLOCK_CORRUPTION for corruption entires. In addition, you could run BACKUP VALIDATE DATABASE and then check V$DATABASE_BLOCK_CORRUPTION. V$BACKUP_CORRUPTION maintains historical records of any corruption.
-
When is information stored in V$BACKUP_CORRUPTION ?
V$BACKUP_CORRUPTION
displays information about corrupt block ranges in datafile backups from the control file. Note that corruptions are not tolerated in the control file and archived redo log backups.
V$DATABASE_BLOCK_CORRUPTION
displays information about database blocks that were corrupted after the last backup.
^^
When is information stored in V$BACKUP_CORRUPTION and when in V$DATABASE_BLOCK_CORRUPTION ?The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run via RMAN.
V$BACKUP_CORRUPTION simply provides a historical record of entries in V$DATABASE_BLOCK_CORRUPTION. -
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.
ThanksThe 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. -
I'm on 9i R2 Patch 7 on a Microsoft Windows Server 2003.
How do you fix data block corruption in a Table?
Is the some way to retrieve the data from the Table drop it then recreate and reimport the data?
or do you have to succumb with restoring the Database from the last known good backup?Hey, you can do the BMR (Block Media Recovery).
Since block corruption is to few subsets of blocks, i.e. a single table, you dont need to restore from the previous valid backup, you can simply do the following to achieve BMR.
Connect to rman and run the following:
run{ backup validate database};
Once the above commend is finishes, exit from RMAN and connect to the database as / as sysdba and use the following view to know the details required for BMR.
select * from V$backup_corruption;
The above queries gives you file# and block# information. Once you have the information do the BMR using following command at the RMAN prompt:
run {blockrecover datafile # block #};
# : indicated the datafile number and block number from the above view.
Let me know if you have any further issues.
You can also use view V$DATABASE_BLOCK_CORRUPTION to view the file# and corrupted blocks information.
Jaffar -
Block corruption - cant restore from backup
Hi,
we have development database 11.2.0.1. There was problem with storage, and as a result there are two corrupted blocks in data files.
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
6 2359942 1 0 FRACTURED
25 1855622 1 0 FRACTURED
I have scheduled weekly full backup and daily incremental backup using EM so now I want to use rman to perform media recovery on corrupted blocks. However rman says there is no backup for affected data files (see below)
RMAN> RECOVER CORRUPTION LIST;
Starting recover at 03-NOV-12
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00006
channel ORA_DISK_1: reading from backup piece /opt/oraBackup/rman/i2npb3o9_1_1
channel ORA_DISK_1: piece handle=/opt/oraBackup/rman/i2npb3o9_1_1 tag=BACKUP_FULL_110212103009
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:42:35
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00025
channel ORA_DISK_1: reading from backup piece /opt/oraBackup/rman/i9npbd5e_1_1
channel ORA_DISK_1: piece handle=/opt/oraBackup/rman/i9npbd5e_1_1 tag=BACKUP_FULL_110212103009
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:16:35
failover to previous backup
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/03/2012 11:59:29
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 25 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
I dont understand this, because the backups are performed weekly and daily and all files are at their proper location. When I check the EM backup reports, I see COMPLETED for every weekly and daily backup.
Anyone please could suggest how to repair the blocks from backups ?Hi people, I am back to this issue. I have found this in the database
SQL> select * from v$backup_corruption;
RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MAR CORRUPTIO
1 796949262 796948233 9293 1 6 2359942 1 0 NO CORRUPT
2 796953328 796949174 9300 1 25 1855622 1 0 NO CORRUPT
3 797035604 797034635 9318 1 6 2359942 1 0 NO CORRUPT
4 797039692 797035556 9325 1 25 1855622 1 0 NO CORRUPT
5 797134390 797121030 9343 1 6 2359942 1 0 NO CORRUPT
6 797137228 797134397 9368 1 25 1855622 1 0 NO CORRUPT
7 797739951 797725854 9590 1 6 2359942 1 0 NO CORRUPT
8 797744507 797739957 9597 1 25 1855622 1 0 NO CORRUPT
9 798340269 798330633 9794 1 6 2359942 1 0 NO CORRUPT
10 798343497 798340270 9801 1 25 1855622 1 0 NO CORRUPTSo the backup contains corrupted blocks. Right ? Older backups are already gone because of retention policy.
I have set up the backup using Enterprise Manager - Schedule Backup.
What I need to know is how to avoid taking backup with corrupted blocks in future. I need such backup to fail.
Thank you for advices and regards. -
Corrupted blocks are shown after runnıng dbv
but I cant see them from the
V$backup_corruption
v$database_block_corruption;
why?Was dbv supposed to mark the block corrupt somewhere?
The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run. -
Block corruption recovery!!
Hi. all.
I am testing a recovery in the event of block corruption.
As far as I know, the solution to block corruption is as followings:
1. BlockRecover command (RMAN)
2. drop the table and import from backup dump file
3. DBMS_REPAIR package
4. complete recovery from online full backup
My question is whether No. 4 is possible or not.
step 1 : bring the datafile offline
step 2 : restore the datafile from the last backup(online backup)
step 3: recover the datafile, applying archive logs and online redo logs
step 4 : bring the datafile online
The above steps are enough for block corruption recovery?
I need to make a document about block corruption issue, but
I have no experience of recovering block corruption.
Thanks in advance.
Best Regards.If few blocks are corrupted, it is advisable to run the BMR (block media recover, staring with 9i). This option provides the availability of other data present in datafile.
Option 4 is okay when most of the data block in a datafile got corrupted.
To know how many blocks got corrupted in the datafile, run the following:
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
SELECT * FROM V$COPY_CORRUPTION;
SELECT * FROM V$BACKUP_CORRUPTION;
You need to look into corrution_type and blocks columns in the v$database_block_corruption view as it gives the reason for block corruption and number of blocks are corrupted in a datafile.
Jaffar -
Error in Database backup using RMAN.
Hi
While taking full online backup using RMAN i got the following error.
ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/DEV/sapdata2/dev640_6/dev640.data6
Please help me how to resolve this issue.Hi,
Please perform DBverify Job and Also analyze the alert<SID>.log file for your Database to get more information about such logical or physical corruption. You may require Block level recovery for the complained DB Files. Please refer this useful document " [Early Detection and Correction of Data Block Corruptions Using RMAN |http://www.ioug.org/client_files/members/select_pdf/04q4/RMAN.pdf]" and share the same with your Oracle DBA.
You can execute the following commands to get information about corrupted block(s), if its there.
select * from v$backup_corruption;
select * from v$database_block_corruption;
Regads,
Bhavik G. Shroff -
Hi there,
I have an Oracle 10.2.0.3 DB running on Solaris 10 update 5, SPARC 64-bit.
I recently noticed that there are a number of files in my backupsets that have been flagged as corrupt:
<pre>
SQL> select recid, stamp, set_count, file#, marked_corrupt, media_corrupt, logically_corrupt
2 from v$backup_datafile
3 where checkpoint_change# >= 2215146265248
4 and (marked_corrupt > 0 or media_corrupt > 0 or logically_corrupt > 0);
</pre>
<pre>
RECID STAMP SET_COUNT FILE# MARKED_CORRUPT MEDIA_CORRUPT LOGICALLY_CORRUPT
99977 746035916 15992 0 2011 317 1
99978 746132372 15998 0 2011 318 0
99979 746153962 15999 0 2011 319 0
</pre>
File#=0 means that this is corruption is on the control file.
I checked a couple other views for more information, but I can't find anything about this:
<pre>
SQL> select * from v$backup_corruption;
no rows selected
SQL> select * from v$database_block_corruption;
no rows selected
</pre>
Can anyone please explain what this information really means and how bad of a situation this is? What methods are available to resolve this issue?Thanks for answering so quickly.
There are 3 copies of the controlfile available. They all have the same size & timestamp:
<pre>
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control01.ctl
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control02.ctl
-rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control03.ctl
</pre>
DB is operating normally. We did have problems with our RMAN backups (incremental level 0) over this past weekend to our external tape system, which led me down this path.
There are no errors in the alert log.
I am not completely convinced my control files are corrupted though. What would be an easy way to check for corruption without taking DB down? -
Hi all,
here is my situation.
This instance is our Production Instance.
The setup is:
10.2.0.3 on Redhat
After analyzing with rman - Backup validate check logical database; - I got the following result:
select *
from v$database_block_corruption
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
3 23704 1 124547349 LOGICAL
select *
from v$backup_corruption
RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MARKED_CORRUPT CORRUPTION_TYPE
1 636798080 636796682 169 1 3 23704 1 124547349 YES LOGICAL
The next step:
SELECT tablespace_name, relative_fno,
segment_type, owner, segment_name, partition_name
FROM dba_extents
WHERE file_id = 3
AND 23704 between block_id and block_id + blocks -1;
TABLESPACE_NAME RELATIVE_FNO SEGMENT_TYPE OWNER SEGMENT_NAME PARTITION_NAME
SYSAUX 3 TABLE SYSMAN MGMT_CURRENT_AVAILABILITY
So it seems my corruption is in a table named MGMT_CURRENT_AVAILABILITY under the sysman schema.
That makes sense since I actually cannot schedule anything with EM.
I cannot select * that table nor export it. I always got an Invalid ROWID error.
What is the safest way to correct my problem?
emca -deconfig dbcontrol db -repos drop
then
emca -config dbcontrol db -repos recreate
Is it safe?
TIAHi, the options will can be:
1.- Use the BLOCKRECOVER for try recover the bad data blocks, please see the next link for get more information about how use this command.
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta010.htm#sthref213
2.- Recreate the EM schema with.
emca -deconfig dbcontrol db -repos drop
then
emca -config dbcontrol db -repos recreate
Please let me know if you need anything else.
Regards. -
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> -
We are getting more frequent Block corruption alert from our production RAC (2 node) db.
if we use dbv utility to check block corruption, everything looks normal and if we check following dictionary views, we could not find any details .
GV$BACKUP_CORRUPTION, GV$COPY_CORRUPTION, GV$DATABASE_BLOCK_CORRUPTION
So do we have block corruption ? what we can do to avoid getting such alerts?Hi,
>>We are getting more frequent Block corruption alert from our production RAC (2 node) db.
What exactly error are you getting from alert log file?
>>if we use dbv utility to check block corruption, everything looks normal and if we check following dictionary views, we could not find any details
In fact, these views above displays information about corruptions in datafile and/or datafile copy backups from the control file. I think this is the wrong place to look at. In addition, there are many possible causes of a block corruption including bad IO, hardware / firmware, OS problems, Oracle problems ... Are you able to determine which database objects have affected by this problem? Have you tried take a look at some trace files?
Cheers
Legatti
Maybe you are looking for
-
It comes up with this thing after authorisation, 'This computer is already authorised. Including this one, you have authorised 2 computers out of your available 5.' This is ******* me off. I want to play the music I freaking payed for.
-
Firefox not starting after 3.6.6 upgrade ubuntu 10.04
These are the last few entries in the firefox strace log. Firefox never opens it just hangs like this every time. I have uninstalled and reinstalled. I have tried firefox -p for new profile still the same. strace firefox wait4(-1, [ ], 0, NULL) = 169
-
BPC 10.0 NW - How can I check & ensure I am the BPC administrator?
Dear All, I am a BPC developer and have recently assumed BPC admin responsbility. I am told that I am having BPC admin rights. But, I can see ONLY ONE environment and it seems there are few more environments that exist in the BPC server. My understan
-
I have and apple account but upon ordering prints i cannot login it wants a new account
i have an apple account with valid password, works for itunes and everything else but aperture wants me to create another account to order books/prints any help appreciated
-
Defaulting transportation zone value while creating the consumer in shop
Dear Experts i have a requirement where i have to default the transportation zone value as "0000000001". when ever a new consumer is created in the webshop when it flows to r/3 it must contain trasnportation zone value as "0000000001"(defaulted) coul