标签归档:dul

使用DUL和ODU抽取Exadata上的oracle数据库(抽取磁盘上的数据文件)

之前研究过dul和odu,发现不能识别磁盘,当时犯了一个错误,因为普通环境(非exadata环境),都是在主机上运行扫描磁盘的工作,因此我之前也在exadata的主机上扫描磁盘,发现不行,具体参见: 在Exadata上,为什么 DUL 和 ODU不能读取ASM数据库的数据,但是Kfed却可以? 今天在exadata的存储节点(cell节点)上配置了一下,发现dul和odu都可以直接扫描磁盘,以后有exadata上oracle数据库损坏时,请联系我,O(∩_∩)O哈哈 具体测试如下: 这里我使用control+C终止了,因为磁盘太大了,扫描时间太久,上面的信息已经可以证明,至少可以扫描 至于normal external等其他问题,以后再说。 扫描文件具体如下: 这里 IDX_DATA1.dat 就是dul扫描出来的一些信息,之后使用命令抽成文件就依据这些。 再看看ODU: 这里报错是因为cell上磁盘空间很小,稍微一折腾就满了(存放ODU抽取文件的是根,100%了): 先别急删除,进去看看数据; 可以看到,odu也抽出了数据, 并且,可以看到,已经抽取了几个dbf的数据文件。

发表在 ASM, backup&recovery, DUL ODU, Exadata | 标签为 , , , | 留下评论

oracle一些块损坏和常见数据库损坏的相关概念和处理

最近帮朋友做了一个公开课(大概2小时吧),大概介绍了一下oracle一些块损坏和常见数据库损坏的相关概念和处理。 这里谈到的东西很少,很多内容细讲都是一门学问,我这里介绍的只是大概的概念,冰山一角。对于oracle大牛们来说,不算是什么,O(∩_∩)O哈哈~ 下周打算给公司的同事们介绍一下。 目前pdf可以下载了Oracle常见错误处理-lunar 后续朋友整理好录音等东西,也会上传到这里,与你共勉,请多指教 :)。 本次公开交流的内容已经放到优酷了:

发表在 backup&recovery, ORA-600/7445 | 标签为 , | 留下评论

global_name为空导致的数据库不能open—–使用DUL修复

GLOBAL_NAME和props$对象介绍 global_name为空导致的数据库不能open—–使用gdb修复(中断oracle启动的部分监测功能) global_name为空导致的数据库不能open—–使用dd修复(使用dd拷贝块的方式) global_name为空导致的数据库不能open—使用BBED修复(bbed恢复update的数据) 这篇为第3种解决 global_name 为NULL导致数据库不能启动的方法。 即,使用DUL来直接修改一个block内部的数据的方法。 模拟损坏,将global_name置空: 那么如何定位到是哪一个block呢? 答案是N中方法: (1)使用ODU定位这行记录的dba地址 (2)对比其他大版本相同的正常库的相同行的数据 (3)查看报错的trace,找到改行数据的和block 。。。。。。 我们这里使用第二种,查看其他相同版本数据库的信息。具体的方法在第一篇《GLOBAL_NAME和props$对象介绍》 中已经介绍了,这里不再赘述。 首先报错的数据库的alert.log信息如下: 可以看到,当前global_name已经被置空了: 现在修改 修改后的数据如下: 直接启动数据库:

发表在 DUL ODU | 标签为 , , | 留下评论

DUL第二篇——使用DUL抽取dmp文件内容

dul常用命令: DUL> unload database ; DUL> unload user ; DUL> unload table ; DUL> scan database; DUL> scan tables; 记录一下测试表的记录数目: 其余的配置参数,参考第一篇DUL 第一篇 —— DUL是什么? 启动DUL,然后直接执行unpump header,之后就可以抽取了: 这里我们看到17634 行记录全部抽取出来了,如果你想测试的更好玩,可以dd掉其中的一部分数据,然后测试看dul怎么工作。 然后直接导入数据,就这么简单,O(∩_∩)O哈哈~ 这里我们看到全部的17634 行数据都导入表中了。

