DG环境主库丢失归档情况下数据文件的恢复

0    94    1

👉 本文共约26624个字,系统预计阅读时间或需101分钟。

【故障处理】DG环境主库丢失归档情况下数据文件的恢复

前言部分

导读和注意事项

各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,\~O(∩_∩)O\~:

① BBED的编译

② BBED修改文件头让其跳过归档从而可以ONLINE(重点)

③ OS命名格式转换为ASM的命名格式

④ DG环境中备库丢失数据文件的情况下的处理过程(重点)

⑤ 数据文件OFFLINE后应立即做一次RECOVER操作

⑥ BBED环境中kscnwrp的使用

⑦ 查询表空间的大小,表空间大小为空,数据文件大小为空的情况

故障分析及解决过程

故障环境介绍

项目源库DG库
db 类型RACRAC
db version11.2.0.3.711.2.0.3.7
db 存储ASMASM
OS版本及kernel版本AIX 64位 7.1.0.0AIX 64位 7.1.0.0
关系主备库为RAC+RAC的物理DG环境

故障发生现象及报错信息

今天查询一套DG环境的表空间大小的时候,发现一个表空间的返回值为空,很奇怪,起初我以为是自己的脚本问题,可是这个脚本是自己写的,而且用了很长时间的了,还花了几分钟的时间又仔细审核了一下脚本,没发现有什么不对的地方。

查询表空间大小的脚本:

结果如下图:DG环境主库丢失归档情况下数据文件的恢复

因为表空间是ONLINE的,若是OFFLINE的话,结果自然为空,由于只有一个数据文件,那就看看数据文件的状态:

SELECT * FROM v\$datafile d WHERE d.FILE#=64;

DG环境主库丢失归档情况下数据文件的恢复

果然数据文件是64,数据文件为OFFLINE状态,而且去备库查看的时候数据文件也是OFFLINE的。这里有一个LAST_TIME需要注意,日志为2015年4月21号,而现在都2016年9月21号了,看来是很久很久很久没有用这个数据文件了。好吧,很久没有写BLOG了,今天就以这个案例为主,说说其修复过程把。

健康检查报告

运行

用自己的健康检查报告看一下能否发现这个问题呢?

DG环境主库丢失归档情况下数据文件的恢复

DG环境主库丢失归档情况下数据文件的恢复

跑完之后,生成的报告在当前目录,报告的目录大概如下所示:

巡检服务概要
数据库总体概况数据库基本信息数据库大小资源使用情况组件和特性
参数文件所有的初始化参数关键的初始化参数隐含参数spfile文件内容Statistics Level
表空间情况表空间状况信息闪回空间使用情况临时表空间使用情况Undo表空间使用情况表空间扩展状况
数据文件状况控制文件../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#rollname_all../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
ASM磁盘监控ASM磁盘使用情况ASM磁盘组使用情况ASM磁盘组参数配置情况ASM实例../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
JOB情况作业运行状况数据库job报错信息../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
巡检服务明细
RMAN信息RMAN备份状况RMAN配置情况RMAN所有备份RMAN所有备份详情控制文件备份
spfile文件备份RMAN归档文件备份数据库闪回../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#log_10_ratefenxi../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#log_10_ratefenxiqiehuan
归档信息归档日志设置归档日志生成情况归档日志占用率近7天日志切换频率分析每天日志切换的量
日志组大小../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#archive_log_rate../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#log_10_ratefenxi../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#log_10_ratefenxiqiehuan../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#logsize
SGA信息SGA使用情况SGA配置信息SGA建议配置SGA动态组件PGA TARGET 建议配置
文件IO信息文件IO分析文件IO时间分析全表扫描情况排序情况../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#sorts
SQL监控逻辑读TOP10的SQL物理读TOP10的SQL执行时间TOP10的SQL执行次数TOP10的SQL解析次数TOP10的SQL
版本TOP10的SQL语句内存TOP10的SQL语句DISK_SORT严重的SQL垃圾SQL之RUNNING_11G垃圾SQL之RUNNING_10G
LAST快照中SQL情况LAST快照中执行时间最长SQL执行时间最长SQL执行时间最长的SQL报告../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
闪回归档闪回归档配置开启了闪回归档的表闪回归档空间../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
DG库DG库配置情况DG库运行情况主库DG进程主库standby日志备库日志应用情况
数据库安全
数据库用户数据库用户一览拥有DBA角色的用户拥有SYS角色的用户角色概况密码为系统默认值的用户
整个用户有多大近一周登录错误的用户../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
系统表空间用户SYSTEM为缺省表空间的用户SYSTEM为临时表空间的用户系统表空间上的对象../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
数据库审计审计参数配置审计表情况DB中所有审计记录../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
数据库对象
段情况对象汇总段的汇总体积最大的10个段扩展最多的10个段LOB段
不能扩展的对象扩展超过1/2最大扩展度的对象Undo 段表空间所有者../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#partsum100
表情况行链接或行迁移的表超过10W行无主键的表无数据有高水位的表../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
分区表情况表大小超过10GB未建分区分区最多的前10个对象分区个数超过100个的表../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
无效对象无效的对象无效的普通索引无效的分区索引无效的触发器../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
索引情况索引个数超过5个的表大表未建索引组合索引与单列索引存在交叉位图索引和函数索引外键未建索引
大索引从未使用索引列个数大于3索引高度大于3索引的统计信息过旧../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
并行度表带有并行度索引带有并行度../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
其他对象告警日志数据库目录回收站情况数据库链路(db_link)外部表
所有的触发器序列cache小于20物化视图type数据泵
数据库性能分析
AWRAWR统计AWR参数配置状况数据库服务器主机的情况AWR视图中的load profile热块
最新的一次AWR报告../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#pga_max_spid../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#buffer_cache_ratiosss../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#spid_completeinfo
ASHASH快照状况最新的一次ASH报告../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#statics_gatherfla_tmptable../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
ADDM最新的一次ADDM../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#ASH_new_lastone../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#statics_gatherfla_tmptable../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
统计信息统计信息是否自动收集需收集统计信息的表被收集统计信息的临时表../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
会话会话概况会话状态一览(当前)历史ACTIVE会话数登录时间最长的10个会话超过10小时无响应的会话
提交次数最多的会话CPU或等待最长的会话../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#look_lock_whowho../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#pga_max_spid../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#buffer_cache_ratiosss
查看LOCK锁情况查看谁锁住了谁游标使用情况并行进程完成情况../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#spid_completeinfo
内存占用查询共享内存占有率PGA占用最多的进程命中率../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#wait_event_history
其它等待事件OLAPNetworkingReplication../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
健康检查结果
健康检查结果健康检查结果健康检查过程中脚本产生的错误../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#../../boc/DB_healthcheck_by_lhr_22.188.188.11_ORAIPPS_1_11.2.0.3.0_20160920125114.html - tablespaces_info#
概况

