前言

不知不覺，技術人生系列·我和數據中心的故事來到了第十期，小y又和大家見面了！

前期我們分享了不少Oracle數據庫故障和優化的實戰案例，有朋友問，小y是否可以分享一些無備份時數據恢復方面的實戰案例呢？

答案自然是——當然可以了。小y從來就不是一個藏著掖著的人嘛 ^_^

這些年，小y所在的Oracle服務團隊，該遇到的和不該遇到的問題，基本都碰到了。

所以在無備份的數據恢復這方面做的案例還是很多的，有時一周甚至要做三四個這樣的CASE，問題類型不盡相同，例如：

>> 某電信運營商文件系統滿，維護人員清理了在線日誌文件導致數據庫無法啟動…

>> 某電信IDC機房掉電，Oracle數據庫損壞無法啟動…

>> 某基金客戶將數據庫用戶誤刪除drop user xx cascade….

……

小y從內心覺得，“沒有備份的數據恢復案例”確實不太好拿出來分享，畢竟這樣的故障對客戶而言是不光彩的事情，如果敏感信息沒有被處理的很幹凈，就怕客戶對號入座，給自己找麻煩，所以一開始也就沒有分享類似案例的念頭了。

但是轉念一想，如果可以把共性的風險提煉出來，不僅可以從技術層面從給大家做一個提醒，還可以從如何完善數據庫運維體系的角度給出建議，那麽這種案例分享就變得有意義了！

這裏補充一點，有朋友可能會好奇的問,”像接到這種CASE，客戶已經絕望，你們可以獅子大開口，開個高價，一定不少賺吧?!”

實際上，很多情況下，按照中亦科技的風格和理念，我們是服務於企業客戶的，是要做口碑的，從和客戶（或潛在客戶）長遠合作的角度來考慮，這種CASE我們大部分都是給客戶免費做的（沒讓你失望吧）。要收費也是看損壞程度和人力投入，我們報的絕對是良心價（低到不好意思說），畢竟客戶都已經很難過了……如果趁機狠狠的宰上一筆，那麽也就是一錘子買賣，後續基本不會再有長久合作了，這是不符合我們的服務理念的。

本期分享主題：

分享一個Oracle變更導致數據丟失的案例，然後啟發大家思考這樣一個問題，

你的Oracle 數據庫運維體系真的完善麽？

小y今天就為大家奉獻這麽一個真實的案例。分享的最後，除了進行技術風險的提示，我們還將就如何建設科學運維體系的話題給出中亦科技的觀點，希望能對大家有所幫助。

案例分享的意義：

小y發現一個問題，就是別人不管再怎麽做風險提醒，很多客戶還是會犯一樣的錯誤！

即使他知道別人已經遇到過的這個問題！

為什麽他知道這個問題、這種風險，但是他還是犯了同樣的錯誤呢？因為他沒有切身之痛！如果只是在看別人的笑話，沒有行動起來，從運維體系的角度做出整改，那麽後續就很可能會出現類似的問題。小y希望讀者朋友，可以領會小y每一次分享的精髓和良苦用心，做到由點帶面，從運維體系的角度出發進行整改和預防，這樣一來也就沒有浪費小y的一片苦心。

先思考一個問題：

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

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

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

這麽做到底有沒有問題呢？看完小y接下來分享的具體案例，您就明白了：）

Part 1

問題來了

悲劇出現

一個潛在的客戶發現訪問256號文件上的數據時報錯，256號文件無法被訪問。

進一步檢查因為文件被offline，需要做recover。

並且該文件無法再online起來,原因是缺少歸檔日誌，無法做recover。

於是向小y求救。小y心想，無非是兩種情況

1） 是不是歸檔日誌備份到磁帶上了

2） 該歸檔日誌被刪除了

如果是第一種情況，那麽就簡單了，只需要從磁帶上恢復回來即可！

如果是第二種情況，那就糟糕了，可能要丟數據了！

沒關系，我們不惹事，事來了我們也不怕。

我們先來看下客戶online數據文件的操作過程：

1.1 文件online

256號文件的online操作,顯然oracle會提示該文件需要做介質恢復即media recovery。因為文件在offline的時候（不管什麽原因）不會把該文件所對應的臟塊刷到磁盤中。

1.2 Recover 數據文件

於是客戶做了recover datafile 256的操作，並輸入AUTO,但是數據庫提示找不到序列號為14389的日誌文件

1.3 查看報錯信息

操作系統上檢查，該日誌文件也不存在

1.4 歸檔日誌去哪了

是不是備份到磁帶上以後，在文件系統上被刪除了呢？

檢查rman的備份情況，發現節點1所需要的歸檔日誌根本沒有任何備份的記錄！

