<< 返回文章列表

未雨绸缪丨DBA四大安全守则及各种数据库灾难案例

2019年8月2日
盖国强
911


导读:日前,我的新书《Oracle DBA手记4:数据安全警示录》(修订版)出版了,按照我一贯坚持的开源原则,今天分享书中的第五章节——DBA四大守则、DBA守则外四则、各类数据库安全的惨痛案例,希望可以帮助到读者朋友们。


云数据库时代的技能升级
超复杂数据库环境案例精粹
走向自动化、智能化的数据服务
安全+连续+高效+智能的解决方案实践


微信图片_20190802141306.jpg



本书概要




《Oracle DBA手记 4,数据安全警示录(修订版)》源于众多实践案例的总结,我们将大量的数据安全事件、数据库安全漏洞、Oracle数据库灾难恢复案例融合于一体,进行了详细的阐述和分析,并总结形成了指导企业规范运维、强化管理、规避灾难的指导原则。

《Oracle DBA手记 4,数据安全警示录(修订版)》通过概括总结形成的数据库运维原则,希望能够给企业运维管理者以警示,通过提前预防措施和规范化管理避免遭遇到书中描述的种种情形;此外,本书还通过复杂的Oracle数据库灾难恢复案例,深入阐述了数据库运行和工作的内部原理,希望能为读者的深入技术探索提供帮助。

《Oracle DBA手记 4,数据安全警示录(修订版)》既适合企业自动化和智能化运维的管理者参考,也适合深入学习数据库技术的读者学习探索。



本书目录





第1章  知己知彼  忘战必危
1.1危机四伏,数据注定泄露
1.2从罗维邓白氏案例看数据道德
1.3数据库管理员出售新生儿信息
1.4美国上千万信用卡信息疑遭盗取  
1.5数据外泄主要来自内部
1.6GDPR带来的数据安全思考  
1.7数据库的漏洞都会重来   
1.8那些运维中的疏忽导致的数据风险   
1.9参考资料   
第2章  运筹帷幄  三十六计  
2.1有效的备份重于一切
2.2测试环境和生产环境隔离   
2.3禁止远程的和业务时间的DDL操作
2.4ORACLE数据库DEVOPS的三十六计   
2.5参考资料   
第3章  合抱之木  生于毫末  
3.1ORACLE数据库软件发布序列   
3.2DB LINK必须升级的预警  
3.3SQL语句注入和CVE-2017-10282警告
3.4JAVA VM的反序列化
3.5从一次UPDATE的优化讲起
3.6一个逻辑坏块引发的灾难   
3.7参考资料   
第4章  靡不有初  鲜克有终   
4.1以空间之由——恢复误删数据文件案例
4.2以拯救之因——强制恢复导致ORA-600 4000错误的案例   
4.3以优化之名——存储优化导致表空间误删案例   
4.4以安全之期
4.5以便利之机   
第5章  未雨绸缪  防患未然
5.1  DBA四大守则
5.2  DBA守则外四则  
5.3  各种惨痛的案例
5.4  参考资料  
第6章  亡羊补牢  未为迟也   
6.1  数据篡改案例解析   
6.2  密码安全与加密  
6.3  分析与恢复被篡改的敏感数据  
6.4  参考资料   
第7章  明察秋毫  见微知著   
7.1  一次小碰撞引发的灾难——ASM保护式文件离线引发故障   
7.2  又一次小碰撞引发的灾难——文件离线与归档日志缺失 的案例   
7.3  空间与文件离线——离线表空间修复   
7.4  对写文件错误的处置改进  
第8章  心存目想  三思后行
8.1TRUNCATE导致的灾难——核心字典表误操作TRUNCATE   
8.2脚本错误导致的灾难——数据库整体被删除故障  
第9章  千丈之堤  溃于蚁穴   
9.1  一个字符引发的灾难——大小写字符疏忽导致的维护故障   
9.2一个盘符引发的灾难——判断失误导致的误格式化故障   
9.3一个BEGIN引发的灾难   
9.4一个空格引发的事故   
9.5一个坏块引发的灾难   
9.6一个标志位的影响
9.7一个磁盘添加引发的故障——通过AMDU恢复数据的 案例一则  
第10章  物尽其用  尺有所短   
10.1关库与关机——强制关机导致的写丢失故障  
10.2从小恙到灾难——重建控制文件失误导致的故障   
10.3尺有所短,物有不足——硬件故障导致的灾难一则  
10.4  由性能问题而追溯的磁盘故障   
10.5静默错误引起的数据灾难
10.6  ORACLE的写丢失检测特性   
10.7  ORACLE 12.2的写丢失检测增强
10.8  参考资料  
附录A:BBED的说明   
附录B:函数F_GET_FROM_DUMP