先看看数据库的概况:

DG环境主库丢失归档情况下数据文件的恢复

1级告警:数据文件OFFLINE

再看看,健康检查的结果:

DG环境主库丢失归档情况下数据文件的恢复

有2个地方很重要,1个数据文件有OFFLINE的,第二个是序列的CACHE值小于20,并且已经有enq: SQ - contention等待事件的发生了,说明比较严重,应该修改其cache值。我们点击到相应的位置可以查看细节。

可以看到是64号文件是OFFLINE状态的。

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

DG环境主库丢失归档情况下数据文件的恢复

2级告警:序列问题

另外,我们看看报告中提到的序列等待问题,可以看到有6个序列的cache值设置有问题,已经导致了会话阻塞了,这部分的cache值强烈建议修改,修改语句在报告中也已经给出。

DG环境主库丢失归档情况下数据文件的恢复

2级告警:告警日志问题

DG环境主库丢失归档情况下数据文件的恢复

告警日志问题不是很大,可以忽略。

4级告警:无效对象

DG环境主库丢失归档情况下数据文件的恢复

无效对象也可以修改一下,报告中提供了具体的脚本。

好了,报告不多看了,今天的主题是如何修复那个OFFLINE的数据问题,报告的脚本内容可以私聊我。

故障分析及解决过程

因为是DG环境,所以首先我们来恢复主库,然后再修复备库的文件问题。

可以看到要恢复64号文件需要的是1128号归档日志,从之前的查询我们也知道日志最后一次访问是2015年4月21,而现在系统的归档号为1W多了:

SELECT * FROM v\$log d WHERE d.STATUS='CURRENT' ORDER BY thread#;

DG环境主库丢失归档情况下数据文件的恢复

SELECT a.FILE#, a.NAME,a.CHECKPOINT_CHANGE#,a.LAST_CHANGE#,status FROM v\$datafile a;

SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status FROM v\$datafile_header a;

DG环境主库丢失归档情况下数据文件的恢复

那目前是数据文件OFFLINE,而归档文件又丢失了,如果想把该文件ONLINE,我们必须采用BBED来推进数据文件的SCN号到最近的日志号才可以。有关该部分的理论知识可以参考: 【BBED】丢失归档文件情况下的数据文件的恢复:http://blog.itpub.net/26736162/viewspace-2079337/

这里我们依然采用BBED来修复该问题。

