日归档：2015 年 4 月 16 日

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

OGG DDL trigger造成升级数据库后大量SYS对象失效和数据库DDL失效

发表于 2015 年 4 月 16 日 由 Lunar

OGG的DDL功能真是坑，今天在测试库尝试升级，被OGG的DDL给坑了（以前没摸过这个库，不知道有这个东西……） 以后，做任何大操作以前，一定要仔细检查数据库，是否曾经开启过OGG的DDL功能。 这个功能有很多隐患： 因为OGG的DDL是建立在SYS用户下面的， 与其他普通用户的trigger不同： 1，数据库文件offline后，如果有OGG的DDL曾经被开启，可能因此打不开数据库（先disable ogg ddl才行） 2，升级过程中，如果没有disable ddl trigger，可能出现一些升级后的异常 3，OGG用户删除后，并不能删除OGG的DDL trigger，因为他的属主是SYS，且属于internal trigger，会导致大量SYS用户的对象失效和DDL功能失效。 。。。。 升级数据库，从11.2.0.1到11.2.0.4，升级过程中，没有报错，但是数据库启动后，报错： 尝试删除OGG用户，报错： 检查报错的OLAP过程，为INVALID状态： 但是升级后，检查所有数据库组件是VALID状态： 理论上，升级后，组件都是正常的，为什么出现这种情况？ 尝试disable 这两个trigger，也报错： 貌似所有的DDL都失效了： 再一查SYS的无效对象，800多个： 使用utlrp编译，也报错： 最后一行提示XDB组件有问题: diable OGG的trigger，然后删除ogg用户后，再次使用utlrp编译，已经正常了： 且数据库已经没有无效对象： 再次校验XDB的组件，正常了： 再次查询组建状态，都ok：

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