备库查询导致的ORA-01110错误及修复(r8笔记第67天)

最近帮助业务部门解决了一个技术问题,因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来,当我看到他们提供的语句,在备 库做了简单的数据评估之后,发现数据量比想象的要多,大概有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. 通过这个案例可以看出,对于数据文件的操作还是需要非常谨慎,对于数据文件的状态监控也应该是运维监控的一个重要参考。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-04-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

关于db link权限分配的苦旅(一) (r7笔记第42天)

昨天接到一个开发的需求,内容看起来非常简单。 申请数据库192.168.1.118:1522:TEST下用户APP_TE_FLOW_128赋予对表testore...

35260
来自专栏杨建荣的学习笔记

一个oracle蠕虫病毒 (r4笔记第60天)

关于计算机病毒,说起来内容就很丰富了,但是第一次听到关于oracle中的病毒时,却感觉很新鲜。这是一个蠕虫病毒,距离现在已经有10年了,但是现在看起来还是能够借...

26330
来自专栏杨建荣的学习笔记

awr性能问题排查第一篇(r3笔记第42天)

对于awr,里面涵盖的内容比较杂,有时候看报告的时候总是不知道该怎么下手。时间长了,可能会有一些阅读习惯或者心得。今天在看大师chris lawson的一篇博文...

30340
来自专栏程序猿

Oracle_12C的新特性

这里我们来领略下Tom眼中的12个特性增强: ? #1 Even better PL/SQL from SQL, 直接在SQL中嵌入PL/SQL对象并运行,猜测...

31690
来自专栏杨建荣的学习笔记

通过shell脚本抓取awr报告中的问题sql(r6笔记第78天)

awr报告中的sql明细部分基本必看的部分,尤其是SQL Order by Elapsed time这个部分,能够很清晰的看到哪些sql语句占用了较多的DB t...

30730
来自专栏杨建荣的学习笔记

关于两个简单问题的分析(r9笔记第10天)

工作中碰到问题当然是见怪不怪了,而处理这些问题也是我们的价值所在。 今天处理了几个看起来比较有意思的小问题,当然究其原因,要不是不规范,要不就是基本功不够扎实。...

31140
来自专栏杨建荣的学习笔记

备库归档删除策略失效的问题分析 (r7笔记第6天)

最近碰到了一个有些奇怪的问题,自己当时排查问题时间紧,没有细细琢磨,今天抽空看了下,终于发现了端倪。 首先是在早晨收到了报警邮件,报警邮件内容如下: ZABBI...

43380
来自专栏数据和云

续:跨平台版本迁移之 XTTS 方案操作指南

运行数据库对比脚本,通过创建 dblink,运行相关的数据库对象比对脚本。这里我们主要比对了存储过程,函数,触发器,试图,索引,表等等。

24240
来自专栏乐沙弥的世界

Oracle expdp 时遭遇ORA-39125 ORA-04063

    数据库在使用DataPump导出时碰到了ORA-39125与ORA-04063。完整的ORA-39125提示是Worker unexpected fat...

14710
来自专栏大内老A

WCF版的PetShop之二:模块中的层次划分[提供源代码下载]

上一篇文章主要讨论的是PetShop的模块划分,在这一篇文章中我们来讨论在一个模块中如何进行层次划分。模块划分应该是基于功能的,一个模块可以看成是服务于某项功能...

263100

扫码关注云+社区

领取腾讯云代金券