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

許多應用系統的性能或穩定性并不理想，這在系統上線后不久就逐漸變為棘手的問題，造成這些問題的原因，往往體現了一點：開發設計這些系統的人，對數據庫本身不是很了解!而DBA又不了解業務!這就導致了很多本來可以避免的問題產生;另一方面，隨著數據庫自我調整、管理的能力不斷加強，而應用又往往是系統性能最大的殺手，所以，DBA的工作范疇，從只負責數據庫服務器維護，逐步走向管理應用系統的設計、開發，是必然的趨勢!
　　許多應用系統的性能或穩定性并不理想，這在系統上線后不久就逐漸變為棘手的問題，造成這些問題的原因，往往體現了一點：開發設計這些系統的人，對數據庫本身不是很了解!而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才能稱職。