备库查询导致的ORA-01110错误及修复-CSDN博客

   最近帮助业务部门解决了一个技术问题，因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来，当我看到他们提供的语句，在备库做了简单的数据评估之后，发现数据量比想象的要多，大概有200万条左右的数据，而业务部门手头有一个excel文件，需要和这些数据做一些比对，当然停了下筛选逻辑还蛮复杂，最开始建议他们数据量太大，使用excel还是可能出问题，但是业务部门认为应该没有太大的问题，他们会有excel中的公式等来处理，想想也有道理，就提供给了他们一个近40M的文件。
   等到快中午的时候，业务部门找到我说，两个excel文件做比对，电脑完全卡住了，还是想问问我看看有没有好的办法，从我的角度来看，这些操作用sql语句完全可以胜任，而且数据量更大都不是问题。简单了解了需求之后，和开发的同学确认了业务逻辑，就开始准备环境了，当然思路还是比较常规的，用外部表来实现。
    首先通过excel来得到需要的几列数据，生成csv文件或者文本文件均可。然后在目标数据库服务端创建外部表来读取这些文本数据，同时和相关的表做集合运算，比如Minus,intersect之类的操作，即可得到最终的结果。
    说起来容易，在实际操作中碰到了一个比较有意思的问题。
在备库中准备做这类的大查询，结果抛出了一个错误。创建的外部表为jeanron.temp_tab
select t1.cash,t1.TEST_TRANSACTION_ID ,t2.trade_no,t2.cash from TEST_NEW.TEST_detail t1,jeanron.temp_tab t2 where req_time >= to_date('2016-03-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and req_time < to_date('2016-04-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and status <> '1' and pay_way_channel_code in ('44','45','46','15','16','17','18','19','91','93','94','146','147','148','149','150','151','159')
*
ERROR at line 1:
ORA-00376: file 21 cannot be read at this time
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
看问题提示无法读取21号文件，根据错误可以基本判断出来应该是文件在offline状态。
查看数据文件的状态，可以看到21号文件TEST_new_index04.dbf 目前是在RECOVER状态。

jeanron@TEST> select file_name,status,online_status from dba_data_files;
FILE_NAME                                             STATUS    ONLINE_
-------------------------------------------------------- --------- -------
/U01/app/oracle/oradata/TEST/TEST_new_data01.dbf         AVAILABLE ONLINE
/U01/app/oracle/oradata/TEST/system01.dbf                AVAILABLE SYSTEM
...
/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf        AVAILABLE RECOVER
这个问题看起来比较奇怪，查看主库中的数据文件状态，都已经是online，说明在过去的某一个时间出现过一个相关的小问题。
对于这类问题，一个比较快捷的解决方法就是从主库生成备库控制文件，然后启动数据库到Mount阶段即可。
但是这一次还是出了差错，把生成的备库控制文件拷贝到备库替换之后，重启数据库，dg broker报了下面的错误。
DGMGRL> show configuration;
Configuration
Name:                TEST
Enabled:             YES
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
    TEST   - Primary database
    sTEST4 - Physical standby database
    sTEST2 - Physical standby database

Current status for "TEST":
Warning: ORA-16607: one or more databases have failed
查看alert日志，报出了ORA-01110的错误。
RFS[1]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2016_04_12/o1_mf_1_8158_cjs8mqfp_.arc'
Tue Apr 12 15:24:33 2016
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT NODELAY
Tue Apr 12 15:24:33 2016
Attempt to start background Managed Standby Recovery process (TEST)
MRP0 started with pid=23, OS id=10683
Tue Apr 12 15:24:33 2016
MRP0: Background Managed Standby Recovery process started (TEST)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1110
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
MRP0: Background Media Recovery process shutdown (TEST)
根据错误可以看出应该是文件校验的时候有问题，creation SCN校验出现了问题。
而这个时候查看dg broker中的verbose明细信息，显示这个备库目前的状态为：
Current status for "sTEST2":
Error: ORA-16766: Redo Apply unexpectedly offline
对于这个问题，要想修复SCN的部分，有一个策略就是BBED,但是线上库，而且考虑这种风险，与其BBED修改，我更愿意保险一些重建备库。
不过重建备库是最后的方案，我来看看有没有其它的方案。
这个数据文件通过查看明细信息发现已经处于这种状态很久了，也就意味着这部分信息在控制文件中已经无法保留，数据文件的SCN还是很早之前，比如半年前的SCN情况。这个时候如果尝试做recover肯定是不现实的，归档保留也不会那么久。不过因为是备库，所以这个问题还好办一些，那就是从主库还原恢复即可。
这个数据文件大概有5G左右，目前使用率在60%，rman备库数据文件大概有3G左右。
所以拷贝数据文件的备份集到备库之后，使用catalog start with的方式进行还原。
RMAN> catalog start with '/U01/app/oracle/temp';
using target database control file instead of recovery catalog
searching for all files that match the pattern /U01/app/oracle/temp
List of Files Unknown to the Database
=====================================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
RMAN> restore datafile 21;
Starting restore at 12-APR-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2976 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00021 to /U01/app/oracle/oradata/TEST/TEST_new_index04.dbf
channel ORA_DISK_1: reading from backup piece /U01/app/oracle/temp/full_1804_908984436_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/U01/app/oracle/temp/full_1804_908984436_1 tag=TAG20160412T154036
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
Finished restore at 12-APR-16

这个时候不用重启备库，数据文件的SCN就自然推进到了新的值，再次查看数据文件的状态就变为了ONLINE.
通过这个案例可以看出，对于数据文件的操作还是需要非常谨慎，对于数据文件的状态监控也应该是运维监控的一个重要参考。