分类目录归档：backup&recovery

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

发表于 2015 年 6 月 23 日 由 Lunar

之前研究过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 | 标签为 , , , | 留下评论

[FAQ]-使用duplicate克隆数据库

发表于 2015 年 4 月 16 日 由 Lunar

帮一个朋友整理的，顺便发到blog。 . 使用duplicate克隆数据库： 将宝宝数据库科隆为Lunar数据库 这部分东西不是新东西，clone在8i就是可以手工做的，在9i还是10g（忘记了），就被封装成duplicat命令了。 之前的测试参见无所不能的duplicate–克隆数据库 . 不过一般我更喜欢手工用rman做，每一步都透明，每一步都可控可回退可追查可修改。 duplicate自动化了，但是出问题后就是整体全部重来，万一有问题，比较耽误时间。 具体步骤如下： 在备库创建目录： 宝宝数据库的参数文件： Lunar数据库使用的参数文件： 创建监听： 创建tnsnames.ora文件 重启监听 测试连接： 创建口令文件： 开始duplicate： 克隆完成，创建临时文件：

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

[FAQ]-使用rman备份做同机克隆和异机恢复

发表于 2015 年 4 月 16 日 由 Lunar

帮一个朋友整理的，顺便发到blog。 . 数据库克隆操作文档 一．前提说明: 1. 本测试是在同一台机器上完成，而在同一台机器中ORACLE_SID不可相同，所以涉及到克隆库修改ORACLE_SID问题 2. 为了使得本次操作能够更好的让客户了解其过程，使用了传统的rman备份来实现,而没有使用duplicate相关命令实现 3. 如果在不同机器上使用rman备份做异机恢复，就不用修改SID，保持跟以前一样就可以（步骤差不多，比同机克隆更简单） . 二．整体思路: 1. 关闭lunar 2，使用pfile.lunar.bak（DB_NAME=lunar）nomount database 3，恢复控制文件 4，恢复数据文件（SET NEWNAME） 5，shutdown abort（lunar） 6，export ORACLE_SID=lunar 7，使用pfile.lunar.bak（DB_NAME=lunar）nomount database 8，重建控制文件（SET DATABASE “lunar”） 9，catalog start with 10，recover database 11，alter database open resetlogs . 三．详细步骤 1，备份数据库lunar … 继续阅读 →

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

ADG备库由于控制文件，归档损坏等原因，不能switchover，failover和active standby database时

发表于 2015 年 4 月 15 日 由 Lunar

昨天损坏的备库，今天准备激活，然后做升级测试。 备库由于归档损坏，已经不能用常规手段switchover和failover，甚至直接激活也不能： 重启数据库后，重建控制文件，然后open resetlogs： 激活数据库： 最后在备库添加temp文件：

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

OEL6.2 EXT4 filesystemio_options=SETALL造成archivelog坏块

发表于 2015 年 4 月 14 日 由 Lunar

又踩了个坑…… 今天同事告诉我前天调整一个数据库的参数，重启后，备库总报错： 初分析，这个错误有点怪异，有redo 头损坏，有“Possible network disconnect with primary database” 尝试clear online redo log和standby redo log，没用 尝试在主库重建控制文件，然后再直接重启备库，还是上面的错误。 冷静下来，感觉不对劲，检查主库和备库，发现主库归档日志是按照sequence顺序生成 备库则是断断续续的，有的可以从主库传过来，有的传不过来 手工传过来，APPLY还是报错： 感觉是arch异常了，而且貌似所有报错的，都是没有从主库传过来的 而所有没传过来的，都是损坏的，因此手工传过来也没用，因此抽取一个arch进行校验： 结果显示，确实arch损坏了。 . 根据问题发生的时间，想起来那天调整数据库参数的时候，有一个filesystemio_options=SETALL 也就是调整文件系统AIO方式的，去年在公司还给大家发邮件说起来“ext4上不要使用 filesystemio_options=SETALL” 否则会造成数据库坏块，没想到今年自己被坑了……（哇哇大哭啊……） 具体可以参见Oracle 文档： ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros when filesystemio_options=SETALL on ext4 … 继续阅读 →

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

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

发表于 2015 年 1 月 29 日 由 Lunar

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

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

ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state

发表于 2015 年 1 月 6 日 由 Lunar

如何处理下面的错误？ ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state 方法跟ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用的是一样的，这里不赘述，简单模拟损坏并修复的过程如下： I_DEPENDENCY2损坏的处理 11.2中I_DEPENDENCY1损坏的处理 例如： 相应的trace如下： 解决问题： 然后将数据库启动到限制模式，rebuild该index：

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