数据驱动,成就未来 




以下为摘取《Oracle DBA手记4:数据安全警示录》第五章的内容:


在企业数据环境中,已经有很多DBA因为疏忽而遭受了惨痛的教训。了解和学习这些案例,可以帮助我们熟悉常见的错误种类和错误条件,进而增强规范意识、建立约束制度及制定防范措施,规避和减少技术风险,保障数据环境的安全运行。

在数据管理阶段出现的问题,被定义到管理安全的范畴里。在这一阶段,如果企业缺乏足够的管理规范,就可能出现很多安全事故,诸如误删除、Trucate数据表等。
下图列举了管理安全范畴中可能涉及的诸多方面。
 

管理安全范畴中可能涉及的诸多方面


在本章中,我们将主要描述各行业DBA遭遇的管理安全问题。从这些现实案例中总结经验,吸取教训,进而未雨绸缪,防患于未然。这也是每个致力于企业数据运营的人的职责所在。


5.1  DBA四大守则




通过分析所经历的各种案例,我们总结出了DBA生存四大守则,用于提醒DBA在工作中应当注意和遵循的内容,这些守则直至今天仍然具有其现实意义。

下面就是需要我们铭记于心的DBA生存守则。

1.备份重于一切

我们必须谨记,系统总是会崩溃的,硬盘总是会损坏的;如果没有有效的备份,迟早会有大麻烦。唯一会使DBA在梦中惊醒的事情是没有有效的备份。

DBA都应该在睡前想一想,如果那个没有备份的数据库,在今晚遭遇硬盘损毁,那么明天该如何去恢复数据和业务呢?

2.三思而后行

Think thrice before you act.

任何时候都要清楚地了解你所做的一切,否则宁可不做!

我们见过太多由于草率的操作导致的数据灾难。有时候一个回车、一条命令就会造成不可恢复的灾难。所以,你必须清楚地了解所做的一切,并且在必要时保护现场,以保证你的操作至少不会使事情变得更糟。

3.rm是危险的

要知道在UNIX或Linux环境下,执行rm意味着可能永远失去后面的东西,所以,必须要确认你的操作正确无误。

太多的人因为使用rm -rf悲痛欲绝了。当年写下这条守则,是因为在一个凌晨被一位朋友吵醒,他说因为误操作rm -rf删除了200GB的数据,并且没有备份。

我当时能告诉他的只有一句话:保持冷静,离开键盘,然后让你的领导知道这件事。

作为一名技术人员,当事情超出你的掌控时,最好的决定就是让更多的人知道这件事,通过共同的决策来制定恢复方案,以防止因为个人再次判断失误造成进一步的损失。

rm是危险的,以此类推,在数据库内部执行DROP、TRUNCATE、RESETLOGS等破坏性操作时,以及在数据库外执行DD、FORMAT等操作时,同样应当谨慎,小心一万次也不为过,疏忽一次就可能致命。

4.制定规范

