最近帮助业务部门解决了一个技术问题，因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来，当我看到他们提供的语句，在备库做了简单的数据评估之后，发现数据量比想象的要多，大概有200万条左右的数据，而业务部门手头有一个excel文件，需要和这些数据做一些比对，当然停了下筛选逻辑还蛮复杂，最开始建议他们数据量太大，使用excel还是可能出问题，但是业务部门认为应该没有太大的问题，他们会有excel中的公式等来处理，想想也有道理，就提供给了他们一个近40M的文件。
等到快中午的时候，业务部门找到我说，两个excel文件做比对，电脑完全卡住了，还是想问问我看看有没有好的办法，从我的角度来看，这些操作用sql语句完全可以胜任，而且数据量更大都不是问题。简单了解了需求之后，和开发的同学确认了业务逻辑，就开始准备环境了，当然思路还是比较常规的，用外部表来实现。
首先通过excel来得到需要的几列数据，生成csv文件或者文本文件均可。然后在目标数据库服务端创建外部表来读取这些文本数据，同时和相关的表做集合运算，比如Minus,intersect之类的操作，即可得到最终的结果。
说起来容易，在实际操作中碰到了一个比较有意思的问题。
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.
通过这个案例可以看出，对于数据文件的操作还是需要非常谨慎，对于数据文件的状态监控也应该是运维监控的一个重要参考。