分类目录归档：Database

[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 | 标签为 , , | 留下评论

一次数据库性能问题处理（11g自动维护任务，log file sync）

发表于 2015 年 4 月 6 日 由 Lunar

看到问题发生前30分钟的awr显示，系统负载超高： 查询数据库当前等待事件： 跟awr中的信息一致： 直觉是resmgr:cpu quantum引起了其他一系列问题，这个已经不是第一次遇到了。 等待事件 resmgr:cpu quantum 是11.2引入的oracle资源管理引起的，这个东西一般问题很多，大部分时候，我们装机时，都是直接禁用的。 11.2的oracle资源管理中有一项最坑的是周末的维护任务，这个遇到好几次了。 禁用方法： 1，关闭一些不需要的维护任务： 关闭数据库的空间Advisor，避免消耗过多的IO： 关闭数据库的SQL自动调整Advisor： 关闭数据库的weekday窗口的DEFAULT_MAINTENANCE_PLAN： 查看当前active的resource plan ，确认已经关闭： 此时awr可以看到系统负载已经下降一点点，但是依然很高： 上述修改后的数据库等待事件已经变味“log file sync”，具体如下： 相应的前台等待事件： 后台等待时间： 在LGWR的trace中，可能会出现类似如下的信息： 这是11.2的新特性，Adaptive Switching Between Log Write Methods（LGWR写模式自动切换），该功能bug一堆，经常导致commit缓慢而带来的“log file sync”。 通过设置如下隐含参数，禁用11.2这个LGWR写模式切换功能： 修改后，数据库等待事件已经变为正常的应用日常的等待事件了： 此时的AWR看到，系统负载已经降下来了： 该应用正常时间，数据库连接数如下： 故障暂时缓解了，应用反映已经正常，但是可以看到，上面的信息告诉我们，对于这个应用来说，需要调整的地方还很多： 1，系统参数全面检查 2，SQL优化（SQL语句的写法，index，统计信息检查等） … 继续阅读 →

发表在 Database | 标签为 , , | Comments Off on 一次数据库性能问题处理（11g自动维护任务，log file sync）

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 | 标签为 , , | 留下评论

通过修改控制文件来修改SCN

发表于 2014 年 12 月 14 日 由 Lunar

之前有一些简单介绍SCN的文章： 浅谈SCN_1–从oracle7至今，如何获取scn 浅谈SCN_2–_kcmgas_函数 使用ORACDEBUG 修改 数据库SCN 这个测试是接着上次的使用oradebug修改SCN的，这里使用修改控制文件SCN和相关标示位的方法： 这个测试，我们把SCN增加100万，即从 2726293 修改为 3726293。 查看当前控制文件的位置： 将控制文件拿到本地，进行修改，修改过程如下： 首先找到数据库SCN： 修改SCN和相关标示位： 讲数据库shutdown，然后将修改后的控制文件copy到ASM中，并使用这个控制文件启动数据库： Mount数据库，并查看数据库SCN： 这里我们看到，数据库的SCN已经修改为我们指定的 3726296了。

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