注意:由于我们的环境是DG环境,所以先把备库的监听器停掉,以免恢复的过程中,主库生成的日志传递到备库,而主库日志被删除后,修复该文件就又得往前推进了,所以先把备库的监听停掉,确保主库的日志不被删除。

接下来就可以做恢复操作了。

修复主库的OFFLINE文件

首先,64号文件当前的SCN号1764555149,我们需要将其修改为15760391176,而日志号也需要转换为11087号,这些都需要转换为十六进制,如下:

692cf98d和后边BBED查询出来的数据文件头的结果一致。

BBED修改文件头推进SCN号
编译BBED

首先准备BBED的环境,编译BBED,将以下4个文件拷贝到Oracle的相关的目录:

DG环境主库丢失归档情况下数据文件的恢复

DG环境主库丢失归档情况下数据文件的恢复

注意:文件我已上传到云盘,可以去http://blog.itpub.net/26736162/viewspace-1624453/下载。

接下来我们编译BBED:

修复文件头的scn号

编译完成后可以使用BBED了:

修复数据文件头的序列号

要想跳过归档还需要数据文件头块的rba。它由seq#、log block#、偏移量(固定为16)组成,决定了数据文件从哪个归档日志的哪个位置开始应用归档。Rba位于数据文件头块偏移量500处开始连续的12个字节,有关RBA的理论知识参考:http://blog.itpub.net/26736162/viewspace-2079337/

修复完毕,BBED的任务已经完成。

下边将文件从文件系统拷贝到ASM中:

DG环境主库丢失归档情况下数据文件的恢复

此时再次查询表空间的占用情况,已经可以看到了TBS101的大小了:

DG环境主库丢失归档情况下数据文件的恢复

接下来创建一个表,看看表空间是否正常:

再次查看表空间大小:

DG环境主库丢失归档情况下数据文件的恢复

表空间占用从原来的11M到现在的63M,正常了。

修改主库的64号文件名称为ASM格式

表空间恢复了,但是文件名称还是a.dbf,接下来我们修改a.dbf为ASM的命名格式:

OK,成功!主库修复完毕,接下来就剩下备库了。

修复备库的OFFLINE文件

查看备库的文件情况,发现64号文件依然处于OFFLINE状态。

虽然可以开启实时应用进程,但是64号文件依然不能ONLINE,因为现在的日志号已经到了1W多了,而64号文件的日志号却还在1K多,这个用日志必然不能恢复了,因为日志早不存在了嘛,难道我又得用BBED?不!!!这里我们可以从主库拷贝数据文件过来,且往下看。。。

主库用CONVERT命令备份64号文件:

在备库上转换文件为ASM格式:

备库上进行重命名操作,若是备库上64号文件被删除了,我们此时也可以先重建64号文件:

可以看到64号文件有了,下边进行重命名,修改为我们从主库拷贝过来的64号文件:

文件在使用,不能进行重命名,该库是RAC库,我们先关闭DG,启动到MOUNT状态后再重命名:

此时查看告警日志,很欣慰看到了12918日志过来了:

最后我们重启备库的2个节点:

而数据库中64号文件已经正常了:

最后不要忘记执行:ALTER SYSTEM SET standby_file_management='AUTO' SID='*';将standby_file_management参数修改为AUTO。

环境修复之后的反思

结论:数据文件OFFLINE之后必须要做的一件事就是紧接着立刻执行一次RECOVER操作。

一个数据文件OFFLINE为啥修复起来这么麻烦呢?就是因为归档丢失了,但是若是我们刚开始将数据文件OFFLINE之后若能立刻执行一次RECOVER操作的话,不管中间过了多久,归档丢失了多少,最后ONLINE数据文件的时候都会直接ONLINE起来数据文件而不用做RECOVER操作。废话不多说,我们且做个实验。

项目source db
db 类型单实例
db version11.2.0.3.4
db 存储ASM
OS版本及kernel版本AIX 64位 7.1.0.0

数据文件OFFLINE后没有立刻做RECOVER操作

数据文件OFFLINE后立刻做一次RECOVER操作

实验结束,所以得养成习惯,若做了数据文件的OFFLINE操作后需要接着执行一次RECOVER操作,这样以后想啥时候ONLINE就啥时候ONLINE了

总结

  1. 有关BBED的一些理论知识参考:http://blog.itpub.net/26736162/viewspace-2079337/
  2. 数据文件做OFFLINE后需接着执行一次RECOVER操作
  3. 最后不要忘记执行:ALTER SYSTEM SET standby_file_management='AUTO' SID='*';将standby_file_management参数修改为AUTO
  4. 该故障过程可以进行模拟实验,读者可以在自己的测试环境或虚拟机环境进行实验,实验操作很重要

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

1 × 5 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部