发表在 DUL ODU | 标签为 , | 2 条评论

DUL 第一篇 —— DUL是什么?

最近打算陆续研究一些DUL的东西,这个在互联网上已经有太多了,我本人用的不多,主要是确实很多时候用不上(运维做得好,这些其实都几乎用不上……) 不过这些东西涉及了很多对于Oracle的运行机制和原理的理解,玩玩还是很有意思的 :) DUL是Oracle Internal工具,专供Oracle Support使用,请勿自行在工作环境操作,否则后果自负!! 第一篇 DUL是什么?

发表在 DUL ODU | 标签为 | 留下评论

浅谈Oracle非常规恢复

一直以来,类似非归档无备份的数据库损坏,或者备份不可用,或者用备份恢复因为时间太长或者空间限制等等原因制约,非常规恢复一直是我们不能扔掉的救命稻草,在这个方面我并不擅长,但是一直都很喜欢。 记得2001年前后,我第一次有兴趣想要认真学习一下Oracle(以前做开发相关比较多,菜鸟dba),在还没有了解Oracle备份恢复的机制时,忘记为什么首先接触了Oracle 817的Standby,一周内完整的读了一遍文档,动手搭建了两个,并记录在ITPUB和我自己的blog上,很有成就感,而那时,我还没有意识到,其实Standby 的本质就是数据库的备份和恢复的完美结合。 后来有机会作为dba参加一个公司(在当时没觉得公司小,但是只有我一个菜鸟dba,O(∩_∩)O哈哈~)的一个海外项目,是做一个3节点Oracle 817 OPS 克隆数据库的事情,当时我还不熟悉RMAN,使用dd裸设备的方式完成了任务。这个项目之后,我开始迷上Oracle的备份和恢复,并且开始玩rman了。 迄今为止,我还是认为数据库备份恢复是学习Oracle的最佳入口,因为很多时候你可以方便的模拟场景,并研究恢复,在一个个案例中,学习和了解更多internal的原理。当然,任何时候官方文档都是第一步,没有这个基础,很多都如同空中楼阁。 还有一点,一个好的架构设计、备份恢复策略和灾备设计都是最好的选择,这个是毋庸置疑的。 但是中国大量D版客户,尤其是小客户中太多情况下是没有专业的设计,出了问题,非常规恢复的手段就是救命稻草了。 下面的ppt就是去年一个客户在备份不可用的情况下,花“巨资”请人做了非常规恢复后,找我们去做的一次交流,客户要求的主题就是“非常规恢复”: 浅谈Oracle非常规恢复-lunar

发表在 backup&recovery, Internal | 标签为 , , , , , , | 留下评论

在Exadata上,为什么 DUL 和 ODU不能读取ASM数据库的数据,但是Kfed却可以?

普通的dul在exadata上是不能读取 cell 节点的数据的: 这里很清晰看到DUL报错了“OS error 2: No such file or dire”和“DUL: Error: “, 12″,由于篇幅关系,这里我就不贴前台DUL的报错界面了,这个trace已经很清晰了。 那么,我猜ODU也是同样的采用传统的read和write的方式读取数据的,跟踪一下,主要内容如下: 我们看到,ODU读取了配置文件:“write(1, “load asm disk file ‘asmdisk.txt’”…, 44) = 44” 然后根据配置文件中的信息直接读取磁盘内容。 很明显,这种情况下ODU还是直接根据文件路径读取信息,那么在Exadata上,自然是搜索不到的。 因为,Exadata上,数据是放在cell上的,db节点调用 libcell11.a 并通过 socket 的方式通信。 但是kfed可以读取cell的数据,具体方法参见 Exadata上验证ASM磁盘头备份的位置 我跟踪了一下kfed读取cell上数据块的过程,大致如下: kfed打开socket,并读取/etc/nsswitch.conf来进行域名解析: kfed 读取自己的fd(/proc/self/fd/),fd是linux系统上进程的文件描述符: kfed 读取 ADR … 继续阅读

发表在 内部机制 | 标签为 , , , , | 一条评论