网志栈编辑推荐
《Oracle DBA手记4:数据安全警示录》不仅是写给技术人员看的，更是写给企业数据管理者看的，力求帮助企业避免遭遇《Oracle DBA手记4:数据安全警示录》所述种种灾难。同时，这也是一本相当深入的技术书，包括了一些相当深入的技术探讨，不仅可以帮助读者加深对于Oracle数据库技术的认知，还可以帮你在遇到类似案例时，做出同样的营救工作。
；
内容简介
《Oracle DBA手记·4：数据安全警示录》以数据安全为主线将众多灾难挽救过程串联在一起，不仅对各个案例的发生过程进行了详细描述，更为读者提供了具体的规避法则。其间穿插介绍了很多新鲜的技术细节和恢复方法，以及作者对于数据安全的思考。
本书不仅是写给技术人员看的，更是写给企业数据管理者看的，力求帮助企业避免遭遇本书所述种种灾难。同时，这也是一本相当深入的技术书，包括了一些相当深入的技术探讨，不仅可以帮助读者加深对于Oracle数据库技术的认知，还可以帮你在遇到类似案例时，做出同样的营救工作。
作者简介
盖国强，Oracle ACE总监，恩墨科技创始人，ITPUB论坛超级版主，远程DBA服务的倡导者和实践者，致力于以技术服务客户。著有《深入解析Oracle》、《循序渐进Oracle》、《深入浅出Oracle》等书；从2010年开始，致力于《Oracle DBA手记》的撰写与编辑工作，并与张乐奕共同创立了ACOUG用户组，在国内推进公益自由的Oracle技术交流活动。
目录
靡不有初，鲜克有终
以空间之由--误操作删除数据文件恢复案例两则
灾难描述
案例警示
技术回放
恢复过程--通过文件描述符进行数据恢复
技术难点
通过 BBED 获取文件号信息
通过 od 命令获得文件号信息
以拯救之因--强制恢复导致 ORA-600 4000 错误案例
灾难描述
案例警示
技术回放
恢复过程
ORA-600 4000 错误揭秘
通过_minimum_giga_scn 消除 SCN 异常
ORA-600 4194 错误 UNDO 故障消除
以优化之名--存储优化导致表空间误删除案例
灾难描述
案例警示
技术回放
以安全之期
VALIDATE 实现备份验证
数据库备份加密
口令模式
透明模式
混合模式
透明加密（TDE）技术
合抱之木，起于毫末
Oracle 数据库软件发布序列
一个逻辑坏块引发的灾难
案例警示
技术回放
一个硬盘坏块引发的灾难
灾难描述
案例警示
技术回放
AIX 系统 ODM 简介
ASM 头块备份机制
kfed 工具编译与使用
手工修复 ASM 案例一则
灾难描述
技术回放
PROVISIONED 磁盘状态分析
使用 kfed 修改 ASM 磁盘头信息
ASM 数据抽取恢复--通过 AMDU 恢复数据案例一则
灾难描述
案例警示
技术回放
AMDU 工具
文件分析
AMDU 文件恢复
未雨绸缪，防患未然
DBA 四大守则
DBA 守则外两则
各种惨痛的案例
系统级误删除案例
数据库误删除案例
通过触发器实现 DDL 监控
主备环境错误案例
业务高峰误操作案例
备份级误操作案例
进程级别误操作案例
数据文件误操作案例
误关闭生产库案例
系统存储级误删除案例
亡羊补牢，未为迟也
数据篡改案例解析
案例描述
案例警示
技术回放
故障分析的过程
日志文件的转储
LOGMNR 解析
案例之深入解析
技术难点
密码安全与加密
明察秋毫，见微知著
一次碰撞引发的灾难--ASM 保护式文件离线引发故障
灾难描述
案例警示
技术回放
恢复过程
又一次碰撞引发的灾难--文件离线与归档缺失案例
灾难描述
案例警示
技术回放
恢复过程
空间与文件离线--离线表空间加载修复
灾难描述
案例警示
技术回放
恢复过程
技术提示
关于归档空间的设置
关于检查点的一致性调整
心存目想，三思后行
Truncate 导致的灾难--核心字典表误操作 TRUNCATE
灾难描述
案例警示
技术回放
恢复过程
脚本错误导致的灾难--数据库整体被删除故障
灾难描述
案例警示
技术回放
恢复过程
千里之堤，溃于蚁穴
一个字符引发的灾难--大小写字符疏忽导致的维护故障
灾难描述
案例警示
案情解析
技术回放
一个盘符引发的灾难--判断失误导致的误格式化故障
灾难描述
案例警示
技术回放
物尽其用，人尽其才
关库与关机--强制关机导致的写丢失故障
灾难描述
案例警示
恢复过程
技术提示
从小恙到灾难--重建控制文件失误导致的故障
灾难描述
案例警示
技术回放
尺有所短，物有不足--硬件故障导致的灾难一则
灾难描述
案例警示
技术回放
附录一 BBED 的说明
附录二 函数 f_get_from_dump
参考资料
前沿
；
未雨绸缪，防患未然
在数据库领域十几年，我发现在国内技术人员往往在充当救火队员的角色，企业也常常认为只有能够力挽狂澜、起死回生的技术人员，才是好的技术人员。而实际上，能够不犯错误、少犯错误，提前预防、规避灾难的技术人员才是企业技术环境的最有力保障，能够未雨绸缪，防患于未然才是更好的技术实践。
我们每年都帮助很多企业挽救数据、拯救危机。2011年12月30日和31日，连续的两个整天，从凌晨再到凌晨，连续挽救了几个用户的数据库。这些灾难发生得那么简单，那么不可思议，在迈入2012这个神秘年份的一刻，深深地触动了我。我想，如果把这些案例描述出来，就可能让一些用户警醒，避免再陷入这样的困境。而从别人的挫折中学习，进而在自己的环境中未雨绸缪，防患于未然，是每个数据库管理人员和企业数据环境管理者应该具备的素质。
写作本书还和2011年底众多席卷而来的密码泄露事件有关。当我注视着最常用的几个密码都在互联网上被公开时，除了手忙脚乱地在各大网站修改密码，剩下的就是深深的遗憾。几乎所有从事IT行业的人，都深知安全的重要性，可是放在实际执行中，大家又往往习惯性失明，忽视了自己周围本来力所能及之安全，很多专业人士就以这样或者那样的侥幸心理放任了风险的存在，并一步一步走向了安全危机。
对于数据库安全来说，通常缺乏的并非技术手段，更多的是缺乏规范和安全认知，如果用户都能够严格遵循安全守则并应用现有的安全技术手段，数据库的安全性就能够大幅增强，我们的安全事故率也会大大降低。
于是我决定动笔，写下自己多年来所遭遇到的安全案例，以及对于数据安全的思考。如果本书中的内容能够帮助一些企业规避错误，保全数据，挽救一些技术人员的时间，那么我将感到无比欣喜。于我们的生命中，最为宝贵的就是时间，寸金难买寸光阴。
；
；
免费在线读
其实这样的泄密，一看就是无意识的。很多时候，DBA就是要对无意识的事情，保持高度的警惕。为了这样的事情，影响到自己的职业生涯，是绝对不划算的。建议DBA在发布任何会有第三方知道的文档之前，先问问自己，这份东西会导致泄密么？多问自己几次，多确认几次，如果不能确认，那就和你的主管确认吧。我还记得，以前我们有一条铁的规定，非项目经理及以上级别，不得公开对甲方发布任何技术文档及承诺。这条规定就很好，可以避免很多不必要的麻烦。
2.忘记你的系统有备份
虽然我曾经反复强调，备份重于一切，但是我不得不承认，有时候，忘记你的系统有备份的确是一个重要的提示。
在本书部分案例中，客户存在备份，但是由于数据量庞大或者空间有限，使用备份进行恢复的成本很高或者不现实，于是客户不得不选择采取一些较为极端的方式来进行异常修复。
而很多DBA之所以犯下错误，也正是因为觉得别人做过备份，已经有了备份。这些想当然的前提在故障出现之后可能不再成立，而这正是很多经典故障的根源。
所以，我非常欣赏郭岳在书中提出的观点：在有些时候，忘记你的系统有备份。
很多人，看到这个标题，可能觉得十分诧异，作为一个DBA，需要遵守的守则中的第一条，就是要备份。
在eygle的DBA四大守则中的第一条，写的就是备份重于一切，并且很明白地说明，唯一能使DBA半夜惊醒的事情，就是系统没有备份。首先不得不说明，我完全同意这个观点，但是在维护电信运营商系统的时候，请你一定要忘记你的系统是有备份的。
我提出这个观点，基于以下两个原因。
首先，对于运营商级别的系统，数据量之大，如果没有到达非常让人崩溃的情况（例如，生产系统崩溃，容灾系统无法启动，并且应急系统也无法运行这样极端），是不会去采用恢复数据的方案的，因为数据量太大，恢复的时间太长，而运营商是要求业务能运行为第一要素的。
其次，人都是有依赖性的，当你知道你的系统有备份的时候，你的操作就开始不那么如履薄冰了，就开始毛躁了，因为你的潜意识会认为，反正我的系统有备份，大不了恢复回来。
忘记你的系统有备份吧，忘记它吧。
Oracle DBA手记.4，数据安全警示录 pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