良好的规范是减少故障的基础。所以,作为一名DBA,需要制定规范来约束开发人员甚至系统管理人员。这样可以规避误操作,减少数据库的风险。

而作为企业数据环境的管理人员,更应该从管理流程上制定规范,防止因管理流程不当而导致的数据安全问题甚至数据灾难。

在管理良好的数据库服务器上,rm -rf甚至是不被允许使用的。

作为DBA一定要严谨专注,在管理数据库的同时,要承担起数据责任,不能有丝毫的马虎和大意,草率的判断和轻忽的选择对数据来说很可能是致命的。

以上四大守则,愿与诸位DBA共勉。



5.2  DBA守则外四则





在本书第1版出版6年之后,当我再次思考这些重要的法则时,有两种情况十分清晰地跳跃了出来,虽然这两种情况其实可以包含在前面的四大守则之中。

1.数据库重做日志安全

在Oracle数据库中,重做日志的写入优先于数据文件。如果意外损坏数据库正在使用的日志文件,则数据库将遭受数据损失,面对这种情形,备份是无能为力的。

那么哪些情况可能导致日志损坏呢?大敌只有一个:误操作。

我们目睹了无数惨痛的案例,这些误操作包括如下情形。
•    在清理空间时,删除 .log 扩展名的所有文件,Redo日志被消灭
•    在主库同主机构建恢复环境时,遗漏了控制文件日志路径修改,RESETLOGS重置了主库日志

•    强制关闭数据库而导致的Redo日志意外损坏


当面对这种意外情况时,如果判断失误,会让情况变得更糟。此时,如果使用备份覆盖当前数据文件进行恢复,一旦Online Log没有归档,那么其中所有的事务都会丢失;如果保留当前数据文件,则丢失的数据仅限于最后提交未写入数据文件的内容。

那么如何规避这样的问题发生呢?

•    不要在生产环境下进行任何测试验证
即便是最专业的DBA,当修改控制文件时都可能有所遗漏。在主库同主机搭建备库或测试环境时,任何一个操作都是非常危险的,所以不要这样做。

•    不要批量清理任何日志文件
这个问题毋庸多说,在生产环境下进行任何操作都应该具备严格的规范。建议在建立数据库时,将Redo日志文件的扩展名改为 .dbf ,这样也许能躲过很多劫难。

•    不要覆盖任何未备份的文件
如果没有100%的信心,就不要试图通过restore恢复覆盖未备份的数据文件,因为一旦出现问题,就无可挽回了。

无数专业的DBA都曾在这个问题上遭遇“滑铁卢”,不同的数据库在日志原理上基本相同,确保日志安全就是确保数据一致性。DBA要切记。

2.数据库存储卷安全

在过去几年里,我亲眼目睹了很多与存储卷相关的数据灾难,将其归纳在这个守则中,典型情况有两大类。
•    对数据库存储磁盘误发出DD清除命令
•    将在用磁盘添加到其他磁盘组中

以上两种情况往往是级联的,很多灾难是在进行空间扩容时发生的。DBA找到新的磁盘,通过DD进行擦除,然后加入现有的磁盘组中。结果发现被擦除的磁盘是在用的数据库存储卷。

这是一种低级错误,但是在生产实践中层出不穷,造成非常严重的生产事故。

那么如何解决这类问题呢?

如果能够遵循相关规范和流程就能够避免(前提是有规范)。例如,在进行磁盘的破坏性操作时,明确根据记录去比对确认,确保被初始化使用的磁盘是空闲的;如果没有规范,DBA也应该对维护的数据库建立数据库基本信息档案,在进行重要变更时必须对比查询,以防误操作带来损失。

在Oracle 12c中,新特性ASMFD就被用于防范数据库之外的操作对数据盘的侵入破坏,这个特性在本书后面的章节中进行了详细介绍。

在《Oracle DBA手记 2》一书中,我的朋友——作者之一郭岳,在文章中曾经提出了几点DBA守则,我深以为然,并对其中两点略作引申,作为DBA守则外四则的第3点、第4点,收录在这里供大家参考。

