【力荐】Exadata火线救援：10TB级数据修复经典案例详解！(2)

最后对所有的文件用dbv做一次校验,有没有物理坏块.

当到了这一步的时候,其实就跟寻常的数据库恢复类似了. 我们同样在open的时候遇到了ORA-1555、ORA-704错误.

记录下我们用到的参数和事件.

event：

隐含参数：

这里比较讨厌的是rollback segments不容易确定,因为你是mounted状态的数据库,连v$rollname都查询不了.

有两个办法来解决：

办法一,用strings去system文件里抓.

办法二,用DUL/AUL/ODU/GDUL等类似工具.相对来说这种方法得到的准确一些

把得出的SYS_UNDO.dmp导入普通用户,去除status为1和2的回滚段(还原段)后放入到上述空着的2个参数.

open的时候可能还会报ORA-1555,需要推进SCN,以upgrade模式open.

推进SCN的方法很多网友也有分享过,度娘或者谷哥都可以.这里需要重点提示后续有需要的小伙伴的是,搞了两下没起来也别灰心.
这次单就推进SCN这块,我们也折腾了好长时间,甚至一度两度打算放弃准备DUL了.

先看看oradebug poke的描述：

那首先是找到SCN的内存地址：

等号后面的值,就是当前显示的SCN了,不过,由于是mount状态,所以显示为0. 将当前的SCN(从v$datafile_header#查)随手加上100万,转为十六进制,推一把看看：

再次查看就能看到SCN的值了：

然后“alter database open uprade”,不断重复尝试…….

此外还用了bbed修改块,还去删除数据字典记录…….

终于,数据库总算open了,数据回来了.

关于更详细的细节,欢迎关注后续DBA+技术沙龙主题.

万幸的是,没有走到最后一步,没有用DUL来抽数据,不然,以这龟速,少说也是一个星期的事情.

DUL和AMDU都是救命的稻草,我们有能力使用,不代表我们一定要去用.而且我们从不在这个时候跟客户谈收费,作为服务商我们坚持救急如救火!而这些救命工具就如同山洞里的核武器,我们希望每个客户都能做好前期规划、维护、备份和容灾,让它们静静地躺着,作为一种威慑手段就好了.

再好的东西,你不关心它,总会出问题的,Exadata也不例外.

摘抄《Exadata专家工具箱》里的几个工具,仅供参考：

sundiag

ExaWatcher

• Diskinfo
• IBCardino
• Iostat
• Netstat
• Ps
• Top
• Vmstat

Exachk

CheckHWnFWProfile

这些命令两周做一次检查还是必要的.

问题发生在别人身上的时候,我们听起来不可思议,觉得别人是不是傻啊,还是懒啊,其实不是,有的时候真是太忙太忙,忙不过来,这时候需要一套工具来帮助大家.

是的,说的就是你.还记得我们昨天的聊天么,你说,他们是不是傻啊,不做监控么,平时不去看么?我说,你要是管理几千个数据库,而你又没有合适的管理工具,一个边缘系统发生这种情况,是在所难免的.

那么什么样的数据库运维管理工具是合适的呢?

• 数据库多维度监控
• 日常运维场景化
• 数据库实时性能分析
• 应用性能追溯

（编辑：ASP站长网）