股票代碼
301208
高可用是數據庫系統的基本需求，也是數據庫技術實現的難點之一。但對于有些行業來說，“零停機”，是剛需！
比如半導體行業，停機哪怕一分鐘都可能造成高達數萬美元的直接經濟損失；比如航空業，航班調度系統一旦出現故障，成千上萬的旅客行程將受到影響，航空公司可能要面臨天文數字的賠償；再比如醫療行業，停機可能直接關系著患者的生命安全！
那么，支撐這些尖端產業的數據庫是如何實現近乎神話般的“零停機”的呢？
要理解這一奇跡背后的奧秘，我們必須首先識別并解決影響數據庫可靠性的幾個常見問題：
問題1：數據庫高可用架構以及災備架構不完善
問題2：數據庫運行性能及穩定性問題
問題3：故障應急處理缺乏規范流程和方案
問題4：缺少高效運維體系
問題5：缺少主動式隱患梳理及預防
......
針對這些普遍問題，中亦科技經過多年技術與經驗積累，總結出以下關鍵點！
一
高可用架構與災備
堅固基石，方能抵御風暴
許多企業的數據庫高可用架構及災備體系并不完善。為了解決這一問題，我們可以根據業務系統的重要性，將其分為幾個不同的等級，并為每個等級量身定制相應的高可用架構及災備方案。
其中核心系統屬于A類系統。A/B/C/D類業務系統生產端數據庫的架構都是RAC集群，區別為是否配置了ADG,是采用小型機還是X86，是在一套集群上部署一套還是兩套數據庫。分類之后再進行核心業務系統和核心系統除外的災備架構和實現方式。
核心業務系統高可用架構圖
二
數據庫補丁管理
精準施策，防范未然
適時地進行補丁分析與升級至關重要。當遇到新版本操作系統或數據庫安裝、季度PSU補丁發布等情況時，就需要進行詳盡的補丁分析，以避免潛在問題。這一過程不僅需要精確的分析策略，還需要完善的補丁升級計劃，確保數據庫始終保持在最佳狀態。
那么，什么時候需要做補丁分析？
以Oracle數據庫為例，當出現下列情況時，需要考慮做補丁分析：
在目標版本的操作系統上安裝數據庫，為了避免目標版本的OS出現BUG需要分析OS需要安裝哪些補丁。
安裝目標版本的數據庫，為了避免新安裝數據庫出現嚴重BUG，需要數據庫應該安裝哪個patchset、哪個PSU補丁及小補丁。
隨著ORACLE季度PSU補丁的發布，需要關注新補丁的分布并對嚴重性分類，需要做補丁分析，這樣，已有數據庫可以根據升級策略提前升級補丁以預防潛在問題。
當已有數據庫出現嚴重BUG，考慮安裝補丁時，具體需要安裝哪個PSU補丁。
三
數據庫最佳實踐
細節決定成敗
基于多年服務經驗，我們總結了一系列最佳實踐，覆蓋操作系統配置、ASM參數調整、數據庫參數優化等多個方面。通過這些精心設計的策略，我們能夠有效消除系統運行中的隱患，確保數據庫的穩健運行。
四
數據庫高可用測試
實戰檢驗，確保萬無一失
在數據庫系統上線前，進行全面的高可用測試至關重要。這包括但不限于服務器單節點故障、網絡故障、心跳網絡故障等場景。通過預先設定的測試案例，我們可以驗證系統在面對各種極端條件下的表現，確保其能夠在實際應用中保持高度的可靠性和穩定性。
對RAC集群高可用架構和容災能力進行測試，主要包含以下幾個場景：
服務器單節點故障：服務器發生故障重啟是運行期間常見的問題之一，硬件故障，網絡故障，參數配置錯誤等都可能導致服務器不穩定或者宕機；一旦服務器硬件出現故障，數據庫隨之也會受到影響，可能會導致數據庫重啟或者關閉。針對這些情況，設計兩個測試用例分別模擬單節點手動重啟服務器和異常宕機時的情景。
服務網絡故障：本次預設的生產環境是雙公網網卡和雙私網網卡的rac環境，其中每組網卡都分為主網卡和備網卡，當公網主網卡出現故障后系統會自動切換到備網卡繼續運行，理論上這個切換的過程會非常短、不會對業務產生影響；同時，因為數據庫正常運行時不會用到備網卡，如果是備網卡發生故障業務也不會受到影響。當公網雙網卡同時發生故障時，服務器將無法對外開放。
心跳網絡故障：本次預設的生產環境是雙公網網卡和雙私網網卡的rac環境，其中每組網卡都分為主網卡和備網卡，當公網主網卡出現故障后系統會自動切換到備網卡繼續運行，理論上這個切換的過程會非常短、不會對業務產生影響；同時，因為數據庫正常運行時不會用到備網卡，如果是備網卡發生故障業務也不會受到影響。當私網雙網卡同時發生故障時，如果較短時間就恢復，集群層面不會出現異常，若超過了misscount時間集群會出現腦裂現象。
服務器單節點HANG故障：服務器運行期間由于硬件或軟件異常原因都有可能導致節點HANG死。操作系統因CPU、內存耗盡或BUG，OS掛起，無法響應數據庫。針對這些情況，分別設計0S無法響應、cluster軟件關鍵進程無響應、cluster軟件關鍵進程異常終止、database軟件關鍵進程無響應、database軟件關鍵進程異常終止、業務作業進程無響應等6個大的場景進行測試。
操作人員操作失誤：實際環境中，有可能存在操作人員誤操作導致數據丟失，本次場景分閃回查詢表、延遲閃回adg三個測試用例來分別模擬恢復數據。
除此之外還將對san網絡故障、軟件升級、HBA卡升級等場景進行測試。
五
運維體系建設
預防為主，應對為輔
構建全面的運維體系是保障數據庫長期穩定運行的基礎。這包括制定詳細的預防策略、建立完善的監控機制、提供詳盡的手冊指南以及系統的培訓支持。通過主動預防而非被動應對，我們能夠顯著降低系統故障率，提高整體服務質量。
運維體系建設關系到數據庫系統的持續穩定運行，主要內容如下：
制定預防未來可能導致性能不穩定的統計信息策略并實施，數據存放策略標準；
提供數據庫監控指標體系和具體實現方式；
制定數據庫備份恢復策略；
提供數據庫變更手冊、應急手冊和維護手冊；
提供系統性的培訓和指導，為客戶后續的深度自主運維奠定良好的人才基礎。
... ...
為了提升業務連續性和用戶體驗，提升系統可用性、穩定性、安全性，全面提升運維質量，我們還會制定了數據庫運維體系說明手冊，用以指導數據庫的日常運維工作。
Oracle運維體系的模型
六
主動式優化與問題梳理
防微杜漸，未雨綢繆
數據庫運維和消防一樣，永遠都是“預防重于救火”，被動式的故障處理只能解決突發的問題，只有主動梳理及預防才能防患于未然，真正做到事半功倍！
中亦科技會從主動式分析和預防及基于開發運維最佳實踐進行問題梳預防進行說明。主動對數據庫運行情況進行性能監控，抓取性能表現不佳或擴展性不佳的SQL/PLSQL并進行主動分析，提交優化建議。通過梳理并預防潛在問題，我們能夠提前發現并解決隱患，減少未來可能出現的問題數量。
在這個信息爆炸的時代，數據庫的可靠性很關鍵。中亦科技一直在不斷的總結項目經驗，培養專業技術團隊，完善服務體系，希望通過不斷升級的數據庫可靠性方案，提高數據庫的可用性和穩定性！
如果您有數據庫可靠性提升的需求，歡迎留言聯系我們，我們的技術專家團隊將竭誠為您服務。