這下悲催了！256號文件online所需要的的歸檔日誌已經被刪除!數據可能要丟失了！

Part 2

事故時如何發生的

一個小變更怎麽會導致這樣的狀況

經了解，這是一個IBM AIX上的10g RAC環境，數據文件采用裸設備。

客戶最近剛為RAC做了一次表空間加數據文件的“小”變更！

那麽文件被offline，以及歸檔日誌找不到了，這兩個問題的出現和這次變更有直接的關系麽？給表空間加個數據文件，這樣的變更也會導致數據丟失麽？

也許你會覺得不可思議，不過小y基本已經猜到了過程。不同的地方總在上演著類似的悲劇。

到這裏，建議讀者朋友們可以先停一下，思考一下變更和這兩個問題的關聯！以及思考一下，如果是你，你接下來會協助客戶怎麽繼續處理呢？

Part 3

劇情重現

為什麽文件被offline&歸檔日誌沒了？

其實很簡單，我們直接來看變更過程和問題出現的整個過程:

3.1 變更“成功”

1月4日11:50分左右，客戶發起了變更。在RAC第二個節點為某個表空間添加了兩個數據文件，並且添加成功。Alert日誌顯示Completed。變更“成功”

3.2 真的成功了麽？

但是變更真的成功了麽？變更做的利索麽？

15:07分，節點1 在做checkpoint的時候，需要更新每個數據文件頭的SCN號，但是由於新加的裸設備的操作系統權限不對，出現IO報錯。顯然，這是一個典型的RAC忘記修改一個節點權限的問題。這麽多ORA-報錯，如果這個時候發現並處理，那麽一切還來得及！只是..沒有可是了…

3.3 數據文件強制offline

15:07分，節點1由於裸設備的權限問題，checkpoint無法寫文件頭的SCN，因此新加入的兩個數據文件被強制offline. 這麽多ORA-報錯，如果這個時候發現並處理，那麽一切還來得及！只是..沒有可是了…

3.4 發現問題

過了N個小時，當節點1訪問這兩個文件中的數據開始報錯時，客戶開始意識到問題的嚴重性了！從視圖v$recover_file中可以看到，file_id為256和257的兩個文件處於offline狀態。

發現裸設備權限忘記修改的問題後，客戶修改了節點1的裸設備的權限並且執行alter database datafile ‘/dev/xxx’ online數據文件時，提示需要做recover。

檢查發現節點1文件被offline期間的的歸檔日誌在文件系統已經被刪除，rman還沒來得及備份，再也無法恢復！

那麽是什麽原因導致歸檔日誌被刪除了呢？

還記得我們在文章一開始“前言”部分的下面這段話麽？

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

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

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

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

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

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

到這裏，你是否還覺得為了避免數據庫hang而刪除歸檔日誌，事後再發起全備的做法是一個安全的做法呢？答案顯然是否定的！小y相信，90%以上的DBA在刪除歸檔日誌的時候是不會去查看v$recover_file中是否存在需要恢復的文件的！

Part 4

還有救麽？

怎麽解決？

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

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

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

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

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

4.1 檢查SCN

檢查v$datafile_header, 19號文件狀態是offline,SCN和其他文件不一樣

丟失日誌的情況下，要想把文件online起來，只能騙過數據庫，我們只要把19號數據文件的文件頭上的SCN改成和其他文件比如17/18號文件一樣就可以。

4.2 確定SCN

SCN號存在每個文件文件頭（塊號是1）的kcvfhckp.kcvcpscn這個結構當中，藍色代表輸入的命令，如下所示，紅色部分即offset 484往後的4個字節表示SCNBASE，用16進制表示，我們將其用計算器轉變為 10進制後，得到的數就是上圖v$datafile_header的SCN。

4.3 註意字節存放高低位順序

下圖采用dump命令顯示的的SCN號是 a883d301（見下劃線）和上圖中的

剛好是按照字節高低位相反的。

4.4 修改SCN

采用modify命令將19號文件的文件頭上的SCN改成和其他文件比如17/18號文件一樣，並重新計算校驗值,最後verify確認BLOCK沒檢出異常就改完SCN了。

再次檢查v$datafile_header,可以看到已經將19號文件已經被我們改成和其他文件SCN一樣。

4.5 數據文件online

recover datafile後online起來，修復完成

Part 5

這是重點

故障原因總結:

本次案例中，為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還是數據丟失？答案是顯而易見的。歸檔空間不夠，這需要從空間規劃來入手，不行就預留七天的空間。數據的安全比廉價的存儲空間更重要

運維是一門科學，你不可能遇到所有的問題，所以就需要一個科學的運維體系來減少問題出現的概率！也歡迎大家和小y就如何構建科學的運維體系進行討論。

一次導致數據丟失的小變更