从摆脱Data Guard手工搭建及维护的烦恼说起(3)

第二天通过日志看到应用运行之后,查看系统级,没有任何的抖动,数据库层面也可以看到应用是连接进来了.在反复确认调用的细节之后,我切换到指定的用户,再次尝试；然后再次运行这个报错的语句,终于得到了期望之中的报错.

SQL>selectbind_flagfromtest_billingwherecn_master=’660078174′;

selectbind_flagfromtest_billingwherecn_master=’660078174′

*

ERRORatline1:

ORA-00604:erroroccurredatrecursiveSQLlevel1

ORA-16000:databaSEOpenforread-onlyaccess

采用owenr用户的方式来查看,就没有问题了.

SQL>selectbind_flagfromacc.test_billingwherecn_master=’660078174′;

BIND_FLAG

———-

689537

这个问题是怎么回事呢?

TEST_SHINK下的都是同义词,指向ACC这个owner用户,那么这个同义词有什么特别的呢.进一步查看,发现同义词test_billing状态是INVALID的.

而问题的修复就更简单了,在主库运行下面的SQL即可.

>selectcount(*)fromTEST_SHINK.TEST_BILLINGwherecn_master=’660078174′;

COUNT(*)

———-

1

因为这个用户应用只在备库使用,所以就导致了这个看起来奇怪的问题,看来都是事出有因,耐心一些,细致一些还是会有发现.对于这个问题更多的细节就不赘述了.

六、数据迁移中巧用DataGuard

DataGuard是数据迁移中一个很重要的方式,但是一大硬伤就是不可以直接升级数据库.可以简化来说,数据库升级的本质是升级数据字典,大批量数据库的情况下快速迁移数据,通过DataGuard来完成,然后导入数据字典信息其实也是一个不错的方式.

比如一套硬件环境是Solaris,Oracle10gR2单实例,数据量在800G左右.想迁移到另外一台服务器上.大体的需求如下：

1. 借助这次维护的时机,能够把数据库升级至11g
2. 升级的过程需要尽可能保留一个较短的时间窗口,计划在2个小时以内完成
3. 有较好的解决方案去演练整个过程,多次总结,提高迁移的效率,保证质量
4. 有完善的回退计划,能够支持回退场景下业务平滑过渡
5. 目前对于跨平台没有明确的要求,可以继续使用Solaris,也可以考虑跨平台,但是影响范围要小.

这种情况下,就可以充分借助DataGuard来完成,我们可以在备库环境创建一个11g的数据库,db_name,字符集不变.

在备库端进行Switchover/Failover(具体选哪个,可以根据需求来定)后,导出传输表空间的元数据.这个时候对数据文件没有做任何操作,导出完成后,停掉备库端10g的数据库.

然后在备库导入传输表空间的元数据至新的11g库,数据文件路径依旧不变,因为传输表空间只传输表数据,对于存储过程,函数,视图,同义词,DB link,权限等都无法同步,所以可以在这个基础上选择性导出全库的指定schema的信息,导入目标库中,因为是DDL的导入,这个过程持续时间也会很快.

导入后就完成了基本的迁移,相比比Datapump,XTTS的传输同步数据的时长,这个过程可以控制在一个很短的时间内.

最后为个人的新书做一个宣传,《Oracle DBA工作笔记》是我个人笔记的精华选集,希望大家多多捧场,学习交流,共同进步.

文章出处：DBAplus社群(订阅号ID：?dbaplus)

（编辑：ASP站长网）