2010年6月2日傍晚，月黑风高，不料天有不测风云，一次痛苦而难忘的误操作就发生于此。
在生产环境的误操作尤其是DBA的梦魇。虽然最后竭尽全力，力挽狂澜，但仍心有余悸。
故事发生在为Oracle提供高级复制的软件Shareplex身上。
起因，Shareplex有一个一直未曾解决的Bug，在vardir目录下会产生许多capture queue files，直到将vardir撑爆。目前的workaround是找到当前使用的capture queue file，人为删掉前面所有的capture queue files。
经过，傍晚是睡意朦胧之际，警觉之心顿消，copy&paste的速度越发地熟练和不假思索，于是，悲剧地多删了最后，也就是当前的capture queue file。
结果，（此处省略几千字）Fixed。
收获：
每一次成功都会有所收获，而每一次失败却收获更丰。因为失败是稀少的（如果很多也太悲剧了。。），失败是让人记忆深刻的，失败也是会成为一个大脑里的标记的。
此次失败的原因是多方面的，其中重要的原因是对此类事情做得太多了，有种“轻敌”的感觉，于是思想上略显懈怠，于是手先于脑。这也就是为什么常常人们的误操作都发生在每周会做无数次的小事情上，而复杂的操作往往会引起人们的警觉，因为能得到完美的完成。
All about Tech：
不说废话，针对Shareplex capture queue file丢失的情况，我们该如何解决呢？
首先讲讲Shareplex capture queue file是干什么的？它是在Source端，接受reader进程读redo log产生的messages。
那么如果capture queue file被删除了，那么意味着我们丢失了一部分从redo log里读出来的messages，而reader进程是不知道他们丢失了的，因此继续往下读。从而形成了一个messages的gap，后面的messages无法传输到Target。
所以，正确的流程是采用shareplex的point in time recovery技术强制让reader从误操作前面一个时间点的归档日志开始读，虽然由于不知道具体的时间偏移量，会有部分重复的数据读出然后被Target应用，重复的时间里有一些OOS（Out of Sync）Errors出现，但是，这样可以保证不丢失数据。
那我们是如何尝试解决的呢？又遇到了哪些意想不到的苦难呢？
1.处于本能，在Source端发现误操作后，尝试了采用qview -i里的fixup all命令，重启shareplex，幻想这个万能命令能解决问题。
结果是reader died。
2.于是call QUEST support，采用了彻底丢弃掉被我删除的capture queue file里的差不多1k多条messages，以此来保证Shareplex的正常工作，至少reader复活了。
采用的具体办法如下：
qview> uscan 0 1 3
***Sque 0, mid 14225964996, sqmid 14225964996, mlen 1157248, nextm 10902612993877, mqseq 10902611836629, mpseq 28467640162888, 06/02/10 05:12:03, FIXUP to patch 1321 missing messages
Sque 0, mid 14225964997, qseq 10902612993877, 06/02/10 04:50:00, 230678/257876132, transid 0, COMMIT, AAAAAAAAAAAAAAAAAA , SCN 3583017198059, forward = 0
Sque 0, mid 14225964998, qseq 10902612994221, 06/02/10 04:50:00, 230678/257918560, transid 0, Insert, AAADiHAAZAABKPRABm , SCN 3583017198060, forward = 1
qview> exit
$> qview -i
qview> qinit
qview> open c r
Current queue o.XXX+C user +PR+o.XXX+sp_ordr+o.XXX
qview> rrls 0 10902612993877
这里我们发现丢失了1321条messages，于是将它们都release掉，之后Shareplex能正常工作。
但是，问题是，之后在Target发现了无数的OOS Errors。由于表都巨大无比，而且巨多，所以无法每一个都进行compare&repair。
这时，我们打算自己进行point in time recovery。
3.第一次在Source的point in time recovery。
首先通过在Target执行show post，找到当前所有post queue进行到了哪个log sequence号了，而记录这个sequence号作为我们point in time recovery的起点。也就是让reader从这个log sequence开始抓取messages。
a.shutdown source和target的shareplex
b.备份好source和target的vardir目录，例如tar一下放到旁边。
c.在source和target上执行ora_cleansp / ， 这里会清空shareplex的一些表。
d.start shareplex on source,然后
stop export
activate config xxx.cfg seqno=
这里要注意观察是否capture进程运行良好，开始堆积messages。
e.start shareplex on target，然后
start post
f.在source：
start export
这时，在target的event log里，我们会看到大量的OOS Errors，这是正常的，等到recover过了出错点后，就会趋于平静。
由于point in time recovery不支持LOB字段，所以我们还要为包含LOB字段的表进行特殊处理：
SQL> select TABLE_NAME from dba_tab_columns where WNER='XXX' and DATA_TYPE in ('CLOB','BLOB');
然后自行向办法同步，这里略去。
4.修复Target sp_cop消失的诡异问题
本来到这里，我们基本修复了所有问题，可见shareplex point in time recovery的强大。
但是意想不到的问题在Target发生了：
也许是由于早期大量的OOS Errors，Target端的sp_cop进程突然不见了，但是post却还在干活。
由于现在无法登入Console，于是在OS层面kill掉所有的shareplex进程，重启shareplex，core dump。。。
通过ipcs -a发现有shared memory segments和Semaphores没被释放，于是ipcrm -m干掉。
重启，继续core dump。。。
于是再次call QUEST support，在support的帮助下，rename了一些文件：
在data目录:
\mv statusdb statusdb.bak3
\mv dirty dirty.bak3
在rim目录:
\mv shstinfo.ipc shstinfo.ipc.bak3
\mv shmaddr.loc shmaddr.loc.bak3
然后重启shareplex，终于成功！顿时觉得几个lock文件都能使shareplex重启core dump，太让人意外的了。
5.修复Target端专门复制sequence的post queue不停死掉的问题
这是以前遇到过的一个bug，某复制sequence的post queue不停死掉。
在event log里会看到如下错误：
Error 2010-06-02 20:13:07.988013 3969 5 Poster: Poster exit on 9i ddl error due to ORA-04002:
INCREMENT must be a non-zero integer. on ALTER SEQUENCE "xxx"."xxx" INCREMENT...
(posting from XXX, queue xxx, to xxx) [module opo]
于是第三次call QUEST support，采用了对这个queue加一个参数，使得ddl error不会让这个queue死掉。
再加一个debug这个queue的参数。
加完之后，这个queue就再也没死了。
sp_ctrl > set param sp_opo_stop_on_ddl_err queue 0
sp_ctrl > set param sp_opo_debug_flag queue 0x0f0021ff
sp_ctrl > start post
如果以后没有继续出现这个错误，可以考虑取消他俩：
reset param sp_opo_stop_on_ddl_err queue
reset param sp_opo_debug_flag queue
stop post queue
start post queue
至此，此次漫长的修复之路到此为止。
教训：
1.不要轻视任何简单、常规、无聊的任务。
2.不要让手先于大脑做事情，等到大脑反应过来的时候发现已经晚了。
3.不要急于完成多个任务，要淡定！
总结，怎么最后写得像检讨。。。
积累rp，总结经验，重新再战！
在生产环境的误操作尤其是DBA的梦魇。虽然最后竭尽全力，力挽狂澜，但仍心有余悸。
故事发生在为Oracle提供高级复制的软件Shareplex身上。
起因，Shareplex有一个一直未曾解决的Bug，在vardir目录下会产生许多capture queue files，直到将vardir撑爆。目前的workaround是找到当前使用的capture queue file，人为删掉前面所有的capture queue files。
经过，傍晚是睡意朦胧之际，警觉之心顿消，copy&paste的速度越发地熟练和不假思索，于是，悲剧地多删了最后，也就是当前的capture queue file。
结果，（此处省略几千字）Fixed。
收获：
每一次成功都会有所收获，而每一次失败却收获更丰。因为失败是稀少的（如果很多也太悲剧了。。），失败是让人记忆深刻的，失败也是会成为一个大脑里的标记的。
此次失败的原因是多方面的，其中重要的原因是对此类事情做得太多了，有种“轻敌”的感觉，于是思想上略显懈怠，于是手先于脑。这也就是为什么常常人们的误操作都发生在每周会做无数次的小事情上，而复杂的操作往往会引起人们的警觉，因为能得到完美的完成。
All about Tech：
不说废话，针对Shareplex capture queue file丢失的情况，我们该如何解决呢？
首先讲讲Shareplex capture queue file是干什么的？它是在Source端，接受reader进程读redo log产生的messages。
那么如果capture queue file被删除了，那么意味着我们丢失了一部分从redo log里读出来的messages，而reader进程是不知道他们丢失了的，因此继续往下读。从而形成了一个messages的gap，后面的messages无法传输到Target。
所以，正确的流程是采用shareplex的point in time recovery技术强制让reader从误操作前面一个时间点的归档日志开始读，虽然由于不知道具体的时间偏移量，会有部分重复的数据读出然后被Target应用，重复的时间里有一些OOS（Out of Sync）Errors出现，但是，这样可以保证不丢失数据。
那我们是如何尝试解决的呢？又遇到了哪些意想不到的苦难呢？
1.处于本能，在Source端发现误操作后，尝试了采用qview -i里的fixup all命令，重启shareplex，幻想这个万能命令能解决问题。
结果是reader died。
2.于是call QUEST support，采用了彻底丢弃掉被我删除的capture queue file里的差不多1k多条messages，以此来保证Shareplex的正常工作，至少reader复活了。
采用的具体办法如下：
qview> uscan 0 1 3
***Sque 0, mid 14225964996, sqmid 14225964996, mlen 1157248, nextm 10902612993877, mqseq 10902611836629, mpseq 28467640162888, 06/02/10 05:12:03, FIXUP to patch 1321 missing messages
Sque 0, mid 14225964997, qseq 10902612993877, 06/02/10 04:50:00, 230678/257876132, transid 0, COMMIT, AAAAAAAAAAAAAAAAAA , SCN 3583017198059, forward = 0
Sque 0, mid 14225964998, qseq 10902612994221, 06/02/10 04:50:00, 230678/257918560, transid 0, Insert, AAADiHAAZAABKPRABm , SCN 3583017198060, forward = 1
qview> exit
$> qview -i
qview> qinit
qview> open c r
Current queue o.XXX+C user +PR+o.XXX+sp_ordr+o.XXX
qview> rrls 0 10902612993877
这里我们发现丢失了1321条messages，于是将它们都release掉，之后Shareplex能正常工作。
但是，问题是，之后在Target发现了无数的OOS Errors。由于表都巨大无比，而且巨多，所以无法每一个都进行compare&repair。
这时，我们打算自己进行point in time recovery。
3.第一次在Source的point in time recovery。
首先通过在Target执行show post，找到当前所有post queue进行到了哪个log sequence号了，而记录这个sequence号作为我们point in time recovery的起点。也就是让reader从这个log sequence开始抓取messages。
a.shutdown source和target的shareplex
b.备份好source和target的vardir目录，例如tar一下放到旁边。
c.在source和target上执行ora_cleansp / ， 这里会清空shareplex的一些表。
d.start shareplex on source,然后
stop export
activate config xxx.cfg seqno=
这里要注意观察是否capture进程运行良好，开始堆积messages。
e.start shareplex on target，然后
start post
f.在source：
start export
这时，在target的event log里，我们会看到大量的OOS Errors，这是正常的，等到recover过了出错点后，就会趋于平静。
由于point in time recovery不支持LOB字段，所以我们还要为包含LOB字段的表进行特殊处理：
SQL> select TABLE_NAME from dba_tab_columns where WNER='XXX' and DATA_TYPE in ('CLOB','BLOB');
然后自行向办法同步，这里略去。
4.修复Target sp_cop消失的诡异问题
本来到这里，我们基本修复了所有问题，可见shareplex point in time recovery的强大。
但是意想不到的问题在Target发生了：
也许是由于早期大量的OOS Errors，Target端的sp_cop进程突然不见了，但是post却还在干活。
由于现在无法登入Console，于是在OS层面kill掉所有的shareplex进程，重启shareplex，core dump。。。
通过ipcs -a发现有shared memory segments和Semaphores没被释放，于是ipcrm -m干掉。
重启，继续core dump。。。
于是再次call QUEST support，在support的帮助下，rename了一些文件：
在data目录:
\mv statusdb statusdb.bak3
\mv dirty dirty.bak3
在rim目录:
\mv shstinfo.ipc shstinfo.ipc.bak3
\mv shmaddr.loc shmaddr.loc.bak3
然后重启shareplex，终于成功！顿时觉得几个lock文件都能使shareplex重启core dump，太让人意外的了。
5.修复Target端专门复制sequence的post queue不停死掉的问题
这是以前遇到过的一个bug，某复制sequence的post queue不停死掉。
在event log里会看到如下错误：
Error 2010-06-02 20:13:07.988013 3969 5 Poster: Poster exit on 9i ddl error due to ORA-04002:
INCREMENT must be a non-zero integer. on ALTER SEQUENCE "xxx"."xxx" INCREMENT...
(posting from XXX, queue xxx, to xxx) [module opo]
于是第三次call QUEST support，采用了对这个queue加一个参数，使得ddl error不会让这个queue死掉。
再加一个debug这个queue的参数。
加完之后，这个queue就再也没死了。
sp_ctrl > set param sp_opo_stop_on_ddl_err queue 0
sp_ctrl > set param sp_opo_debug_flag queue 0x0f0021ff
sp_ctrl > start post
如果以后没有继续出现这个错误，可以考虑取消他俩：
reset param sp_opo_stop_on_ddl_err queue
reset param sp_opo_debug_flag queue
stop post queue
start post queue
至此，此次漫长的修复之路到此为止。
教训：
1.不要轻视任何简单、常规、无聊的任务。
2.不要让手先于大脑做事情，等到大脑反应过来的时候发现已经晚了。
3.不要急于完成多个任务，要淡定！
总结，怎么最后写得像检讨。。。
积累rp，总结经验，重新再战！
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15415488/viewspace-664339/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15415488/viewspace-664339/
264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