3.高度的信息安全意识

本书的宗旨是安全,在数据安全的诸多方面里,信息安全是核心环节。DBA或相关技术人员能够接触到核心数据,虽然用于防范DBA获取数据的各种技术手段在不断发展,但是接触也就意味着责任,权利与责任从来都是如影随形的。能够访问、获取数据,并不意味着可以去利用和传播这些数据。DBA的职业道德要求大家只需完成责任范围之内的数据库维护即可,对于业务数据应当敬而远之,视而不见。

2011年,一则新闻触动了很多数据工作者的神经。陕西1400多万手机用户的信息被泄露,不法分子利用这些信息以短信推广等方式进行非法获利活动。对于运营商来说,拥有用户信息的同时也意味着要承担保护这些数据的责任,如果不能保障这些数据的安全,那么这些数据就可能被不法分子利用,去侵犯公民的个人隐私甚至经济利益。而对数据工作人员来说,接触数据的同时也要遵守职业道德和法律法规,坚决避免不必要的信息泄露和传播。

下面是这个案件的相关信息。

根据2011年9月23日的新闻报道,西安警方破获了全国首例非法出售、获取公民个人信息的案件。

据了解,这一案件导致陕西省近1400万手机用户的个人信息被泄露。

根据最后的破获结果,犯罪嫌疑人是一家科技公司的技术人员,他代表公司负责研发和维护陕西省某通信公司的计费经营系统。

2011年3月以来,他利用工作便利,多次侵入这家通信公司的用户数据库,盗取手机用户的个人信息。

2011年4月,他应另一嫌疑人的要求,再次侵入某通信公司客户数据库,窃取了西安、咸阳、铜川等7个地市1394万手机用户的个人信息。

据警方介绍,这1394万手机用户,占全省手机用户总量的60%~70%。这些信息被非法交易的背后,是利益的驱动,利益让4名犯罪嫌疑人形成了非法利益链条。警方同时指出,该案件的侦破,也暴露出通信运营商和为通信运营商提供技术支持的科技企业,都存在监督职责缺失的问题。

律师认为,盗取手机信息的技术人员,首先违反了民事法律规定,须承担相应民事赔偿责任。刑法修正案中也有涉及泄露、盗取私人信息的相关规定:非法泄露个人信息,最高可判三年有期徒刑。

国家机关或者金融、电信、交通等单位的工作人员,违反国家规定,将本单位在履行职责或者提供服务过程中获得的公民个人信息,出售或者非法提供给他人,情节严重的,处三年以下有期徒刑或者拘役,并处或者单处罚金。窃取或者以其他方法获取上述信息,情节严重的,依照前款的规定处罚。


5.3  各种惨痛的案例




我们曾经收集过DBA曾经犯过的各种错误,这些信息千奇百怪、五花八门。对于管理者来说,了解这些错误有助于制定规范、防范问题的发生;对于DBA来说,则有助于吸取教训,增长经验,防患于未然。

对于这些案例,我大多数都保留了原始的描述和记录,只做了一些简单的编辑整理和分类工作。这些案例收集自网络,与大家共为警醒。

[主备环境错误案例]

很多企业,或者很多DBA有一个不良习惯,就是他们常常忽视生产环境和测试环境的区别,他们甚至不做环境校验就草率地执行任务,结果造成很多不应该发生的灾难和错误。

下面是一系列因为混淆生产环境和测试环境而出现的错误。

一系列因为混淆生产环境和测试环境而出现的错误


针对这些情况,有以下几个建议。

1.测试环境和生产环境应当处于不可互通的物理网络中

互通就意味着可以同时访问,也就可能带来很多意想不到的安全风险。企业应当将测试环境和生产环境部署于不可互通,或不可同时访问的网络环境中,避免因为错误连接而发生的数据库灾难。

