數據庫智能管理助手-CloudDBA

摘要：阿里雲CloudDBA主要分爲離線分析和在線分析兩種功能。幫助用戶節省成本，定位問題，分析緣由並推薦解決方法。CloudDBA能夠作到實時診斷，離線診斷和SQL優化。而且經過MySQL的參數調優，檢測參數的不合理或者準備的延遲的狀況。

演講嘉賓簡介：

勳臣，阿里雲RDS內核團隊技術專家，目前阿里雲CloudDBA專家系統開發。有着豐富的數據庫開發管理和優化的經驗。

本次直播視頻精彩回顧，戳這裏！

PPT下載連接：http://click.aliyun.com/m/51146/

如下內容根據演講嘉賓視頻分享以及PPT整理而成。

本次的分享主要圍繞如下三個方面：

1、CloudDBA提供了什麼

2、核心能力

3、典型實踐應用

1、CloudDBA提供了什麼

CloudDBA主要提供了兩個功能，一個是離線分析，另外一個是在線分析。咱們知道DBA主要平常工做分爲兩塊，一個是羣檢，還有就是作線上的響應，好比說個人數據庫忽然一下應用被卡住了，或者數據庫出現性能抖動，這些問題都是須要DBA實時響應的。Oracle包括兩個報告，一個是AWR報告，還有一個叫ASH報告，咱們從功能上來講和Oracle有些相似。離線的分析主要是AWR報告，而後在線響應是ACTIVE SESS HISTORY。

CloudDBA在雲上是SASS化的一塊，是基於PaaS平臺的增值服務。雲上的SASS須要去解決性能的問題，問題的診斷，以及提供一些輔助的工具。雲上的數據庫跟自建的數據庫有一點不一樣，若是數據庫上雲了以後，PaaS這層的工做雲都幫忙解決了。好比，性能監控，HA等都已經作了。DBA真正要作的是上面這一層，就是怎麼讓數據庫運行的更好，讓用戶用好數據庫。

不論是雲上的仍是自建的數據庫，它自己的成本其實是看得見的，是很低的。對作DBA的同窗來講，從準備到數據庫上線花費的精力其實是有限的。而真正的難點是如何把數據庫管理好？由於咱們爲作產品的平臺應用提供支撐，若是用戶的使用習慣很差，很容易將咱們的數據庫搞壞掉，整個業務都會受到影響。因此從下圖能夠看到咱們的數據庫會有大量的維護成本，大概大於80%。固然DBA主要是解決應用中的一些問題，節省時間成本。好比說，用戶反饋說應用卡住了，對DBA來講須要登陸到數據庫中，到控制檯看動畫，看看到底發生了什麼？這些動做其實是很重複，很機械的、若是有CloudDBA，它會有本身的一些小的腳本，好比定位問題，很快的能夠輸入用戶名密碼，把狀態抓出來，基於狀態作一些判斷。這種方式是能夠的，可是還有更好的解決方式，若是做爲一個產品，把這樣的行爲產品化和服務化，交付出來。在應用卡住的時候，用戶只須要點一個按鈕，產品就能夠把狀態抓出來，而且分析出數據庫卡住的點，並給出下一步的解決建議。甚至絕大部分場景，命令都會給生成出來，用戶直接複製執行就能夠了。

2、核心能力

1.實時診斷

咱們會把DBA積累的經驗產品化，編成程序，錄入到資料庫中去。將診斷的結果進行輸出。咱們在平常工做當中會常常發現一樣的問題對不一樣的DBA來講解決的方式也不一樣。甚至說一位同窗在當值班的時候遇到問題，知道怎麼解決了，換另外一位同窗指班沒有遇到問題，過了很長的時間再一次發生時你們可能都忘了如何解決這個問題。因此這時就須要將工做經驗進行沉澱，產品化，服務化，再把它輸入出來。咱們把解決問題的方法。技巧，經驗錄入到資料庫（Knowledge Base）中，它就是一個診斷程序，通過不斷的錄入經驗，Knowledge Base會變得愈來愈豐富。結果格式會分爲現象描述，緣由描述和相關診斷建議。

2.離線診斷

