Verifying block corruptions 


 


 Check in bdump alert_SID.log  file for any "Errors"
 
 Verify the udump  trace files for "Corrupt","file=" and "blocknum="
 
 file=n is the corrupt datafile and blocknum=nnnn is the corrupt block
 
 If the file no. is more than one, then corruption is more than one file
 
 If the blocknum is more than one block and it is changing with time, 
                then corruption is growing

 Recovering Corrupt block without dataloss 


 
 Check your latest hot back files and restore in some partition
 
 You need archive log files during recovery, restore them from last hot backup date
 
 Shutdown the database
 
 Take a copy of control file
 
 Move only the corrupt "n" file(s) to another location
 
 Restore the needed "n" hot backup file(s) to a good partition.
 
 start the database

  svrmgrl> connect internal;
	svrmgrl> startup nomount;
	svrmgrl> alter database mount;
	svrmgrl> select name,status from v$datafile;
	svrmgrl> alter database rename file '/diks1/.../yz_d01.dbf' to '/disk2/.../yz_d01.dbf';
	svrmgrl> recover datafile '/disk2/.../yz_d01.dbf';
           Apply all the archive log files till "Media recovery complete." statement.
  svrmgrl> alter database open;
          statement processed.
 
 Shutdown are startup the database, take a complete export of the objects which raised errors
      to verify block corruption is still existing.

Tips
      1.  If you issue "Cancel"  or wrong archive log location during recovery,
          Don't panic, issue command "RECOVER DATAFILE 'filename'"  and  proceed.

      2.  You can do reanme of files in in one command
           ALTER DATABASE RENAME FILE 'file1','file2','file3' to 'file1','file2','file3';

      3.  You can issue recovery command for all files in one command
 	    RECOVER DATAFILE 'file1','file2','file3';