資料庫最佳化專案的流程之實施 zt
0.1.1. 最佳化專案的流程之實施
優 化方案的實施實際上最重要的不是技術,而是實施的規範性。最佳化的實施方案已經完成,所有的實施指令碼都已經完成編寫,實施的時候只是按照實施方案規定的步 驟,一個一個步驟的執行就行了。不過對於較為大型的最佳化專案,最好設定一個專職的實施指令長、一個操作人員和一個稽核人員。
指令長的職責是發出實施指令,操作人員負責實施操作,稽核人員對每個操作的步驟進行稽核,並且在命令實施完畢後校驗實施結果。這種分工下每個人的職責十分清晰,不容易出現較大的問題。在我們第一次最佳化實施的時候,老於就擔任了指令長的角色,老肖負責操作,而老白負責稽核。
實 施過程中如果碰到問題,需要首先判斷該問題是否能夠被解決,如果透過判斷這個問題很難解決,那麼就馬上應該考慮回退。如果這個問題的回退將導致整個最佳化的 回退,那麼就需要花更大的精力去爭取解決這個問題,但是必須為這個問題的解決指定時間限制,在這種情況下,可能需要對實施方案做調整,調整實施步驟的各個 時間點以及名且該問題的最終回退點。實施方案調整後必須嚴格按照調整後的實施方案,如果到了最終回退點還沒有解決這個問題,那麼就必須毫不猶豫的進行回 退。在一次失敗的實施和一次失敗的最佳化這兩種結果的選擇上,明智的人都會選擇前者。最佳化操作回退後,我們還有時間分析問題,找出問題的原因,然後進行下一 次實施,而如果由於最佳化實施的失敗影響了第二天的業務,那麼你失去的可能是這個客戶。
由 於生產環境十分複雜,因此在做大型的最佳化實施的時候要十分謹慎。因為大型最佳化涉及面十分廣,有時候可能會超出我們想象的範圍。稍有不慎,就會對最佳化效果產 生極為不利的影響。比如我們的最佳化操作中經常會有新增索引、重建索引、整理表碎片等操作,對於這些操作,我們往往會忽略由於對這些表和索引的操作,可能會 導致以前某個SQL的執行計劃發生改變。如果這個SQL和某個關鍵業務相關,那樣的話就可能產生十分嚴重的效能問題。
這 種大型的最佳化最好能夠在測試環境中進行嚴格的測試,不過實際上,在絕大多數專案中,我們無法做到這一點,完全的模擬測試所需要的測試環境、測試資料、測試 模擬器方面的要求十分高,在老白做過的所有最佳化專案中,還沒有一個客戶能夠提供完整的測試環境。基於上述原因,在絕大多數情況下,我們都無法做到進行完整 的測試,因此在最佳化實施的時候我們需要做更多的工作。
為 了避免由於區域性調整帶來的負面影響,我們在實施前,應該採集足夠的歷史資料,這些歷史資料包括STATSPACK/AWR報告,關鍵業務模組的SQL的執 行計劃及開銷等。在最佳化實施完畢後,雖然大家都很累,但是有一件事情必須做完後再去休息,這就是等待30-60分鐘,然後採集相關的資料,和歷史資料進行 比對,檢查關鍵業務模組相關的SQL的開銷是否有明顯的增加,對於執行開銷增加的異常現象,都需要進行嚴格的檢查。老白採用這個方法就成功的避免了多次事 故。有一次我們對系統進行最佳化,調整了部分索引,並且整理了部分表,重建了部分索引。做完後,我們對涉及到的所有表和索引做了分析。所有操作都完成後,我 們採集了STATSPACK報告,透過報告我們發現,在TOP SQL中有2、3個SQL是以前我們沒有見過的,透過調閱這幾個SQL之前的執行計劃,發 現這幾個SQL的執行計劃發生了改變,經檢查,發現有幾張小表上面沒有分析資料,而這些小表這次最佳化操作並未涉及。重新分析了這幾張小表後,系統恢復正 常,這幾個SQL的執行成本恢復了正常。
對於有些系統,我們可能無法在最佳化實施後就馬上發現問題,那麼我們必須在客戶上班前就回到現場,第一時間採集最佳化的資訊,並且和歷史資料比對,如果發現異常情況,馬上進行相應的處理,以避免最佳化中的負面影響帶來的災難性的後果。
一般來說無論實施後的效果如何,實施後的幾天,最佳化人員需要對系統進行觀察和分析,檢查是否存在一些小的需要調整的地方。如果發現後,及時作出最佳化建議,並且進行調整。這種調整有時候能夠對整個最佳化效果起到十分關鍵的作用,大家也不能忽視。
雖 然最好的做法當然是在最佳化時對最佳化的每個步驟進行嚴格的分析,從而避免這種情況的發生,但是這種完全避免僅僅在理論上存在,每個最佳化實施者的分析能力不 同,實際生產環境也十分複雜,測試環境的缺失以及測試手段的不足,都可能給最佳化實施帶來不確定性,所以在無法完全避免的情況下,如何將負面影響限制在最低 水平就十分關鍵了。
在這一節裡實際上有三個問題需要關注,第一個是在實施過程中如何避免不必要的錯誤,完全依賴於實施方案進行操作,透過指令長、操作員、複核人員的分工,避免錯誤的操作。
第二個問題是碰到異常如何處理,如果我們的實施方案水平較高,那麼碰到各種情況可以按照預案進行,但是我們無法對任何情況都提供預案,在碰到沒有預料到的問題的情況下如何進行處理,如何決定最終回退時間也是決定實施成敗的關鍵因素。
第 三個問題是實施後如何判斷是否存在較為嚴重的問題,並且採取相應的措施。在絕大多數最佳化實施專案中,做完調整後大家都很累,都希望馬上回去休息一下,不過 這個時候如果多留下一段時間,可能可以避免一些不必要的問題。這個問題也涉及到最佳化實施方案中的時間安排,在設計方案的時候也要充分考慮到這方面的問題, 儘可能多預留一些時間。另外對於實施人員,最好能夠在最佳化實施的前幾天充分休息,以便於有足夠的體力來應付從晚上到第二天上午的連續十幾個小時的工作。來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/82387/viewspace-1027019/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案實施方案
- 專案實施過程
- 修改Oracle資料庫字符集(zt)Oracle資料庫
- SYBASE資料庫dbcc命令詳解(zt)資料庫
- Vue + Spring Boot 專案實戰(四):資料庫的引入VueSpring Boot資料庫
- 資料自動同步方案實施指南:企業如何實現高效資料流轉?
- 圖資料庫專案DGraph的前世今生資料庫
- 企業如何實施專案控制?
- SpringBoot專案取消資料庫配置Spring Boot資料庫
- 客快物流大資料專案(五十一):資料庫表分析 物流專案 資料庫表設計大資料資料庫
- RPA專案的實施週期一般是多久?企業如何來估算RPA專案的實施週期?
- [zt]IT專案開發的75條管理守則
- 微前端與專案實施方案研究前端
- SpringBoot專案連線MySQL資料庫Spring BootMySql資料庫
- [MAUI 專案實戰] 筆記App(二):資料庫設計UI筆記APP資料庫
- gorm 專案使用多數資料庫 怎麼實現好GoORM資料庫
- 亞信安慧AntDB資料庫——實時流資料處理的先鋒資料庫
- 圖資料庫驅動的基礎設施運維實操資料庫運維
- ERP專案成功實施的三大關鍵要素
- 專案實施中如何進行有效的溝通?
- 報表實施案例:某市利用大資料助力精準扶貧專案開展大資料
- 【MySQL】資料庫最佳化MySql資料庫
- mysql資料庫最佳化MySql資料庫
- 資料庫系統概述之資料庫最佳化資料庫
- golang讀取檔案的json資料流,並解析到struct,儲存到資料庫GolangJSONStruct資料庫
- 記錄:如何使用ASP.NET Core和EnityFramework Core實現 資料庫操作 和 資料庫實體 的專案分離ASP.NETFramework資料庫
- 敏捷專案管理到底怎麼實施?敏捷專案管理
- 推薦 Go 實戰專案—高效能 kv 資料庫 LotusDBGo資料庫
- 資料庫的大腦-最佳化器資料庫
- 資料庫查詢和資料庫(MySQL)索引的最佳化建議資料庫MySql索引
- gin框架,讀取檔案的json資料流,並解析到struct,儲存到資料庫框架JSONStruct資料庫
- django基礎--02基於資料庫的小專案Django資料庫
- MySQL資料庫效能最佳化MySql資料庫
- 大資料教程之《MYSQL資料庫》TCL語言和DCL語言大資料MySql資料庫
- CMDB實踐指南:專案規劃與實施策略解析
- springboot 多資料來源 activiti 工作流 整合專案框架原始碼 druid 資料庫連線池ehcache快取Spring Boot框架原始碼UI資料庫快取
- 專案資料庫表設計與建立模型資料庫模型
- springboot專案整合druid資料庫連線池Spring BootUI資料庫
- 資料專案與erp專案的差異