離線診斷是基於狀態，作深層次的分析，挖掘Top SQL，看哪些SQL執行次數最多，最長，消耗時間最長。另外還有事物分析，看事物是否合理，以及SQL Review。由於咱們作DBA，若是沒有一個很強大的工具去規範開發人員行爲的話，這個工具早晚會被拖垮。在早期的時候，出一份規範發給開發人員，要求搜索語句只能按照規範寫，不然會出事。可是若是沒有一個工具約束和規範，每一個開發團隊都不可能看每一條規範語句。還有就是死鎖的分析。

3.SQL優化

MySQL的優化器固然沒有Qracle那麼優秀，咱們常常會聽到它的執行效果不是很好，表的鏈接順序不是那麼的最優。好比表上面有索引，可是索引失效了，你們都知道索引失效的狀況是字段不匹配。咱們的工具會幫助咱們在字段後面加個函數。好比說有一個交易表，交易表上有一個字段用時間去get，由於目前時間都至少精確到秒。不少開發人員會把日期函數直接加在get上面，等於具體某一天就能夠了。可是若是用Oracle或者SQL Server3的數據庫是沒有問題的，DBA會給你加一個函數索引。可是若是用的是MySQL，並且是5.7以前的版本是沒有辦法的，真正的寫法是大於等於這一天的開始和小於等於這一天的結束，應該是這一天24小時的範圍以內均可以識別出來。還有一個是計算代價的重寫，咱們會到備庫動態的採樣，好比說一個查詢，上面沒有索引，帶有多個字段，要建一個混合索引，那麼這個字段的順序應該怎麼放？咱們會到備庫中動態採樣，看這些列上的數據分佈，而後生成最優的字段順序，最優的索引。由於不可能看幾個字段有的全部索引順序，因此採起動態採樣。這一塊的內容能夠到阿里雲的官網搜，有不少很是詳細的資料和視頻。

3、最佳實踐

咱們常常遇到用戶把規格升級，而後進行壓測，發現升級規格後性能反而降低。好比4C32G生級成了8C62G，發現吞吐降低。經過診斷報告TOP SQL定位性能降低緣由。發現truncate的執行時間變慢了，爲何變慢?由於表的內存變多了，內存的張頁變多了，MySQL truncate以前是要把張頁落入文件裏面去，利用咱們的工具能夠很快的定位緣由語句，下一步應該把MySQL的 Max present的參數調小，把張塊控制在必定的範圍裏面。

另一個問題是用戶說每隔半小時就會出現壓力抖動，查明什麼緣由。由於用戶提出這個問題時，抖動發生的時間是在前幾天或者過了幾個小時。因此咱們會建議用戶開啓CloudDBA，這樣才方便咱們跟蹤，具體的數據用戶在本身的的控制檯就能夠看到了。以下圖是經過TOP SQL獲得的診斷報告，知道哪一個時間發生了抖動。

鏈接滿了也分爲不一樣的場景。第一種是出現鎖了，這種是最多見的，這是把鎖會話KILL掉。第二種就是在業務高空的時候執行了ddl的操做，這時也很好解決，咱們都會幫助用戶定位出來。還有一種是應用程序的鏈接使用有問題，沒有關掉。好比Java的JDBC開了以後沒有關掉，這時咱們也能夠識別出來。咱們會建議用戶使用鏈接池，及時的把鏈接關掉。還有一個，既不是MySQL堆積也不是鎖，也正常使用鏈接池，這時就多是規格過小，壓力太大。若是不能升級規格，那麼應用程序就要作限流。

鏈接滿了以後，CloudDBA能夠幫助識別並終止會話。

CPU達到100%以後，CloudDBA能夠幫忙識別出來，同時進行優化

除了上述的幾種場景，阿里還作了一些參數優化。MySQL有很是多的參數，參數的不合理或者準備的延遲均可以經過CloudDBA檢測出來。

CloudDBA是一個動態淨化的產品，咱們是在不斷的更新。咱們會和阿里雲的工單系統聯繫，他們處理的工單會扭轉到咱們這邊，咱們會吸取消化掉一部分，看哪些能夠經過程序集成起來，RDBA會嵌在RDS數據庫的控制檯上面，用戶能夠無償使用。

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。