共计 4999 个字符，预计需要花费 13 分钟才能阅读完成。
最近帮助业务部门解决了一个技术问题，因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来，当我看到他们提供的语句，在备库做了简单的数据评估之后，发现数据量比想象的要多，大概有 200 万条左右的数据，而业务部门手头有一个 excel 文件，需要和这些数据做一些比对，当然停了下筛选逻辑还蛮复杂，最开始建议他们数据量太大，使用 excel 还是可能出问题，但是业务部门认为应该没有太大的问题，他们会有 excel 中的公式等来处理，想想也有道理，就提供给了他们一个近 40M 的文件。
等到快中午的时候，业务部门找到我说，两个 excel 文件做比对，电脑完全卡住了，还是想问问我看看有没有好的办法，从我的角度来看，这些操作用 sql 语句完全可以胜任，而且数据量更大都不是问题。简单了解了需求之后，和开发的同学确认了业务逻辑，就开始准备环境了，当然思路还是比较常规的，用外部表来实现。
首先通过 excel 来得到需要的几列数据，生成 csv 文件或者文本文件均可。然后在目标数据库服务端创建外部表来读取这些文本数据，同时和相关的表做集合运算，比如 Minus,intersect 之类的操作，即可得到最终的结果。
说起来容易，在实际操作中碰到了一个比较有意思的问题。
在备库中准备做这类的大查询，结果抛出了一个错误。创建的外部表为 linuxidc.temp_tab
select t1.cash,t1.TEST_TRANSACTION_ID ,t2.trade_no,t2.cash from TEST_NEW.TEST_detail t1,linuxidc.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 状态。
linuxidc@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.
通过这个案例可以看出，对于数据文件的操作还是需要非常谨慎，对于数据文件的状态监控也应该是运维监控的一个重要参考。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-04/130295.htm