I_DEPENDENCY2损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

我们知道，在10.2中如果SYS.I_DEPENDENCY1损坏或者不可用时，数据库open时就会报如下类似错误： 10g中I_DEPENDENCY1损坏的处理 11.2中I_DEPENDENCY1损坏的处理 那么如果I_DEPENDENCY2有问题时，什么结果呢？ 我们还是在10.2.0.1中测试： 测试结果，数据库可以正常open，但是alert后报错，显示如下： 修复的方法很简单，直接将该索引的状态设置为失效，然后rebuild，具体操作，参考ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

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

11.2中I_DEPENDENCY1损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

上一篇，我们测试了10.2中，i_dependency1失效的过程和处理方法。 参考10g中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 这里，我们在11.2中模拟i_dependency1失效（测试环境使用11.2.0.3）： 11.2中：先看一下，数据库中跟依赖关系相关的表都有哪些： 可以看到，10g是18个，11.2是24个。 10g和11g中，DEPENDENCY$表都存在两个索引，这两个索引损坏时对数据库的影响是不同的，他们分别定义如下： 他们存储在哪些block中： 10g和11g的DEPENDENCY$ 和 I_DEPENDENCY1、I_DEPENDENCY2定义都一致的，只是处理方法不同。 现在我们在11.2.0.3模拟i_dependency1失效，看看什么效果： 相应的alert.log信息如下: 说明已经标示 SYS.I_DEPENDENCY1 为无效了。 现在启动数据库看看： 没错，就是这个结果，从11.2开始，类似I_DEPENDENCY1这样的index的失效不会数据库不能open了。 而在10.2中，需要open upgrade模式。 现在修复这个索引： 注意 ：11.2跟10.2还有一个小区别（感觉无关紧要）：11.2多取了一个字段“type#”： 那么11.2为什么可以直接open呢？ 首先，我们来看一下，当 I_DEPENDENCY1 正常时，数据库open的相关动作： 该语句执行7次，七次的执行计划都是上面这样的。 当I_DEPENDENCY1为UNUSABLE时，该语句仍然执行7次，但是7次的执行计划都类似下面的，走“TABLE ACCESS FULL DEPENDENCY$”。 这说明oracle 11.2的二进制代码多了一个判断的功能，当发现I_DEPENDENCY1为UNUSABLE时自动修改了执行计划（没有验证其他类似索引是否都是这样的）： 推测：11.2的代码里面写死了一个判断当open数据库时，如果遇到类似DEPENDENCY$这样的表的索引失效了，那么直接对DEPENDENCY$进行全表扫描。

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

ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

发表于 2015 年 1 月 5 日 由 Lunar

有朋友问起ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_DEPENDENCY1’ or partition of such index is in unusable state错误怎么处理。 11.2中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 当SYS.I_DEPENDENCY1损坏或者不可用时，就会报如下类似错误： 首先说一下，10g中的处理方式，有两种： 1，直接在10g中修复 2，使用11.2将数据库拉起来到upgrade模式，然后修复 先看一下，数据库中跟依赖关系相关的表都有哪些： 这里，我们关心的是DEPENDENCY$的索引信息，可以看到，DEPENDENCY$表存在两个索引。 这两个索引损坏时对数据库的影响是不同的，他们分别定义如下： 9i、10g、11.1以前，一些核心对象的定义就在$ORACLE_HOME/rdbms/admin/sql.bsq中。 比如tab$,obj$,ind$等等的定义都在其中。 从11.2开始，创建一些重要的核心基表的脚本仍然是sql.bsq，但是已经将各种对象的创建分类到不同的脚本： dependency$，i_dependency1和i_dependency1的定义如下（10.2和11.2没有区别）： 下面我们看一下他们使用了哪些block： 下面我们在10.2总模拟i_dependency1失效（测试环境使用10.2.0.1）： 执行alter index i_dependency1 unusable后，alert.log的信息如下： ind$的flags字段的定义（该定义可以查询基表定义，10.2中在sql.bsq，11.1以后，在dcore.bsq）： 通过对比，可以发现实际上对于ind$.flags的定义并没有改变，只是内部操作有所变化。 这些标示很有用，比如orcacle 9204有监控SYS的XXX索引的bug会导致数据库不能open，可以通过这个标示来修复。 再比如，10g以前online 创建索引中断后很麻烦，也可以通过修改这个来修复。 10.2以后可以通过dbms_repair.online_index_clean来清理索引状态。不过该功能没有记录在10.2的官方文档中（但是用desc … 继续阅读 →

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