01引言

數(shù)據(jù)庫管理員(DBA)承擔著保障生產(chǎn)數(shù)據(jù)庫穩(wěn)定運行的職責，在完成生產(chǎn)變更、事件處置等工作的同時，還應(yīng)該在哪些方面持續(xù)提升自身能力呢？本文從銀行DBA的視角，談一談“DBA的自我修養(yǎng)”。

02看山是山

看山是山，就是干一行研究一行。DBA每天在做什么？以G行的經(jīng)驗，大概有五個方面的工作：日常維護、環(huán)境搭建、升級遷移、開發(fā)支持、故障處置。既然做DBA，就得研究怎么把這些工作做好。

日常巡檢靠人工做，耗時耗力容易遺漏。G行的經(jīng)驗是從標準化到腳本化、再到工具化。巡檢做到位，就有了解決潛在的故障和容量風險的提前量，按標準的變更流程和變更工藝執(zhí)行更加從容，也就不易出錯?！皞浞萏焯熳觯謴鸵粫r難”，G行有句話“不以恢復為目的的備份都是耍流氓”，恢復測試是寫進G行科技管理制度的強制要求，每年進行檢查考核。

環(huán)境搭建效率的提升，在G行一樣是經(jīng)歷了從標準化到自動化過程。通過軟件的Golden Image加上PaaS平臺的自動化交付，標準一致，快捷高效。

至于升級遷移，不僅僅是升級操作本身，還有升級前各種測試，選擇最佳的升級窗口、千方百計將對業(yè)務(wù)的影響最小化，升級后組織保障，樁樁件件都得考慮周詳。當我們歷盡艱辛終于把成百上千的數(shù)據(jù)庫升級最新版本之后，就會驚喜地發(fā)現(xiàn)：最早升級的那個數(shù)據(jù)庫又該升級了...好吧，我們的經(jīng)驗有3點：

1、首先選擇合適的軟件版本，就是所謂的LTS（Long Time Support）版本，不僅僅是數(shù)據(jù)庫軟件，還包括中間件、操作系統(tǒng)乃至硬件，最好保持基本一致的生命周期，避免“你方唱罷我登場”。

2、統(tǒng)籌規(guī)劃，與應(yīng)用系統(tǒng)的架構(gòu)改造、功能升級的計劃相結(jié)合，提升測試效率，避免資源重復投入。

3、針對不同數(shù)據(jù)量、不同重要程度和不同停機窗口要求的系統(tǒng)，總結(jié)對應(yīng)的升級實施工藝，分類施法，有標準可依。此外，作為“高效能人士”的DBA，在版本升級這件事情上，還是盡早養(yǎng)成“以終為始”的好習慣吧...

支持開發(fā)和測試，是G行DBA的日常工作中時間占比最多的部分。高效數(shù)據(jù)庫真的是設(shè)計出來的，而80%的數(shù)據(jù)庫性能問題都是SQL問題。G行一方面將SQL編寫和數(shù)據(jù)庫設(shè)計的最佳實踐寫入科技開發(fā)規(guī)范，同時引入了SQL審核工具進行實際檢查。這里要特別提到的執(zhí)行計劃和統(tǒng)計信息收集這兩個近乎玄學的東西了。G行根據(jù)自身實際需求，定制開發(fā)了統(tǒng)計信息收集工具，可以根據(jù)表的大小、分區(qū)與否、業(yè)務(wù)運行的時間規(guī)律以及表內(nèi)數(shù)據(jù)變化的特性，分別收集、復制乃至直接設(shè)置統(tǒng)計信息，目的就是保持SQL性能的穩(wěn)定。即便如此，Hint和SQL Profile / Baseline仍然是必不可少（這里必須給O記加個雞腿，其他兄弟繼續(xù)努力吧）。

前面說了日常運維、環(huán)境搭建、升級遷移、支持開發(fā)四個方面的工作，如果這四個方面做好了，數(shù)據(jù)庫的故障自然會少。但不是說故障處置的工作不重要，相比其他方面的技術(shù)問題，這里我們更想說的是的DBA在故障處置中行動標準。DBA參與故障處置，無論是不是數(shù)據(jù)庫的問題，首先應(yīng)該讓自己進入戰(zhàn)時狀態(tài)，一切行動聽指揮，嚴格執(zhí)行指令，主動報告發(fā)現(xiàn)；牢記降低業(yè)務(wù)影響是故障處置第一目標，快速響應(yīng)，溝通表達清晰簡潔，當斷則斷。

 圖1 

