許多應用系統(tǒng)的性能或穩(wěn)定性并不理想，這在系統(tǒng)上線后不久就逐漸變?yōu)榧值膯栴}，造成這些問題的原因，往往體現(xiàn)了一點：開發(fā)設計這些系統(tǒng)的人，對數(shù)據(jù)庫本身不是很了解!而DBA又不了解業(yè)務!這就導致了很多本來可以避免的問題產(chǎn)生;另一方面，隨著數(shù)據(jù)庫自我調(diào)整、管理的能力不斷加強，而應用又往往是系統(tǒng)性能的殺手，所以，DBA的工作范疇，從只負責數(shù)據(jù)庫服務器維護，逐步走向管理應用系統(tǒng)的設計、開發(fā)，是必然的趨勢!
一、 現(xiàn)階段DBA對系統(tǒng)性能及穩(wěn)定性所做的調(diào)整工作
目前DBA對系統(tǒng)性能的調(diào)整工作大致是這么幾個方面：
1、 在硬件層面進行調(diào)優(yōu)，這通常就是直接花錢，買設備、擴容。
2、 在DB層面進行調(diào)優(yōu)，比如調(diào)整初始化參數(shù)，調(diào)整數(shù)據(jù)庫物理結構。
3、 對應用的SQL進行優(yōu)化，比如在數(shù)據(jù)庫分析statspack，調(diào)整Top SQL。
4、 只有非常少數(shù)的，通常是對系統(tǒng)穩(wěn)定要求較高的一些公司的應用，才會在新的應用上線前，讓DBA對sql進行充分的審核與評估。
問題：在應用系統(tǒng)的分析、設計、開發(fā)階段，就目前情況看，很少有DBA參與，而應用系統(tǒng)上線或者開發(fā)工作基本結束后，DBA所能做的調(diào)優(yōu)工作其實是很有限的。
二、 許多應用系統(tǒng)的性能或穩(wěn)定性仍不理想
許多應用系統(tǒng)的性能并不理想，或者系統(tǒng)數(shù)據(jù)會出現(xiàn)一些難以重現(xiàn)的奇怪的錯誤，這些問題(尤其是性能問題)有時并不是在系統(tǒng)初期就會體現(xiàn)出來，但是隨著系統(tǒng)的運行、數(shù)據(jù)的增多而逐步變得難以解決，給系統(tǒng)后期的功能擴展和用戶使用上帶來了不少麻煩，造成這些問題的原因，往往體現(xiàn)了一點：開發(fā)、設計這些系統(tǒng)的人不了解數(shù)據(jù)庫!以基于Oracle的應用為例，簡要舉例說明：
底層數(shù)據(jù)結構不合理
由于缺少專業(yè)DBA的協(xié)助，很多系統(tǒng)設計出來的底層數(shù)據(jù)庫表結構問題重重。而做過系統(tǒng)的人都知道，底層數(shù)據(jù)庫結構不合理，帶來的改造代價之大幾乎等于一次重構!我見過一個OLTP系統(tǒng)，其核心表竟有100個字段，平均一條記錄超過8K，如果按Oracle默認的8K一個Block，一半以上的行必須產(chǎn)生行鏈接!
而最糟糕的是，設計這樣表結構的人還認為自己充分利用了冗余來降低表之間的連接，事實上，其人根本不曉得什么是范式、什么是更新異常，按照范式，這個表應該拆分為兩個表的，但如果要改幾乎所有的程序都要改!雖然范式不是越高越好，但絕對是設計的人必須吃透的一個東西。在冗余上，相信大多數(shù)DBA都認為，級聯(lián)更新的代價是非常高的，因此冗余應當避免發(fā)生級聯(lián)更新的情況，對于關系型數(shù)據(jù)庫設計中冗余的使用，絕不是門很容易掌握的技巧。
一、 現(xiàn)階段DBA對系統(tǒng)性能及穩(wěn)定性所做的調(diào)整工作
目前DBA對系統(tǒng)性能的調(diào)整工作大致是這么幾個方面：
1、 在硬件層面進行調(diào)優(yōu)，這通常就是直接花錢，買設備、擴容。
2、 在DB層面進行調(diào)優(yōu)，比如調(diào)整初始化參數(shù)，調(diào)整數(shù)據(jù)庫物理結構。
3、 對應用的SQL進行優(yōu)化，比如在數(shù)據(jù)庫分析statspack，調(diào)整Top SQL。
4、 只有非常少數(shù)的，通常是對系統(tǒng)穩(wěn)定要求較高的一些公司的應用，才會在新的應用上線前，讓DBA對sql進行充分的審核與評估。
問題：在應用系統(tǒng)的分析、設計、開發(fā)階段，就目前情況看，很少有DBA參與，而應用系統(tǒng)上線或者開發(fā)工作基本結束后，DBA所能做的調(diào)優(yōu)工作其實是很有限的。
二、 許多應用系統(tǒng)的性能或穩(wěn)定性仍不理想
許多應用系統(tǒng)的性能并不理想，或者系統(tǒng)數(shù)據(jù)會出現(xiàn)一些難以重現(xiàn)的奇怪的錯誤，這些問題(尤其是性能問題)有時并不是在系統(tǒng)初期就會體現(xiàn)出來，但是隨著系統(tǒng)的運行、數(shù)據(jù)的增多而逐步變得難以解決，給系統(tǒng)后期的功能擴展和用戶使用上帶來了不少麻煩，造成這些問題的原因，往往體現(xiàn)了一點：開發(fā)、設計這些系統(tǒng)的人不了解數(shù)據(jù)庫!以基于Oracle的應用為例，簡要舉例說明：
底層數(shù)據(jù)結構不合理
由于缺少專業(yè)DBA的協(xié)助，很多系統(tǒng)設計出來的底層數(shù)據(jù)庫表結構問題重重。而做過系統(tǒng)的人都知道，底層數(shù)據(jù)庫結構不合理，帶來的改造代價之大幾乎等于一次重構!我見過一個OLTP系統(tǒng)，其核心表竟有100個字段，平均一條記錄超過8K，如果按Oracle默認的8K一個Block，一半以上的行必須產(chǎn)生行鏈接!
而最糟糕的是，設計這樣表結構的人還認為自己充分利用了冗余來降低表之間的連接，事實上，其人根本不曉得什么是范式、什么是更新異常，按照范式，這個表應該拆分為兩個表的，但如果要改幾乎所有的程序都要改!雖然范式不是越高越好，但絕對是設計的人必須吃透的一個東西。在冗余上，相信大多數(shù)DBA都認為，級聯(lián)更新的代價是非常高的，因此冗余應當避免發(fā)生級聯(lián)更新的情況，對于關系型數(shù)據(jù)庫設計中冗余的使用，絕不是門很容易掌握的技巧。