一. 數據庫生命周期
結合軟件生命周期、項目的開展，數據庫的生命周期，大致可分為這麼幾個階段。
1. 規劃
在立項後，對於數據庫平台的軟硬件選型，以及大致的數據庫架構。
1.1 配置多少台服務器，服務器的內存大小/磁盤空間、IOPS/CPU核數/網絡帶寬等；
1.2 選擇的操作系統與數據庫產品，及相應版本；
1.3 整體架構，比如是否考慮：HA,Scale out, load balance, 讀寫分離等策略。
2. 開發
開發的工作，通常是在測試環境上進行的，開發結束後搬到生產環境。
2.1 數據庫設計；
2.2 SQL編程及調試；
2.3 開發過程中的SQL優化。
3. 實施
開發的數據庫程序到生產環境的部署。到這裡，基本是項目上線了。後面就進入了
運維階段。
二. 運維做些什麼
從上面的圖來看，運維是項目上線後的工作。看看從項目上線開始，運維都做了什麼。
1. 部署環境
1.1 數據庫安裝（如果服務器太多，可以選擇靜默安裝）；
1.2 參數配置（實例、數據庫參數）；
1.3 權限分配（登錄、數據庫用戶權限）。
2. 備份/還原
對於數據庫來說，有個可用的備份是非常重要的，防止有數據損壞，用戶誤操作等造成的數據丟失。保證了數據的存在，運維才有意義，否則其他工作做的再好也是白搭。
3. 監控
對於運維來說，首先要保證數據庫的運行，然後就是運行中系統的性能。所以監控主要分為這兩點：
3.1 數據庫運行狀態，有沒有什麼數據庫中斷或異常、錯誤或警告？
3.2 數據庫性能，有沒有什麼性能問題或者性能隱患？
4. 故障處理
在監控過程中發現，或者系統用戶反饋出來的數據庫錯誤或者警告，進行診斷並修復。
5. 性能優化
在監控過程中發現，或者系統用戶反饋出來的數據庫性能問題，進行優化。
6. 容災
容災只是手段，最終還是為了保證系統的可用性，通常選擇的策略有：故障轉移集群、鏡像、日志傳送、異地備份等。
如果在實施時，已經部署了容災策略，那麼這時只要做一些狀態監視即可。
也有系統是在上線一段時間之後，才補充部署容災策略的。
7. 升級/遷移
7.1 升級
通常是在本機進行，硬件不變，比如：更換操作系統、數據庫的版本、打補丁；
7.2 遷移
通常是需要升級硬件，比如：更換新的服務器，所以把數據庫搬到新的服務器上；
也有在本機“遷移”，只是為了移動數據庫文件的位置。
7.3 遷移+升級
不過很多時候，都是在遷移中做升級，也就是換了新的服務器，也換了軟件版本。
8. 健康檢查
通常叫做巡檢或者HealthCheck。可能是每天、每月、每年的。
事實上如果把巡檢的內容做到每天、每小時、甚至每X分鐘，那就是一個准實時的系統監控。
9. 系統用戶反饋的數據庫問題
用戶反饋出來的任何數據庫問題，需要DBA去做處理，即便有時診斷出來並非數據庫的問題。
從廣義上來看，除去數據庫開發外的其他任務，都應該算在運維職責之內。
問：那麼數據庫運維到底都有哪些日常任務？
答：把上面的每項任務要做的事情一個個羅列出來就可以了。
比如，數據庫運行狀態監控包括：數據庫服務是否中斷、磁盤空間、錯誤日志檢查、數據庫一致性檢查、作業運行狀態、索引碎片檢查等等。
後面會逐個分解各項任務的詳細清單。
三. 運維過程中的問題解決
運維過程中遇到問題時，如果能夠通過自己/他人的經驗解決，那麼固然好；
但如果沒有解決思路的話，通常是這樣去查：
1. 查日志：操作系統/數據庫/應用程序日志中，有沒有相關的錯誤/信息提示；
2. 查錯誤號：官方文檔/網友分享中，有沒有解決方案；
3. 如果都沒有找到，那麼就中獎了，自己分析不出就團隊分析，團隊分析不出找官方支持，當然有的時候，官方支持也不是一定能解決。
注意：對於在線系統，這麼慢慢查下去，時間可能消耗太久，會影響用戶體驗。通常是優先快速解決問題，那怕只是用臨時應急方案，以保證系統的可用性，然後再去分析根本原因，徹底解決，以防止下次再發生。