03看山不是山

DBA往往聚焦具體的某個數(shù)據(jù)庫產(chǎn)品的運維和研究，有時候會把一個產(chǎn)品的概念和特性等同于數(shù)據(jù)庫這個技術(shù)門類的概念和特性。其實這也不算大問題，DBA本身就是個具體的工作，必須對一個數(shù)據(jù)庫產(chǎn)品學習透徹，不僅僅是操作，更要深入了解原理。只不過在這個數(shù)據(jù)庫產(chǎn)品百家爭鳴的時代，如果我們?nèi)霊蛱?，在接受新產(chǎn)品的時候會有些額外的困擾。

例如，PostgreSQL是典型的學院派，遵循中Database Cluster-Databases-Tables的經(jīng)典關(guān)系數(shù)據(jù)庫概念。如果我們把PostgreSQL里的Database Cluster與Oracle里的Cluster（Real Application Cluster）去對照理解，難免不知所云。即便是最基本的“Database”這個詞，不同的數(shù)據(jù)庫產(chǎn)品中定義也不盡相同。MySQL里的Database的范圍大致與Oracle/DB2中的Tablespace相當，盡管MySQL自己也有Tablespace這個概念；再有，Oracle的同學往往不怎么區(qū)分Schema和User，因為在Oracle里面這兩個東西實際使用起來沒什么區(qū)別。而在DB2、MySQL之類其他數(shù)據(jù)庫中，用于認證和權(quán)限管理的User和用來組織對象的Schema之間的區(qū)別就大了。

看山不是山，這里討論的不是哲學里共相與殊相的深奧問題，只是想建議DBA跳出某一個產(chǎn)品的范疇，一專多能?？梢試L試一下用下面的結(jié)構(gòu)梳理一下不同的數(shù)據(jù)產(chǎn)品。

圖2 

如果想了解數(shù)據(jù)庫內(nèi)部的原理，推薦學習這些材料:

1、MySQL:MySQL Internal （dev.mysql.com/doc/internals/en/ ，目前MySQL官網(wǎng)上是8.0版本的源代碼指南，實際上5.7版本的Internal手冊更加適合DBA）。

2、PostgreSQL:The Internals of PostgreSQL (www.interdb.jp/pg/)，作者鈴木啟修，有中文版。

3、Oracle:Oracle Core Essential Internals for DBA，作者Jonathan Lewis（Oracle領(lǐng)域的大神，出自牛津數(shù)學系），有中文版。

04看山還是山

“廬山煙雨浙江潮，未至千般恨不消。到得還來別無事，廬山煙雨浙江潮?！碧K東坡說的是人生，技術(shù)又何嘗不是如此。

KV數(shù)據(jù)庫、文檔數(shù)據(jù)庫、圖數(shù)據(jù)庫、時序數(shù)據(jù)庫...亂花漸欲迷人眼。我們這里想下一個判斷，且看驗與不驗：未來10年甚至更長，關(guān)系數(shù)據(jù)庫仍是不可撼動的主流。原因在于：其他數(shù)據(jù)庫解決的是技術(shù)問題，而關(guān)系數(shù)據(jù)庫尤其是它背后的關(guān)系模型可以定義世界。讓我再次致敬偉大的Codd博士吧！

只要是關(guān)系數(shù)據(jù)庫，就一定有三個必須的功能組建：SQL解析、事務(wù)管理和存儲引擎。集中式數(shù)據(jù)庫將三個功能做在一起，而分布式數(shù)據(jù)庫往往將三個功能分散在不同節(jié)點來提升擴展性。

看山還是山，希望DBA能夠從深入到淺出，從本質(zhì)上理解數(shù)據(jù)庫，對數(shù)據(jù)庫技術(shù)發(fā)展的趨勢形成自己看法。

05總結(jié)

如果問到我們的看法，或許可以參考這段對話:

問：“他們認為分布式數(shù)據(jù)庫是未來”。

答：“這是對的。”

問：“那我該怎么辦？”

答：“要多想?！?/span>

問：“想了以后呢？”

答：“我只能告訴你，那以前要多想?！?/span>