« 归档日志管理不容易 »
DBA » http://www.anysql.net/dba/keep_enough_archive_log.html 2009-02-06昨天晚上接到一网友电话, 咨询一件事情, 聊了一会后才明白了是什么事情. 一个数据库中有两个用户A和B, 理论上所有的表应当分别存在DATA_A和DATA_B中, 现在要清掉B用户及DATA_B表空间以释入空间, 没有事先做足够多的检查, 就将DATA_B表空间及数据文件删除了, 事后发现A用户有一两个重要的表存在DATA_B表空间上, 引起了系统停机问题.
由于数据库巨大, 最近的全备是一年多以前的了, 从里面还原出来进行恢复, 才发现丢了一年前的一两个归档日志, 因此束手无策, 来咨询我怎么办, 其实已经没有捷径可走了. 这个问题的背后从小处看却是归档日志管理的问题, 理论上大家都知道应当去定期检查, 但事实上能照着做的人很少.
最近我自已也有两个和归档日志有关的问题, 还好年前用智能化角本来管理归档日志了, 才避免了Standby的重建工作. 第一次在节前业务高峰, 远程Standby的存贮设备太差了, 恢复跟不上, 积累了上TB的归档日志, 如果用原来的归档清除脚本, 早就不行了, 用了智能的脚本强行顶着, 最后撑到了现在跟上了, 要不又要重建几个TB的Standby了.
第二次是过年中间远程备库的机器挂起了, 大家都回去过年了, 又是Standby就暂时不管了, 因为智能脚本中只会在Primary上删除已经在这个Standby上应用过的日志, 所以很多天的归档日志得以保留下来, 将机器重起一下后, 再传归档日志过去, 又一次避免了Standby的重建工作.
也和很多企业, 没有充分认识到数据的作用, 没有给管理员一个简单一些的操作环境, 有关. 当然更重要的是DBA要有责任心, 然后才能细心认真地工作.


智能化脚本不错