标签归档:linux

Linux误删除文件并且数据库crash后恢复

我们都知道误删除文件后,如果没有其他操作,且数据库没有crash(句柄还在),那么是可以通过fd找到文件进行数据库恢复的,具体可以参考以前的文章:linux 误删除文件恢复 那么,如果句柄已经释放(比如数据库crash了),且客户重启了数据库,并执行了一些“恢复”尝试,然后怎么办? 我们测试下,这里我们要借助一个小工具:ext3grep 该工具可以在下面的网址下载最新版: http://code.google.com/p/ext3grep/downloads/list 系统必须要有e2fsprogs-libs,否则安装ext3grep的时可能会有问题。 如果你下载了rpm包,那么安装so easy: 如果你下载了src的源码,那么可以如下方式安装: 我们看下他的帮助,还是很强大的: 模拟数据库文件被误删除,且数据库crash: 数据库启动报错,丢失了文件 ‘/oradata/orcl/users01.dbf’。 现在使用ext3grep进行扫描和恢复: ext3grep是针对ext3文件系统的(ext2单有自己的扫描恢复工具),确认丢失的文件是ext3文件体系: 这里,我的数据文件都在/oradata,是设备 /dev/sdc1 : 注意这里,我的数据库目录的inode是 4358145 ,下面我们开始从这个inode继续查找: 文件的inode已经被覆盖了 这里根据两个两个信息进行恢复文件的操作: (1)数据库报错告诉我们需要恢复的文件名称:/oradata/orcl/users01.dbf (2)ext3grep的提示信息告诉我们了从哪里开始写文件: Inode 4358145 is directory “orcl”. 恢复过程如下: 从上面提示我们看到了文件已经恢复出来了,放在 orcl/RESTORED_FILES 下面: 完了不行了,被覆盖了。。。否则这一步就会在当前执行ext3grep的目录下找到一个RESTORED_FILES目录,里面就是我们的user01.dbf文件,再之后,你懂的。。 把他copy到/oradata/orcl/users01.dbf,然后执行recover datafile ‘/oradata/orcl/users01.dbf’,在open,就ok了。。。 我们再测试另一个工具extundelete(感觉原理跟ext3grep一样),看看他是不是强大一些,o(∩_∩)o … 继续阅读

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

Linux下手工卸载11.2 RAC(非MOS的deinstall方法)

用了下11.2的deinstall卸载慢的很,熬人,自创了一个,感觉很好,5分钟内搞定,可以稍微改改,写成脚本,o(∩_∩)o 哈哈 思路来自于经典的《How to Proceed From a Failed 10g or 11.1 Oracle Clusterware (CRS) Installation (Doc ID 239998.1)》 补充了一些11.2特有的内容。 下载11.2 RAC的官方方法: How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation (Doc ID 942166.1) 本次没有采用这个方法,其主要是执行deintall脚本,但是我的环境中,执行时间很久,不喜欢……………… 以下是一个节点的,2个节点也一样: 最好先执行这个: 当然,按照我下面的,不执行也没有问题…… 检查是否还有 d.bin … 继续阅读

发表在 Installation and Deinstall, RAC, Scripts | 标签为 , , , | 2 条评论

linux 误删除文件恢复

创建测试表空间 创建表插入数据 删除datafile 数据还在,因为从buffer cache中读到的 执行flush buffer cache 可以看见,再次查询,报错文件状态不对了(找不到了) 检查dbwr进程的spid 找到dbwr的句柄 进入dbwr进程的File Descriptor number目录中 恢复过程 检查下,文件已经恢复完成,大小为10m 将数据文件offline 恢复datafile 将数据文件online 好了,完成恢复了

发表在 backup&recovery | 标签为 , , | 2 条评论