解決數據庫卡、慢,問題多,難管理——老技術的執著

 

寫在前面

  本篇是赤果果的產品介紹文章,同時也是向使用數據庫的戰友們表達一下咱們是怎樣一步一步打磨產品,又有什麼樣的遠景、動力讓咱們一直走下去....html

  八年數據庫之路的感悟 這篇文章最後所提到的數據庫管理產品,又通過兩年的不懈努力,一羣帶有熱情的老技術打磨,如今3.0版本已經成功上線,並有將近500家線下企業客戶使用,2500家線上用戶,同時也承載着上千技術愛好者的大力支持。數據庫

  在這裏也向一直支持咱們的技術大牛們表達感謝!!服務器

要作到什麼?

  複雜的技術簡單化、可視化、自動化、智能化 (都是被無數產品說爛掉的詞),解放DBA、解放IT管理人...微信

1.0的時代

  咱們怎麼樣全面瞭解客戶的數據庫運行狀況? 腳本? 命令? 又不全又累人,還不及時....咱們作了最初的原形Expert for SQL Server ,他能幫助DBA 快速瞭解分析系統的運行狀況,什麼時間點出現過什麼問題運維

  這樣咱們能夠對衆多服務器、衆多客戶的系統進行全面分析。而告別我的經驗主義、效果看水平,這樣的時代咱們認準的事——分析全面工具

  告別:硬件說軟件問題,軟件說硬件不行,解決數據庫問題就是換高速存儲換完還不行再換服務器?佈局

  

 

  同時我也經過1.0的產品寫了一整套數據庫優化的文章和案例 SQL SERVER全面優化-------Expert for SQL Server 診斷系列post

  幫助技術同行解決各類數據庫問題,固然最重要的仍是告訴你們如何不輕易下結論,一切問題要——全面分析,找到根源優化

2.0時代

  SaaS、雲已經成爲大火和沒法阻擋的趨勢,咱們也一樣開放了線上的診斷平臺SQL專家雲SaaS平臺,免費幫助技術同行處理數據庫問題,同時咱們在1.0的基礎上汲取各類場景、解決問題的思路,以1.0時代積累下的3000家客戶運行狀況提煉分析,把更多的指標,更多的問題場景融入到產品中,也獲得普遍的承認。url

  同時在2.0的版本中,咱們也在智能化的路上前進了一大步,超過3000家的數據庫運行狀況,上萬個問題場景,也醞釀出了 咱們自動化解決問題的功能——智能加速與智能運維!

  

 

 

  SaaS平臺的推出,讓咱們接觸到了更多的數據庫使用者,也接觸到各類不一樣的系統運行狀況,也有不少人在SaaS平臺上尋求幫助,本身的系統有問題,又對數據庫不懂,沒法分析。

  在SaaS平臺運行的一年半里,咱們大約接到幾百位求助者分享給咱們的運行狀況,咱們也爲他們全面分析並解決了數據庫上的棘手問題,固然更多的是小白問題....哈哈哈哈

  小到解決問題,大到針對系統現狀如何規劃數據層應用,這樣的過程是快樂了,技術是純粹的,沒有談錢只有技術交流...偶爾大俠賞個紅包,技術團隊的兄弟也出門吃頓好的...哈哈哈

 

