今天一次哭笑不得的异常处理过程
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部门肯定要被。。。。
页:
[1]