语言
<< 返回文章列表

抢先下载:《Oracle DBA手记4》7-17/17 部分

2018年9月7日
盖国强
1917

相关链接:1/17 http://www.enmotech.com/web/detail/1/580/1.html

                 2/17 http://www.enmotech.com/web/detail/1/581/2.html

                 3/17 http://www.enmotech.com/web/detail/1/582/2.html

                 4/17 http://www.enmotech.com/web/detail/1/585/1.html

                 5/17 http://www.enmotech.com/web/detail/1/586/2.html

                 6/17 http://www.enmotech.com/web/detail/1/587/2.html

                 7-17/17 http://www.enmotech.com/web/detail/1/589/1.html


文末有下载方式:

数据库误删除案例

有些威胁来自数据库外部,而有些威胁则来自数据库内部,对于数据库外部,破坏性的操作有 rm ,而在数 据库内部,同样有破坏性操作,如 Truncate.


分析总结以下的种种灾难,我们做出以下建议:

1. 通过触发器约束或禁用特定的 DDL 操作,防范数据库风险

对于 TRUNCATE 等高风险的数据库 DDL 操作,可以考虑通过触发器进行禁用,防止未授权的操作损害数

据。

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

2. 严格进行权限管理,以最小权限原则进行授权

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

3. 明确用户职责,加强用户管理 

应当明确不同的数据库用户能够用于的工作范围,应当使用普通用户身份的,就绝对不应该使用 DBA 的

用户身份,只有职权相称,才能够避免错误。 

即便是拥有管理员职责的用户,也应当遵循以不同身份执行不同任务的习惯,比如 SYS 和 SYSTEM 用户

的使用就应当进行区分和界定

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

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


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

不论操作系统级别还是数据库级别的删除操作,尽量以重命名替代删除,如重命名数据表,重命名数据文 件,然后通过一段时间的观察和确认后再彻底删除。

Oracle 10g 中引入的回收站功能,就是将我们执行的 DROP 操作变更为重命名进行保护,当我们发现了失

误之后,可以通过回收站找回,但是注意回收站保存对象的时间和空间有关,如果存储空间不足,对象会被自 动释放。

我们在管理中借鉴这个回收站思想是很有帮助的。 

6. 尽量争取充足的时间

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

7. 审核你的剪贴板

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

审核你的剪贴板,确保其中的内容是你期望的。

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

对于 DBA 来说,如果一个脚本你从来没有认真读取了解过,就不要去执行,脚本中的一个错误就可能导

致严重的数据灾难。我们遇到过案例,由于脚本中的一个变量错误,导致所有数据文件被删除,教训惨痛。 

如果实在无法审核脚本的内容,那么在进行重要操作之前,备份你的数据。


通过触发器实现 DDL 监控

关于建议 1 中提到的触发器监控,以下我们将做详细的介绍和说明。 

如下触发器实现对于特定表的 DROP、TRUNCATE 防范:


主备环境错误案例

很多企业,或者很多 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 在错误的环境下执行命令的可能性。


《Oracle DBA 手记4》9-17.pdf

《Oracle DBA 手记4》7-17.pdf

《Oracle DBA 手记4》10-17.pdf

《Oracle DBA 手记4》12-17.pdf

《Oracle DBA 手记4》13-17.pdf

《Oracle DBA 手记4》14-17.pdf

《Oracle DBA 手记4》8-17.pdf

《Oracle DBA 手记4》11-17.pdf

《Oracle DBA 手记4》16-17.pdf

《Oracle DBA 手记4》15-17.pdf

《Oracle DBA 手记4》17-17.pdf