3.0的時代來了

  在1.0和2.0累積下來的經驗看,咱們依然有不少不足:包括不少生僻的指標讓初級使用者依然很難簡單診斷,實時性診斷分析滯後,問題預警缺失,智能解決方案較爲單一等等....

  對於使用者的需求咱們一一整理足一強化、改善、研發....

  你們都喜歡用老外的產品,外來的就是最好的?咱們國內產品差什麼? 咱們就是要打造No.1

  從功能到使用習慣再到智能化...咱們一步一步前行,全部的客戶建議都是咱們最寶貴的財富...

  如今咱們的3.0界面是這樣的....

  

 

 

  首先咱們美化了界面,IT的深藍色調...常規關注指標的佈局,使用習慣上頁面的調轉,目標源頭的呈現等等

  並一改2.0重診斷分析問題,而變成簡單呈現,簡單發現,簡單處理爲原則。

  頁面可能都是花架子,咱們來講功能提高!

  

  這樣的工具也許就是知道數據庫的「昨天、今天、明天」,也就是「過去、如今和未來」

  

  

  下面列舉一些簡單又使用的功能

  實時知道運行了那、哪些語句、運行的好很差

  在運行狀態的記錄和分析基礎上,咱們最強化了就是方便...易用,以下面:

  任什麼時候間點的運行語句很輕易的就能夠呈現出來,點擊便可瞭然於心

  圖示是語句

 

 

  知道任什麼時候間點執行的語句這可能只是最基礎的功能,就算我知道了15點31分23秒,運行了個語句很是慢,可這個語句平時也不慢,拿下來一執行幾毫秒就完成了。我怎麼知道是什麼緣由形成的?當時怎麼就執行那麼長時間?

  語句實時查看

  

  分析語句行爲,上面的例子有些經驗的人都知道是語句執行的時候被阻塞了,而阻塞有兩種:硬件的資源等待,或語句資源爭用的鎖(也是咱們常說的鎖表/死鎖/阻塞)

  那咱們就會清楚地知道當時是爲何慢? 卡在硬件仍是軟件的語句上? 

 

  語句阻塞等待 實時分析

  

  

  是被哪一個語句卡住?爲何卡住?源頭是誰?誰執行的從哪來的?什麼程序過來的? 接口仍是報表?

  語句源頭分析 

   

  若是是被硬件資源卡住,是CPU、內存、仍是IO? 

  爲何不夠用? 當時硬件資源利用率怎麼樣? 

  硬件與語句關聯分析

  

  咱們常常被問題究竟是硬件不夠形成的仍是軟件的問題所困擾,在這樣的狀況下咱們是否能夠同時看到語句運行的好很差已經當時的硬件什麼壓力?這樣是否是一下就解決了呢?

 

  硬件壓力來源分析

  CPU已經使用到 90% 了? 哪些操做致使CPU高的?

  

  

  這些語句是否能夠優化?

  

 

  

  數據指標全面,並且對分析問題的流程和邏輯作到只需 「按步驟點擊」 ,好比忽然一個時間點系統慢了,要幫助管理人員清晰的展現出分析問題的邏輯!

  把DBA解決問題的思路融入產品,讓非DBA也能夠解決DBA問題,您說這樣能夠嗎?

  

 

  也許這就是所謂的 「工欲善其事,必先利其器」

 

  其餘的實時告警、趨勢分析、深刻體檢等等功能,因爲篇幅緣由,簡單貼如下圖吧。

   趨勢分析

  趨勢分析能夠拉長時間觀察發生問題的規律

  趨勢分析也可對系統進行預測分析,好比什麼時間點該提高內存?

  

 

  自動化巡檢

  

 

  其餘功能

  

 

 

--------------博客地址---------------------------------------------------------------------------------------

博客地址 http://www.cnblogs.com/double-K/

 

 歡迎轉載,請註明出處,謝謝!

-----------------------------------------------------------------------------------------------------

再說點什麼

  生活中的便利你們也都感受到了,隨便一個不方便,可能就有人作了對應的貢獻,咱們也同樣,咱們是一羣老DBA跟年輕的從業者沒法拼創意、沒法比精力、體力。但咱們也會用咱們優點的經驗來貢獻咱們本身的一份力量。

  新入行的DBA愈來愈少,能踏實肯學的就少之又少,數據做爲企業命脈,各個企業都面臨着數據庫的問題,也許還有一些時間讓咱們這幫老鳥發揮一些餘熱。

  但願你們在看完本篇之後,有興趣的技術咖能夠花些時間多嘗試一下,多給咱們一些寶貴的建議。

  咱們會在這樣的技術貢獻上越走越遠,愈來愈深刻,由於咱們要打造的是 No.1

 ----------------------------------------------------------------------------------------------------

若是您也遇到相似問題或者想加入咱們歡迎微信交流

 

注:此文章爲原創,歡迎轉載,請在文章頁面明顯位置給出此文連接!
若您以爲這篇文章還不錯請點擊下右下角的推薦,很是感謝!

相關文章
相關標籤/搜索