今天一次哭笑不得的异常处理过程

ALLSTARS_ORACLE

3点多开发打来电话说一个核心表被错误全表update，有4个字段被错误修改，其中一个字段的值被全部更新成36，

这时候产线已经彻底歇菜了

我们的UNDO都设成3小时的保留时间，他要求恢复到2点半，这没啥难度，很easy的将2点半的数据插到一个新表。

这时开发那里电话已经被打爆，和他确认2点半数据OK之后就把问题表truncate，并把2点半的数据插了进问题表

没几分钟他又一个电话打来说2点半的数据还是错的，要继续向前rollback。我们这回彻底傻眼，原来的表已经做了

truncate，flashback是没戏了。

幸好这个核心表有一个trigger，所有的更改记录都被插到一个新表，再费了一番周折把13:09-14:34这之间的

那个特定字段不等于36的旧值全部捞出来插到问题表中，恢复了24万多但还少1673笔数据

这时候已经知道是一个IIS 网页的错误导致全表update，又去历史记录表中找特定时间段被这特定电脑修改的1673

笔数据，一番周折之后终于定位到这1673笔数据，并插到问题表中。这次彻底OK。

后记：

DBA和开发的沟通还是相当关键，出了问题一定不要慌，Double Check之后再做动作。处理完又仔细看grid control

的监控，发现2：19左右那个该死的网页做了三次全表update，更新了75万笔数据，logminer也能抓到这75万次

修改。即使flashback，历史表，logminer都不好使，我们的库也开了闪回，迫不得已的情况下也可以整库闪回去。

那样的话IT部门肯定要被。。。。