你的系統中是否還存在著類似下面這樣一個處理邏輯的腳本呢？

為了避免歸檔日志來不及備份到磁帶從而將歸檔文件系統撐滿繼而導致數據庫hang，很多客戶的系統中往往存在這樣的一個腳本，當歸檔文件系統使用率達到60%的時候，啟動腳本備份日志到帶庫，當歸檔日志使用率超過90%，刪除歸檔日志，并且發出報警信息，提示歸檔日志被刪除，需要盡快進行一次全備！

看上去這么做無可厚非啊，有問題么？

這么做到底有沒有問題呢？ 

沒錯，客戶的系統中就存在著這么一個腳本！

由于備份到磁帶不正常，導致歸檔日志文件系統使用率達到閥值，繼而觸發了腳本刪除歸檔日志的操作！再加上變更時忘記修改一個節點裸設備權限的“巧合”，導致了悲劇的發生！

怎么解決？

這種情況下，有辦法把數據文件online起來么？（當然也可以用抽取軟件直接抽取數據）

小y這么問，自然是有辦法，而且方法很簡單（不到5步）。

用bbed將被offline文件的文件頭的SCN改到和其他數據文件SCN一致即可，做起來也就幾分鐘，大家下來不防可以自己試一下。需要說明的是，這不過是一種騙過數據庫一致性檢測的方法，丟失了日志文件，數據丟失是不可避免的！

使用bbed修改數據文件頭SCN時，唯一要小心的是修改時注意不同平臺字節序的問題，linux平臺是小字節序，高低位是相反的。

這里小y以自己環境的19號文件被offline后并且online需要的歸檔日志已經被刪除的情況為例，來說明處理的過程。

故障原因總結:

本次案例中，為Oracle RAC表空間添加數據文件的一個變更，由于在一個節點忘記修改權限，導致數據文件被offline,后來歸檔日志由于文件系統使用率的原因，被腳本自動刪除，從而導致了數據丟失的悲劇。通過bbed可以在沒有日志文件的情況下把文件online起來，但是數據丟失是不可避免的！

中亦科技關于建設數據庫科學運維體系的建議：

相信大家有一個共識，那就是“變更是導致故障的重災區”。

運維無小事，變更無大小。

小的變更，往往因為熟練、輕視而沒有充分準備詳細的變更步驟。憑經驗做事，加上熬夜疲憊、精神松懈等原因，很容易遺漏一些小的細節而導致大禍。

確實是這樣的。

變更由人來操作（不可能用自動化運維手段來實現全部變更），是人就一定會有犯錯的幾率，即使是雙人復核，也不能完全避免，而且真正長期做到變更雙人復核的客戶，絕對是少數。

那么，建設一套科學的運維體系就顯得尤為重要了！

科學的體系下可以減少問題出現的概率。

以運維中的變更環節來舉例，從方法論上來說，小y建議：

1、  梳理所有的變更

2、  梳理所有變更的風險點

3、  針對每個風險點，縷出對應的可行性解決方案

4、  解決方案從原則上說，是需要獨立于現場實施人員的

具體到今天所分享的這個案例，小y認為有很多值得改進的地方：

1、  對于采用裸設備的RAC環境，缺少對于每個節點數據文件在OS上權限的監控

如果有這樣的一個監控點，很快就可以發現節點1忘記修改權限，那么也就不會被offline了，也就不會出現由于數據丟失引發的故障了

2、  缺少對v$recover_file的監控

如果有這樣的一個監控點，很快就可以發現文件被offline的情況，及時online起來就可以解決。另外，Online這個動作是否可以做成自動化呢？

3、  缺少對alert日志ORA-錯誤的監控或及時處理的機制

監控點的級別設置是否準確呢？同樣是ORA-錯誤，預警則很容易被忽略；而嚴重則會發送短信通知。例如，小y有些同事在數據中心，每天需要輪著值班，對著監控的告警，逐條確認和分析、處理，以確保不被遺漏，從而保障業務的連續性。

4、  缺少對備份的監控或（和）及時處理機制

如果發現備份不成功的問題，例如備份作業太多導致排隊，那么可以通過錯峰、增加帶機等形式，也就不會出現歸檔日志超過閥值得情況了。

5、  系統中無論如何也不應該存在刪除歸檔日志的腳本

不刪除怎么辦呢？數據庫會hang啊？你是接受數據庫hang還是數據丟失？答案是顯而易見的。歸檔空間不夠，這需要從空間規劃來入手，不行就預留七天的空間。數據的安全比廉價的存儲空間更重要