Oracle 11 rman db restore file corruption

Question

First to mention that I came to the need of asking help after furious research I reattempts for about 3 weeks. I checked previous threads in Oracle community but nothing works for me. I am trying to restore Oracle 11.1.0.7. multi HDD cluster production on single hdd locally on amazon ec2.

Restore is done from full back-up copy I downloaded from ftp location (I have no access to production,export and etc.) just have access to the files, i.e. I am not able to change anyhow export procedure.

So here are my steps in brief (I guess that problem might be in some of them):

rman target /
set DBID ...
startup nomount
RESTORE CONTROLFILE FROM 'file destination'
shutdown;
startup mount;

Catalog the backup files to rman, for all AL and BK files:

catalog backuppiece 'C:/BKUP/AL_2851492942_20151016_893271615_PGQJSFHV_1_1';

Rename all redo files to match my local directory structure

rman:crosscheck backup; Run{
SET UNTIL SEQUENCE 50511;      
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE; 
}


sqlplus sys/sys as sysdba

shutdown immediate; startup mount;
alter database noarchivelog;

Drop the no longer used log files. Drop these in state UNUSED left Active and Inactive. Drop all temp files(they point to other drive letter):

ALTER DATABASE OPEN;
ALTER TABLESPACE mytempspace 
ADD TEMPFILE 'c:\oracle............dbf' SIZE 1G REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

My problem is that on my second query (get) to db through my app I receive:

ORA-01578: ORACLE data block corrupted (file # 64, block # 2559928)
ORA-01110: data file 64: 'C:\ORACLE\ORADATA\mydb\mydbLOBDATA2_1.DBF'
ORA-26040: Data block was loaded using the NOLOGGING option
ORA-06512: at "mydbUSER.POBJECTSTATE", line 78
ORA-06512: at line 1

What I was able to find with validation and it is LOBSEGMENT - Lob_ObjectState and it logically corrupted.

I tried DBMS_REPAIR and with rman advise failure (which suggest to restore my copy from backup - nothing useful).

Since backup are refreshed every week I try with new ones from the next week, again the same problem.

Is there a possibility that the problem starts from export (how can I check this - I do not have access but i may ask db admin to check anything)?

Answer 1

Your only solution for this problem is to take a backup of the datafiles that are hit by a direct load operation, or prevent force_logging operations totally. Force_logging operations may seem like a good idea, performance wise but if you care about your data ..... don't do it.

alter database noforce logging;