作者：IT168 Laurence.li 2007-01-30[@more@]【IT168 專稿】許多應用系統的效能或穩定性並不理想，這在系統上線後不久就逐漸變為棘手的問題，造成這些問題的原因，往往體現了一點：開發設計這些系統的人，對資料庫本身不是很瞭解！而DBA又不瞭解業務！這就導致了很多本來可以避免的問題產生；另一方面，隨著資料庫自我調整、管理的能力不斷加強，而應用又往往是系統效能最大的殺手，所以，DBA的工作範疇，從只負責資料庫伺服器維護，逐步走向管理應用系統的設計、開發，是必然的趨勢！
一、現階段DBA對系統效能及穩定性所做的調整工作
目前DBA對系統效能的調整工作大致是這麼幾個方面：
1、在硬體層面進行調優，這通常就是直接花錢，買裝置、擴容。
2、在DB層面進行調優，比如調整初始化引數，調整資料庫物理結構。
3、對應用的SQL進行最佳化，比如在資料庫分析statspack，調整Top SQL。
4、只有非常少數的，通常是對系統穩定要求較高的一些公司的應用，才會在新的應用上線前，讓DBA對sql進行充分的稽核與評估。
問題：在應用系統的分析、設計、開發階段，就目前情況看，很少有DBA參與，而應用系統上線或者開發工作基本結束後，DBA所能做的調優工作其實是很有限的。
二、許多應用系統的效能或穩定性仍不理想
許多應用系統的效能並不理想，或者系統資料會出現一些難以重現的奇怪的錯誤，這些問題（尤其是效能問題）有時並不是在系統初期就會體現出來，但是隨著系統的執行、資料的增多而逐步變得難以解決，給系統後期的功能擴充套件和使用者使用上帶來了不少麻煩，造成這些問題的原因，往往體現了一點：開發、設計這些系統的人不瞭解資料庫！以基於Oracle的應用為例，簡要舉例說明：

底層資料結構不合理
由於缺少專業DBA的協助，很多系統設計出來的底層資料庫表結構問題重重。而做過系統的人都知道，底層資料庫結構不合理，帶來的改造代價之大幾乎等於一次重構！我見過一個OLTP系統，其核心表竟有100個欄位，平均一條記錄超過8K，如果按Oracle預設的8K一個Block，一半以上的行必須產生行連結！

而最糟糕的是，設計這樣表結構的人還認為自己充分利用了冗餘來降低表之間的連線，事實上，其人根本不曉得什麼是正規化、什麼是更新異常，按照正規化，這個表應該拆分為兩個表的，但如果要改幾乎所有的程式都要改！雖然正規化不是越高越好，但絕對是設計的人必須吃透的一個東西。在冗餘上，相信大多數DBA都認為，級聯更新的代價是非常高的，因此冗餘應當避免發生級聯更新的情況，對於關係型資料庫設計中冗餘的使用，絕不是門很容易掌握的技巧。

不合理的底層資料庫結構設計，給系統的效能埋下了重磅的定時炸彈，這個系統在客戶那裡跑不到一年，資料量稍微上去些，效能、穩定性就直線下降，而重構的成本又極高，買新伺服器肯定是隻能治標。而假如底層資料表結構是資深DBA設計的又會如何？當然，如果完全讓DBA去做資料庫表結構的設計，DBA就必須非常清楚地瞭解整個系統的業務細節資訊，這在DBA來說，人力資源上是有一定困難的，畢竟維護好線上伺服器就已經佔用了DBA很多的資源，並且領導們通常更看重這點。

很少有領導能認識到DBA在系統開發設計中所起到的作用，和維護線上系統、處理DB故障相比，對整個系統的穩定性和效能，是同樣重要的！
SQL效能問題
系統的開發，通常和DBA是沒有什麼關係的，但是，如果DBA對系統有足夠的瞭解，這時候也是可以做不少貢獻的。比如，檢查系統業務的資料流是否正確，這個需要透過一些手段，比如sqltrace、10046等，詳細對系統的邏輯實現進行檢查，一方面查出系統中過於消耗資源的或編寫不規範的SQL及時進行調整最佳化，另一方面，查出系統中不合理的資料庫訪問，不要到了線上才發現問題，那時可能已經當機了。簡單舉個例子，當一個頁面需要多處顯示商品的類目列表時，程式往往容易犯一個錯誤，就是多次以同樣的SQL讀取出同樣的資料，並應用於每一個列表顯示上，如果你只讀取一次，或者乾脆在Web層進行cache（要有適當的重新整理策略），就可以大大減少單次訪問該頁面在DB上的I/O消耗。有時甚至會檢查出根本不需要被執行的SQL，也在這些和自己毫不相干的功能中頻繁地執行著……同時，對資料流的檢查還能夠查出一些隱藏得較深的系統Bug，這個更需要基於DBA對業務細節的瞭解。

誰說DBA只會花錢？如果一個伺服器I/O負載達到極限，大多數人只能選擇擴容，最多重構部分功能來作些最佳化，而從statspack往往可以看出，系統的I/O資源多數是被一些並不該如此頻繁執行的SQL給佔用了，它們單次執行並不慢，但佔用系統資源比例卻異常高，這些問題，細化在每一個業務中，對這些問題的檢查和資料流最佳化，就是對系統資源的最大節省，就是省錢！這個工作，或許只有DBA才能稱職

