罗敏oracle Oracle Acs资深顾问罗敏 老罗技术核心感悟:失去了一次露脸机会

2017-09-24
字体:
浏览:
文章简介:某日与Oracle同事一同在某移动公司进行技术交流,涵盖12c.云技术.数据库整合.容灾.OEM等多个专题领域.临近中午时分,一直喷到了Oracle最适合于人工错误恢复的FLASHBACK技术.正在唾沫四溅之际,突然接到客户DBA电话:"罗工,能不能暂停一下技术交流,我们正好有三张表刚被人意外删除了,能不能过来帮忙用你刚刚介绍的FLASHBACK技术把这三张表抢救回来?"世界上怎么还有这么巧合的事情?已经由不得我有半分迟疑,特别是任何私心杂念了.诸如:"罗工,这不正好让你展现

某日与Oracle同事一同在某移动公司进行技术交流,涵盖12c、云技术、数据库整合、容灾、OEM等多个专题领域。临近中午时分,一直喷到了Oracle最适合于人工错误恢复的FLASHBACK技术。正在唾沫四溅之际,突然接到客户DBA电话:“罗工,能不能暂停一下技术交流,我们正好有三张表刚被人意外删除了,能不能过来帮忙用你刚刚介绍的FLASHBACK技术把这三张表抢救回来?”

世界上怎么还有这么巧合的事情?已经由不得我有半分迟疑,特别是任何私心杂念了。诸如:“罗工,这不正好让你展现Oracle技术特点,给你次露脸机会了。”。“罗工,你不挺能吹的吗?看你能不能展示真才实学了”… …。于是,我端起笔记本电脑,直奔现场,一边下楼,一边赶紧看FLASHBACK相关资料。俗话说:临阵磨枪,不快也光。呵呵。

销售同事也看出了情形的紧迫和老罗的“窘”态,想尽一切可能在帮忙:帮我拆笔记本电源线,帮我提着矿泉水,更恨不得搀扶着正阅读文档,步履有点蹒跚的老罗同志一同下楼,哈哈!

待我赶到机器旁边时,资料也已经看完了,心中也有底了。于是,在简单询问了问题现象之后,赶脚让第三方公司DBA输入如下命令:

咦,怎么是空?再在sys用户下输入:

还是空!怎么回事?难道删除这三张表的客户不是意外操作,而是诚心搞破坏,用了“drop table … purge”命令,或者清空了回收站(Recycle Bin),从而彻底删除了这三张表?与客户进一步确认:这三张表的确是误删除的,没有使用上述命令。

既然如此,为什么回收站没有这三表表的数据呢?稍一思忖,想起来了!Oracle还有个初始化参数(RECYCLEBIN),可控制是否使用FLASHBACK DROP。一检查,果然如此!原来DBA把RECYCLEBIN设置成OFF,从而关闭了FLASHBACK DROP功能。唉!遗憾啊,老罗同志失去了一次露脸的机会,Oracle更失去一次展现技术特点的机会!

本来可以通过“flashback table <table_name> to before drop”一条简单命令,在数秒钟之内就能恢复被误删除表,结果害得客户从生产系统去重新抓取数据,同时恢复被删除的索引、Constraint等数据,整整折腾了一个多小时。客户庆幸的是:幸亏生产系统还有数据,否则叫天不应,喊地不灵。

待一切恢复正常了,我还是询问DBA了:“为什么要关闭FLASHBACK DROP功能呢?”回答是:“你们Oracle Flashback太消耗资源了,影响性能,我们不敢打开。”

哦,原来如此。这也是本文的主题:从技术上言,Flashback不是单一技术,而是一个技术家簇。以下就是各种Flashback技术的综合对比:

各位看见了吗?上述表格中每种Flashback技术原理、目的、是否是缺省配置、适应场景等都是不一样的。没错,某些Flashback技术,特别是Flashback Database是需要进行专门配置的,例如创建Flashback Recovery Area,还会产生大量Flashback log,也的确对性能有一定影响的。

但是,很多Flashback技术一方面是缺省配置的,另一方面是基于Undo技术的,并不额外产生资源开销的,对性能的影响也非常有限。

例如Flashback Drop技术仅仅在删除表时才会有一定操作,难道我们的系统成天都有Drop Table操作?大家没事天天删表玩儿?不可能吧,呵呵。

唉,这就是国内IT行业的常态之一:不分青红皂白;技术运用简单化;动辄一刀切;缺乏对相关技术的深入研究;什么新特性都不敢用;想当然地自己吓自己……

我们时候才能真正做到严谨、科学、务实、专业、积极、进取,充分评估、大胆运用各种IT新技术、新特性啊?