DBA三思而后行

1:测试环境和正式环境物理分析，不要既开测试的维护窗口，又开生产的窗口

===================================================================

OS操作

1:rm

著名的一个《一个空格的血案》

- rm –rf /usr /lib/nvidia-current/xorg/xorg
+ rm –rf /usr/lib/nvidia-current/xorg/xorg

如何规避：用mv 代替 rm 先到临时位置

but mv也有一个很严重的问题：如果将一个文件移到一个已经存在的目标文件中，则目标文件的内容将被覆盖。

解决办法 mv -i dsw.ora /home/oracle/ 

同样在cp -a 也存在这个问题，cp前务必检查目标目录是否有同名文件

rm 后面不写*

2：chmod 755 -R / home/oracle

同样是空格的问题，修改权限，chmod chown 也务必检查文件目录是否多写的空格

3：tar解压，如果存在同名对象将覆盖

[root@parnassusdata1 haha]# ls
a1  a2  a3  d.tar
[root@parnassusdata1 haha]# cat a1
555555555555555555555558888
[root@parnassusdata1 haha]# tar xvf d.tar 
a1
a2
a3
[root@parnassusdata1 haha]# cat a1
8888

4：执行脚本，务必检查，脚本名称带上日志和说明

==================================================================

DB操作

1：dml的update delete丢失where 条件 

2：ddl中的drop、 truncate 先备份后操作

3：业务高峰时候不得执行ddl

（1）ddl导致一系列的 SQL 重解析，依赖对象（procedure）失效等数据库连锁反应，一旦 SQL 重解析集中出现，系

统必然经历负荷峰值，如果系统繁忙，可能就此挂起；

（2）任何ddl的变化都需要check这个对象可能被引用的对象

4：慎重进行统计信息收集和索引创建

（1）alter index rebuild online（大表慎用）

online 的时候失败，到白天业务高峰期间 smon 还在清理临时段，业务堵塞

5：防止索引失效：分区维护导致索引失效

6：忘记关闭跟踪磁盘占用导致系统hang

慎用 alter system 级别的跟踪

7：kill -9 千万要确认，不要kill掉后台进程