致亲爱的读者朋友们，

你不愿意花时间做预防，最终会愿意花加倍的时间去处理故障。在运维的世界，一味避免麻烦只能制造更多的麻烦。未雨绸缪防患未然，才是数据安全法则。从现在起，让计划做主，定期监控防患未然。

最近爆发的SCN故障让好多DBA很头疼，抛开故障对其他库的影响，很多企业自身的损失也是不可估量的。这引起了很多运维商和公司管理层的重视，那么究竟是什么导致了这一故障再次集中爆发？

SCN的问题并不是一个新的问题

早在2011年关于Oracle SCN的安全漏洞被发现以后，Oracle就给出了自己的态度，2012年一月发布了CPU补丁增加了隐含参数_external_scn_rejection_threshold_hours，这个补丁不仅能够防止SCN故障的发生，并且在故障发生的时候，能够防止故障传播给其他库带来影响。

对于新的补丁，很多客户并不敢轻易尝试，因此在该补丁发布一年多的时间里，应用程度并不是很高，这导致了2012年年底2013年年初在移动，电信行业的SCN故障首次大面积爆发。对于这类大型企业，往往数据库众多彼此关联错综复杂，并且可能分部与总部间也会以DBLINK关联，牵一发而动全身，损失惨重。

自那次故障后，SCN的问题引起了很多人的重视，大部分企业也是及时打补丁进行预防和修复。然而在平时繁重的业务和企业各方面压力下，仍然有部分企业无动于衷。直到今天，让故障来提醒。这三年多的时间里，本是有很多的机会可以打个补丁，避免这一切的。而Oracle也是苦口婆心提醒了好多次，并发布《关于Oracle DB SCN 生成率过高的预警及处理建议》告诉大家及时预防问题。

关于BUG的问题，Oracle每个季度都会发布很多的补丁，无论是你遇到过的还是没有遇到过的故障，都应该慎重评估每一个新的补丁会给系统带来的影响，在有必要的情况下及时应用新的补丁，让系统远离bug忧患。

这种故障发生在年底，不得不引起我们的重视。安全问题，再强调都不为过。“对于数据库安全来说，通常我们认为缺乏的并非技术手段，更多的是缺乏规范和安全认知，如果用户都能够严格的遵循安全守则并应用现有的安全技术手段，数据库的安全性就能够大幅增强，我们的安全事故率也会大大降低。”这是盖总在《DBA手记4-数据库安全警示录》中的一段话，今天再次拿出来，与大家共勉。

主动选择，远离忧患。

云和恩墨，为你的数据安全保驾护航。

--云和恩墨编辑部

2016年11月1日

往期期刊回顾

1~11

第一期刊物下载链接:

http://pan.baidu.com/s/1nuuXaUP

第二期刊物下载链接:

http://pan.baidu.com/s/1pJXyYU3

第三期刊物下载链接:

http://pan.baidu.com/s/1eQZpiBg

第四期刊物下载链接:

http://pan.baidu.com/s/1kV7zh3p

第五期刊物下载链接:

http://pan.baidu.com/s/1mi2EKOC

第六期刊物下载链接:

http://pan.baidu.com/s/1pLqyXCn

第七期刊物下载链接:

http://pan.baidu.com/s/1nvNE43Z

第八期刊物下载链接:

https://pan.baidu.com/s/1jIQ4pl8

第九期刊物下载链接:

https://pan.baidu.com/s/1gfa5riV

第十期刊物下载链接:

https://pan.baidu.com/s/1boWBDXP

第十一期刊物下载链接:

https://pan.baidu.com/s/1mi0gGPU

如何加入云和恩墨大讲堂微信群

搜索盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。

点击阅读原文下载本期电子期刊