开发者平台
开发者平台 您当前的位置:主页 > 开发者平台 >
如果误删了数据库,该怎么办?这篇文章来帮你!
发布时间:2018-09-30 编辑:AG88

有时候,会遇到误删数据库的情况,比如,误删了用户,误删了数据表,这个时候该怎么办呢?不要着急,这篇文章来帮你!

误删除数据表

原来接手一个部门的所有数据库,结果漏了一个,也没人告诉我,所以我不知道这个数据库存在。一天一个程序人员误按了一个按钮,把大量的数据全部删除,找到我后,发现数据库没有归档,也没有任何备份。结果是程序人员补了几天的数据,奖金也直接泡汤。

误删除用户

刚从事DBA不久,可已经犯了个让我终生难忘的错误。原本是要将测试环境的一个user给删掉,由于桌面上开了多个窗口,结果drop user XXX cascade,直接将正式环境的一个user给drop了,刚按下enter,就感觉怪怪的,心想不会吧!!已经来不急了,还好这个user的信息是从另外一台服务器上同步过来的,要不然死定了。以后做什么动作我都习惯先看看是在哪个DB上那个服务器上,千万别搞错了。

误删除表数据

以前公司,有一个程序员写好的脚本,一个实施人员去执行,脚本里面带了 delete * from xxx; commit; 啥备份,归档都没有。结果我们公司全部人员出动,抱着笔记本,台式机,去北京某区县所有的机关单位上门录了一星期人员信息。至今记忆犹新。

误删除数据表

测试环境导出的腳本中包含drop語句,結果看都沒看就直接在生產環境中做了,一下子物料表就沒了,整个生产停线,后来做了恢复,丢了半天的数据。教训:执行的脚本一定要认真检查。

参考建议

1.通过触发器约束或禁用特定的DDL操作

对于TRUNCATE等高风险的数据库DDL操作,可以考虑通过触发器进行禁用,防止未授权的操作损害数据。 很多轻忽的数据灾难都来自于Truncate,这个类似于系统级别的rm命令极具破坏性,而且DDL不可以回退,即便发现已经为时过晚。所以我们建议用户可以考虑使用DDL触发器来禁用Truncate之类的危险操作,以达到安全防范的目的。

2.以最小权限原则进行授权

过度授权即是为数据库埋下安全隐患,在进行用户授权时一定要遵循最小权限授予原则,避免因为过度授权而带来的安全风险。

3.明确用户职责

应当明确不同的数据库用户能够用于的工作范围,应当使用普通用户身份的,就绝对不应该使用DBA的用户身份,只有职权相称,才能够避免错误。 即便是拥有管理员职责的用户,也应当遵循以不同身份执行不同任务的习惯,比如SYS和SYSTEM用户的使用就应当进行区分和界定。

4.在任何数据破坏之前进行备份

在进行数据表的截断、删除之前,进行备份,将备份养成一种习惯,这样才能够避免误操作之后的措手不及。

5.以重命名代替删除操作

不论操作系统级别还是数据库级别的删除操作,尽量以重命名替代删除,如重命名数据表,重命名数据文件,然后通过一段时间的观察和确认后再彻底删除。 Oracle10g中引入的回收站功能,就是将我们执行的DROP操作变更为重命名进行保护,当我们发现了失误之后,可以通过回收站找回,但是注意回收站保存对象的时间和空间有关,如果存储空间不足,对象会被自动释放。 我们在管理中借鉴这个回收站思想是很有帮助的。

6.尽量争取充足的时间

不要低估任何一次简单的维护操作,因为一个意外就可能大幅延长你的维护时间。所以,应当尽量争取充足的时间,包括做好充足的准备工作,加快无关紧要步骤的执行,减少不必要的时间消耗,时间越充裕,你用来应对可能出现的故障的时间就越多。

7.审核你的剪贴板

很多错误是由于粘贴剪贴板的内容引起的,所以,当你准备向一个窗口或者命令行粘贴你看不到的内容时,提高你的警惕性。在Windows上,有很多剪贴板增强工具,可以帮助我们记录和展现剪贴板的内容,可以考虑选用。 审核你的剪贴板,确保其中的内容是你期望的。

8.没有认真看过的脚本就绝不要执行

对于DBA来说,如果一个脚本你从来没有认真读取了解过,就不要去执行,脚本中的一个错误就可能导致严重的数据灾难。我们遇到过案例,由于脚本中的一个变量错误,导致所有数据文件被删除,教训惨痛。 如果实在无法审核脚本的内容,那么在进行重要操作之前,备份你的数据。


本文源自: AG环亚集团官网

Copyright © 2005-2016 http://www.letskungfu.com AG环亚集团官网_AG亚游平台_AG8环亚集团_新浪新闻版权所有 AG环亚集团官网_AG亚游平台_AG8环亚集团_新浪新闻