DBA三思而后行

1:測試環(huán)境和正式環(huán)境物理分析，不要既開測試的維護(hù)窗口，又開生產(chǎn)的窗口

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

OS操作

1:rm

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

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

如何規(guī)避：用mv 代替 rm 先到臨時位置

but mv也有一個很嚴(yán)重的問題：如果將一個文件移到一個已經(jīng)存在的目標(biāo)文件中，則目標(biāo)文件的內(nèi)容將被覆蓋。

解決辦法 mv -i dsw.ora /home/oracle/ 

同樣在cp -a 也存在這個問題，cp前務(wù)必檢查目標(biāo)目錄是否有同名文件

rm 后面不寫*

2：chmod 755 -R / home/oracle

同樣是空格的問題，修改權(quán)限，chmod chown 也務(wù)必檢查文件目錄是否多寫的空格

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：執(zhí)行腳本，務(wù)必檢查，腳本名稱帶上日志和說明

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

DB操作

1：dml的update delete丟失where 條件 

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

3：業(yè)務(wù)高峰時候不得執(zhí)行ddl

（1）ddl導(dǎo)致一系列的 SQL 重解析，依賴對象（procedure）失效等數(shù)據(jù)庫連鎖反應(yīng)，一旦 SQL 重解析集中出現(xiàn)，系

統(tǒng)必然經(jīng)歷負(fù)荷峰值，如果系統(tǒng)繁忙，可能就此掛起；

（2）任何ddl的變化都需要check這個對象可能被引用的對象

4：慎重進(jìn)行統(tǒng)計信息收集和索引創(chuàng)建

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

online 的時候失敗，到白天業(yè)務(wù)高峰期間 smon 還在清理臨時段，業(yè)務(wù)堵塞

5：防止索引失效：分區(qū)維護(hù)導(dǎo)致索引失效

6：忘記關(guān)閉跟蹤磁盤占用導(dǎo)致系統(tǒng)hang

慎用 alter system 級別的跟蹤

7：kill -9 千萬要確認(rèn)，不要kill掉后臺進(jìn)程