事情大致过程是这样的：两节点的RAC数据库(A和B)，其中A节点所在的主机不知道什么原因重启了，导致A节点数据库宕掉，原来跑在A节点上的GG便自动failover到B节点上了，当我尝试启动extract时，出现以下错误：
Normal 0 false false false EN-US ZH-CN X-NONEERROR OGG-01028 Oracle GoldenGate Capture for Oracle, E103ESG1.prm: Non-standard redo detected in 10g compatible format. 在metalink上找到一篇文章[ Normal 0 false false false EN-US ZH-CN X-NONE[ID 1313864.1], 根据它提供的解决方法，我做了：
Normal 0 false false false EN-US ZH-CN X-NONEggsci> Normal 0 false false false EN-US ZH-CN X-NONEalter EXTRACT E103ESG1 begin 2011-11-18.
Normal 0 false false false EN-US ZH-CN X-NONEERROR OGG-01028 Oracle GoldenGate Capture for Oracle, E103ESG1.prm: Non-standard redo detected in 10g compatible format. 在metalink上找到一篇文章[ Normal 0 false false false EN-US ZH-CN X-NONE[ID 1313864.1], 根据它提供的解决方法，我做了：
Normal 0 false false false EN-US ZH-CN X-NONEggsci> Normal 0 false false false EN-US ZH-CN X-NONEalter EXTRACT E103ESG1 begin 2011-11-18.
ggsci> Normal 0 false false false EN-US ZH-CN X-NONEstart E103ESG1
问题就出现在这个该死的日期上，当时美国时间是11-17号晚上，中国时间是11-18，当时因为有点急，同时又有个新手同事在后面盯着我，说要跟我学习，心里上就有点想装潇洒，没多想就敲了2011-11-18，然后悲剧就发生了，导致部分数据丢失，马上用户就开始抱怨、问责。原本应该是一件有功的事，就是因为自己心理太想当然、一时疏忽，变成了被人问责，心里真不是滋味。
这个不是技术问题，而是心态问题，以后工作中心态一定要摆正！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/26277071/viewspace-711635/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