分离部署一方面可以降低误操作的可能性,另一方面也可以屏蔽一些无关的访问可能,从而从网络链路上保证数据安全。

2.在执行任务之前确认连接访问的数据环境

通过查询数据库的视图(v$instance和v$database)就可以获得数据库的主机、实例名称等信息。



SQL> select instance_name,host_name from v$instance;
INSTANCE_NAME    HOST_NAME

---------------- ------------------------------

ORCL             hpserver2.enmotech.com



在执行任何重要的任务之前,都应当明确确认连接的环境是正确的。这应当成为DBA的习惯。

3.避免打开过多的窗口,防止操作错误

在执行任务时,要保持尽量少的打开窗口。我经常见到工程师的桌面有众多凌乱的窗口同时打开着,混乱与错误同行,尤其是在通宵加班等情况下。

保持简洁、清晰的工作界面,是一个工程师应当具备的基本素质。

4.在执行重要任务时应保持良好的状态

良好的状态是高效率和高质量工作的保障。如果是夜间工作,应该保证有充足的睡眠,以清醒的头脑面对重要的工作;并且一定要避免在疲劳状态下连续工作,疲劳作战是对自己和数据的不负责任。

5.避免匆忙之下进行重要的工作或决定

很多误操作都是因为急着下班,急着回家,临门一脚导致的失误。所以当我们去执行一项工作时,应当保持平和的心态,避免仓促紧急地做决定。

6.测试环境和生产环境的密码不能相同

有些测试环境或非生产环境是利用生产环境恢复得到的,DBA往往在建立测试环境后,不去修改数据库用户的登录密码;通常,DBA也习惯在所有环境中设置通用的密码。这些习惯为系统带来了很多风险和不确定性。

我们建议用户在不同环境中设置不同的密码。这是因为一方面生产环境和测试环境面对的访问用户不同,密码相同则意味着生产环境的安全性完全得不到保障;另一方面,DBA登录不同的数据库如果使用相同的密码,就进一步增加了DBA在错误的环境下执行命令的可能性。

[业务高峰期误操作案例]

在维护生产环境时,尤其是负载极高的核心生产环境,我们需要注意的是,每一个操作都可能导致系统负载波动,甚至产生严重的性能问题。

下面这些案例就是一些因在业务高峰期进行贸然操作而导致的数据库问题。
 

因在业务高峰期进行贸然操作而导致的数据库问题


因在业务高峰期进行贸然操作而导致的数据库问题


DBA经常在深更半夜工作,而且有时是连续作战。为了防止因疲劳引起的误操作,在工作前要先把步骤理一遍,具体到每一个命令。如果有测试环境,要先在测试环境下执行一遍。然后就照着这个步骤做,最好是复制粘贴。操作时,要关闭其他SHELL窗口,将操作窗口的日志保存。这样操作过程都可以记录下来,如果在操作过程中发生意外,也不至于漏掉要做的步骤,总体操作是可控的。工作完成后,写报告也比较方便。

强烈建议使用ISO 9000的管理方法:记下要做的,按所写的做,写下所做的。

种种案例表明,我们应当严格遵守生产环境的维护守则,以避免产生不必要的业务影响和数据灾难。

1.高峰期禁止在数据库中执行DDL操作

DDL操作会导致一系列的SQL重解析、依赖对象失效等数据库连锁反应。一旦SQL重解析集中出现,系统必然会经历负荷峰值;如果系统繁忙,可能会就此挂起;DDL导致的依赖对象失效,甚至无法编译通过,可能长时间影响业务系统的正常运行。
所以,在生产环境中,应当严格禁止高峰期的DDL操作,避免因为操作不当或考虑不周带来数据库灾难。

2.慎重进行统计信息收集和索引创建等

