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)?
Best Answer
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.