併發問題
誰都知道系統有併發存在，可是我們在設計系統的時候，又往往是按照單一業務的思維模式來設計、編碼，很少考慮同一業務、不同業務之間併發運作可能產生的問題。通常，系統無規律地出現一些“奇怪的”、“不可能的”錯誤，極有可能就是併發惹的禍，而背後的問題，往往體現了設計人員不瞭解資料庫的鎖機制，無法和業務很好地結合。設計的人不瞭解資料庫，而DBA又不瞭解業務，這就導致了很多本來可以避免的問題產生。

最經典的就是Tom Kytes舉的酒店預定的例子，當兩個服務員同時按下查詢預定房間的按鈕，結果是兩個人都預訂到了同一間客房，這個問題很經典，在目前看來也很容易解決，不就是加上鎖麼？但是，這只是一個例子，在你實際應用的系統中，你這樣貿然地加上for update，又可能導致別的問題！比如：死鎖。在一個複雜的業務系統中，死鎖不難見到，這個是設計者的設計漏洞，需要設計者全面衡量業務關係，然後對錶的鎖定製定規則來儘量避免的。學會使用鎖來保證資料的完整性還是不夠的，還要靈活應用鎖，適當採用樂觀鎖定。

如果對於重要的業務，一律免談，直接悲觀鎖定也是不可取的，會給系統的維護帶來一些問題，某些業務這樣做甚至會帶來資料的大面積鎖定時，在OLTP上的代價很高，嚴重影響系統併發能力。我曾經碰到一個錯誤資料的問題，分析後，確定是兩個不同的業務間併發，同時缺少必要的鎖定，而造成的錯誤資料。但基於該業務的特殊性，加鎖的代價是昂貴的，在DBA的仔細追究下，確認了可以透過樂觀鎖定也即提交時檢驗的方式來達到兩全其美的目的。從這裡可以看出，資料的健康和完整性，與系統的併發能力有時是矛盾的，但有經驗的DBA能夠教你如何獲取最佳方案，當然，前提是DBA參與設計並熟悉業務。

系統架構的問題
DBA不是系統架構師，但資料庫是一個應用系統核心的部分，同時，由於資料庫伺服器不像應用伺服器那樣便於擴充套件，因此往往也是整個系統效能的瓶頸所在，所以架構師在設計系統架構時，應該充分考慮DBA的意見，要考慮到DBA對資料庫中的SQL進行效能調整的便利性甚至是可行性！

否則就可能導致DBA及開發團隊對系統的效能問題反應過慢甚至束手無策！我曾經見過一個架構，它無法實現oracle最普通的分頁SQL！繫結變數就根本不在考慮中！再就是有些第三方元件或架構，能夠幫助我們的系統生成SQL，這當然很省事，能夠加快開發速度，可是在這樣的系統中，DBA如果想要最佳化一條SQL可能很難，因為開發人員要修改的東西相對較多，修改的工作量大、耗時長，並且工作量多肯定就更容易帶來新的錯誤!Oracle大師Tom Kytes也曾在經典著作Export one on one中反對使用這種自動產生SQL的元件或架構,這種東西很可能給你的系統帶來效能和維護上的問題！

這些問題，如果諮詢過資深DBA，相信會盡早發現並在架構上得到修復或調整。而到了系統開發的後期，架構的問題已經很難做本質的調整了。假如你的系統要求非常高效，並且併發訪問較大，那麼建議架構師傾向於尊重DBA的意見，這對整個系統的效能以及持續地調優將非常重要。而DBA，對系統架構也要有一定的認識，並明確自己在現有架構中遇到的困難是什麼。

三、提高應用系統的效能、穩定性

除了DBA原本的DB調優、SQL調優、伺服器維護等日常工作以外，擴充套件DBA的工作範疇，強化DBA在系統開發過程中的控制能力和決定權。

1、讓DBA參與到需求分析中去，並充分理解使用者需求，從DB的角度來理解和考慮這些需求實現的成本。

2、 Schema的設計必須由DBA設計確定或者稽核確定，這點也要求DBA必須瞭解業務系統，才能整理出正確的、有良好擴充套件性的E-R關係。

3、讓DBA更深入的參與系統的設計，儘可能地讓DBA瞭解應用的業務設計細節，這對於DBA稽核資料流是起到決定性作用的，如果有條件，業務的資料流應當作為系統的文件之一，以便將來的反覆核查。

4、在系統上線之前，由DBA稽核sqltrace中的sql以及資料流邏輯，最好是能給出一些重要業務功能在DB成本（比如I/O）上的評估結果。

5、系統上線後的效能監控，及時作出調整甚至一定範圍內重構最佳化資料訪問邏輯。

如上所述，則DBA的人力資源必然不足，因此，細化DBA的工作，進行分工是正確並且高效的，在一些公司，已經將DBA分為專管線上伺服器的產品DBA和專管開發、參與系統設計的開發DBA，從不同方面全面保障系統的穩定和高效，值得借鑑！

DBA在系統設計、開發中的重要性

相關文章