统计信息收集和索引调整是优化数据库的常用手段。可是要切记,在业务峰值期间进行统计信息收集,或收集之后导致不可预期的执行计划改变,都可能使数据库瞬间停滞;而贸然添加的索引,也有可能导致其他SQL执行计划的恶化。

所以,在生产环境中,统计信息的收集或索引的增减,都应当是非常慎重的。要避免因为考虑和或测试不周全而带来额外的麻烦。

[备份级误操作案例]

我们曾经反复强调:备份重于一切。但很多人在执行备份时,也会遇到因备份而导致的误操作故障。

下面是一些与备份相关的误操作和灾难的案例。
 

与备份相关的误操作和灾难的案例


总结这些故障,我们有下面几点经验。

1.所执行的操作系统命令需要经过测试

很多操作系统级别的命令在执行时都具有一定的风险,如rm、mv、tar等,如果不理解这些命令的具体含义和参数的意义,就可能犯下无法挽回的错误。

所以,对于需要执行的每条命令,都要经过测试,确保其有确定的输出结果,然后才去执行它。如果对某个命令没有把握,那就永远不要去执行它。

2.执行备份并进行备份检查

很多企业觉得有了备份就高枕无忧了,可是备份和有效备份是两回事。我们一定要检查备份成功与否,备份是否有效,这样才能保证在危急关头有“备”无患。

3.使用文档手册,完善操作流程

在执行任务之前,准备文档手册,通过测试验证其可行性。并且在执行命令时按照文档操作,确保不会节外生枝。

俗话说:台上一分钟,台下十年工。只有在台下做好准备,在台上的一分钟表演才能流畅完美;而如果台下只花一分钟准备,那么台上的收尾恐怕就要“十年工”了。

所以,要多做些准备工作,磨刀不误砍柴工。

[进程级别误操作案例]

很多维护工作涉及进程级别的一些操作,强制终止进程是很多DBA都做过的事情,不过一旦出现失误,终止的进程出现问题,就会为数据库带来麻烦。

最常见的是误终止了后台进程,还有进程跟踪生成的大量进程转储信息引发空间耗尽。
下面是一些常见的案例。

进程级别误操作案例


这些案例给我们的警示如下。

1.明确区分后台进程和用户进程

数据库的后台进程是维持数据库正常工作的必要进程,如果误操作kill了重要的后台进程,那么数据库可能会立即崩溃。所以一定要注意区分后台进程和用户进程的区别。
通常数据库的核心后台进程是SMON、DBWR、LGWR、CKPT、PMON等,一旦异常终止就会导致数据库崩溃。

2.要反复确认后再执行操作

对于终止进程的命令,要反复确认后再执行。并且要注意,如果进程正在执行特定的操作,例如索引重建、TRUNCATE数据表等,意外中断可能导致严重的数据库内部错误。

所以,应当通过系统级别的跟踪命令对进程堆栈进行跟踪确认后再进行操作,并且要在强制终止进程时,做好应对异常的准备。

[数据文件误操作案例]

在数据库的文件维护中,如果处置不当,也可能带来很多灾难,本书就包含多个与文件离线相关的复杂案例。

下面是一些DBA犯下的与文件相关的错误。
 


数据文件误操作案例

总结这些案例,带给我们的警示如下。

1.文件命名需要遵循规范

在Windows系统上的文件名不区分大小写,这一和UNIX系统截然相反的做法,使很多Windows用户在UNIX系统上犯了不少错误。

所以,对于数据库文件来说,一定要遵循统一的命名规范,避免发生因为不规范带来的故障。当添加文件时,需要根据规范进行添加,以维持命名的一致性和规范性。

2.对于裸设备的处理要反复确认

由于裸设备上的文件在文件系统中不可见,所以在处理裸设备文件时一定要反复确认,确保遵循正确的操作步骤,按文档、按规范进行操作。

此外,系统管理员和数据库管理员要加强沟通,明确哪些裸设备在用及其用途。曾经有一个案例,裸设备被误操作格式化后,才发现有数据文件存储于裸设备上。

