上次说的原因已经基本定位，主要是表更新后的行迁移数量过多导致。初步在网上查询了一下方法，主要有三种：rebuild、move、导出导入表信息，各有优劣。也和公司的DBA讨论了一下，他建议用move方法。我觉得前两种都可以，由于需要自己动手，就在toad中看到可以直接支持rebuild，有现成的方法生产脚本，个人觉得比较保险。

当然动手时间最好选择在晚上或周末人少的时候，因为接近周末了，所以决定周六动手。

周六下午待系统rman备份基本完成后，开始动手了，因为有toad现成的脚本，所以就容易了，rebuild生成脚本后大体看了一眼，先拷贝了一份脚本，然后点击执行。

目不转睛的盯着一步步完成，突然心一沉，居然toad脚本报错，好像是日志组冲突，“日志组“？这是什么鬼？难道因为有人操作或者rman没有执行完？看了看似乎没有发现有正在执行的session。再试一次，报错依然，心里开始有点慌了，赶紧先联系DBA，问问日志组冲突怎么回事，DBA回复不清楚。看来是rebuild不成了，赶紧紧急恢复吧，还好执行脚本还不多。现在才赶紧仔细端详rebuild的脚本，没错先改A表名为A_X，然后删除引用这个表的其他表上的外检约束，删除本表上的约束，开始新建A表，从A_X查询插入A表数据，。。。。现在到哪一步出错了？看了看A_X已经有了，A表重建没有成功，不管了，先把A_X改名回来，把其他表的外键约束、本表约束统统重新建立一遍吧。手忙脚乱一通，终于好了，算是恢复了。

这时重新审视了一下新建表的脚本，突然发现与以往不同，多了这么一句：

SUPPLEMENTAL LOG GROUP GGS_37635 (BNO) ALWAYS

直觉感觉和日志组报错有点关系，赶紧网上搜一下，好像和oracle stream、ogg等有关，这时DBA来电，OGG报错，果然和OGG有关。DBA赶紧忙着恢复OGG去了。还好业务系统已经恢复正常，还能缓口气。

OGG是别的团队负责的，一时也无法搞明白，要不第二方案？和DBA商量一下，他也说使用move方案吧，今天先不处理了，他需要找时间验证一下。好吧，只好先收工了！

第二天一早，收到DBA信息，验证通过，详见邮件。大体上看了一下，不过和想的有点出入，我们move表不用换表空间，DBA验证的是换表空间，不过既然换表空间都没有问题，那么不换表空间也应该没有问题，因此决定再用move方案试一次。move方案相对简单一点，需要注意索引失效后的重新rebuild一下就行。于是我就立刻开工。果然进展顺利，很快就执行完毕，顺便把索引、约束、外键、其他引用的视图、函数、存储过程也编译一遍，也重新收集一遍统计信息。

然后再检查一下字典表的数据迁移情况，OK，果然消除了！随后也观察一下数据情况，居然大周末也有人加班操作，没多大一会就产生新数据了，好吧，至少帮我验证基本功能正常了！

接下来还有一个小插曲，检查表索引时发现，居然主键索引的属性不是唯一，虽然不影响系统本身，但是难免心里痒痒，干脆修改一下吧，结果因为主键索引不能随便更改，只能删除重建，同时各表引用这个表的外键失效，又引起新的一轮操作，OGG又开始报错，还好有DBA在，很快恢复。

事后总结：（1）提前准备方案，特别要注意备好异常恢复方案，免得手忙脚乱；

（2）多方论证，这次调整没有意识到OGG和此次调整有关，差点吃大亏。

后记，本周前两天又通过ELK平台进行了局部URL和业务部门网段的监控分析，确认响应时间恢复到以前的水平，也算是对于周末手忙脚乱的回报吧！看来，吃一堑长一智，平常再多的理论学习也是雾里看花，到头来还得通过实践检验，同时也才算是有体会有收获。