第一章 技術人生系列 ·我和資料中心的故事(第十期)·運維無小事之一次導致資料丟失的小變更

中亦安圖 | 2016-04-08 22:05

前言

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

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

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

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

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

>> 某電信運營商檔案系統滿，維護人員清理了線上日誌檔案導致資料庫無法啟動…

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

>> 某基金客戶將資料庫使用者誤刪除drop user xx cascade….

……

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

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

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

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

這裡引用中亦安圖自身Oracle技術專家老貓的一張圖片：

本期分享主題：

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

你的Oracle 資料庫運維體系真的完善麼？

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

案例分享的意義：

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

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

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

先思考一個問題：

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

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

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

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

如果覺得網頁版太長讀的不過癮，我們還提供PDF版本的下載，如何獲得電子版pdf以方便閱讀，請點選文章最下方“閱讀全文”申請，填寫個人資訊後，我們後續將第一時間傳送電子版的pdf到您的郵箱，前100名會優先獲得前九期的PDF 版本分享。

如果覺得分享的案例還不錯，麻煩親們抬手轉發一下,希望可以提醒和幫助到更多的客戶。

更多Oracle資料庫實戰經驗分享和風險提醒的首發，盡在“中亦安圖”公眾號！歡迎關注。

有什麼技術難題也可以給小y發郵件，郵箱是 51994106@qq.com,或者加小y的微信(shadow-huang-bj)，只要小y有時間，一定會盡力為大家解決疑難問題。著急的問題可以直接撥打小y的電話，137-010-26113或者撥打中亦科技的熱線電話4006 3737 00轉2號鍵，暫時沒有需要的，也可以先儲存一下小y的號碼，說不定哪天有小y可以幫上忙的地方。

另外，有興趣的可以加入QQ群227189100，我們從4月份開始，會定期做一些線上的分享。

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就如何構建科學的運維體系進行討論。

 

About Me

....................................................................................................................................................

本文來自於微信公眾號轉載文章，若有侵權，請聯絡小麥苗及時刪除

ITPUB BLOG：http://blog.itpub.net/26736162

QQ：642808185 若加QQ請註明您所正在讀的文章標題

【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】

....................................................................................................................................................

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2083751/，如需轉載，請註明出處，否則將追究法律責任。