3.如果有可能尽量选择ASM或文件系统

由于裸设备已经退出Oracle的支持序列,所以应当适当的将裸设备上的数据库转移到文件系统或ASM上。ASM是较好的选择,但是仍然需要专业的学习和维护才能够被良好地使用;而文件系统对于普通用户来说是方便维护的。

根据不同的用户选择合适的技术非常重要。

[误关闭生产库案例]

很多DBA还经历过误操作关闭主机或生产库的情况,这种误操作绝对是刻骨铭心的,往往一个回车键按下去,就为时已晚。

下面是一些典型的因误操作而关闭主机和服务器的案例。




误关闭生产库案例

误关闭生产库案例



总结这些常见的案例,我们得出以下警示。

1.尽量避免层层跳转的服务器登录方式


虽然很多企业的数据环境通常都要经过层层跳转才能够访问,但是不可避免地,跳转的次数越多出错的可能性也就越大。所以应当尽量减少跳转次数,禁止从一个主生产节点跳转到另一个主生产节点。

在操作时,也应当通过hostname等方式确认所连接的服务器主机是否正确。

2.完成操作后尽快退出生产服务器

当在生产服务器上完成工作后,应当尽快退出,以防止因其他工作的干扰而出现误操作。尤其是当离开计算机时,应当退出或锁定操作界面,防止他人误操作。

3.经常确认服务器、数据库和路径标识

应当经常确认主机名称、当前路径、数据库名称等信息,防止无意识的误操作。尤其是当重新或临时接触操作终端时,如果不能明确看到服务器或数据库标识,则应当首先查看这些信息。

下面这些常见的命令行操作应当成为DBA的下意识的“条件反射性”操作。


[oracle@hpserver2 ~]$ hostname
hpserver2.enmotech.com
[oracle@hpserver2 ~]$ pwd
/home/oracle
[oracle@hpserver2 ~]$ ps -ef|grep smon
ora11g    1484     1  0  2011 ?        00:02:05 ora_smon_eygle
oracle    5200 14397  0 15:14 pts/3    00:00:00 grep smon
[oracle@hpserver2 ~]$ id
uid=505(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)



[系统存储级误删除案例]

除了在数据库层面上,在主机、操作系统、存储层面上也有很多典型案例。如果不够谨慎,在主机网络层面上的误操作也可能对系统产生致命的影响。

下面是一些操作系统和存储级别的误操作案例。
 

系统存储级误删除案例


系统存储级误删除案例



下面是来自这些案例的警示。

1.超级用户和数据库用户要严格分离

在生产环境中,不应该给DBA以root权限,以防止操作不当给整个系统带来不良的影响。即使DBA很了解系统,但是还是需要有系统管理员去执行系统层面的维护工作。

2.事关存储无小事

存储最终容纳着用户的所有数据,所以针对存储的任何操作都不能草率,当增减硬盘、格式化分区时,都要严格进行磁盘确认、分区比较,避免因为误操作而“釜底抽薪”。

3.电源即Power

电源也就是Power,是所有动力的来源。所以当中断电源时,系统的所有环境都可能遭受影响。在面对电源问题时,应当慎之又慎。因为断电而导致数据库无法启动的案例比比皆是,不要让数据库因为电源问题而崩溃。

在本章中,我们采集了大量的实践案例,希望能够通过这些案例给读者一些警示。作为技术人员,要努力提升知识技能,避免让自己陷入危险的操作事故中;而作为企业的管理者,则要不断思考如何通过规则、制度、产品去阻止类似问题的出现,避免遭受误操作的损失。

改善服务品质,创造服务价值,这是企业运维的使命和职责所在。不断思考,不断改进,才能使得企业在信息化时代立于安全之地。

5.4  参考资料

http://china.cnr.cn/xwwgf/201109/t20110901_508447708.shtml