首先談到系統優化，這是大部分dba都要接觸到的工作。企業定出一個商業目標，IT主管需要把這個商業目標轉換成系統的承載能力，要保證系統不會成為拖累。這個目標到了DBA這裡，DBA需要把它分成主機與操作系統，存儲，數據庫3個部分。
主機方面的優化會從硬件選型開始，我們需要確定我們的系統目標容量是什麼，需要采購什麼硬件能夠支撐這個容量，要有可量化的指標，有了可量化的指標後我們可以通過測試得出什麼機器能滿足性能，最後要綜合成本考慮，選定一款能符合目標容量並且性價比最高的機器。由於硬件的升級換代非常迅速，一般2年時間就有新一代主機推出，所以在選擇機器的時候只選夠用的機器而不去追求一次采購到位，任何高端的機器2年過後必然被更高端的機器所代替。一般來說在企業發展的初期，采用Linux的pc server是最優化的方案，相比較Windows系統，linux系統的長時間運行的穩定性更強，與unix系統相比，Linux又體現了經濟性。在企業的業務迅速發展後，對系統可用性更高的情況下，我們需要考慮采用UNIX系統的服務器，采用各種高可用方案保證系統的穩定性，為業務發展提供支撐。當系統搭建完畢，我們需要把注意力回到主機和操作系統上，對系統的運行狀態持續跟蹤，對系統的瓶頸進行優化。
存儲方面的優化需要DBA對各種存儲體系非常了解，對DAS,NAS,SAN的優缺點要了然於胸。要為不同的應用選取不同的存儲方案，舉個例子，如果一套系統的對性能的要求不是第一位，但是非常注重經濟性，那麼DAS可能會是一個好的選擇。如果一套系統要求有快速可以移植能力，那麼NAS可能將會是首選。如果一套系統追求的是性能，那麼SAN可以做為它的解決方案。另外當今各個存儲廠商也都提出了自己的數據生命周期管理實現方案，大家的目的也都是為了讓用戶把最重要的數據放在核心存儲上，次要的系統和歷史數據可以分布在成本比較低的二級或三級存儲上，盡可能為用戶節省成本。另外對於存儲方面細節的優化我們可以集中到raid的劃分，storage read/write cache劃分，存儲的iops，throughput和cpu utilization,response time的監控。DBA首先要做到能做正確的事(為不同的應用選對合適的系統)，其次要能做到正確的做事(關注技術細節，關注性能，把知識合理得運用到優化中去)。
數據庫上的優化DBA首先要做的是找到一種階段化的優化手段，一般來說針對數據庫優化都會經過下列步驟
一般來說在企業裡面優化目標基本會跟數據庫的吞吐量，數據庫請求響應時間掛鉤。在確定優化目標後，我們可以去查看當前性能，查看數據庫性能監控報表，查看數據庫的等待事件，查看top n sql，聯合操作系統上的性能報表一起定位到瓶頸，然後對這些瓶頸做出相應的優化，再比較優化前後性能的差別，反復這個過程，最終達到優化目標。因為企業的應用系統可能天天在變化，dba必須每天都關注性能問題，優化是一個長期持續的過程，最終目標都是為了發揮出系統的最大能量。
接下來說到應用優化，其實很多時候當系統負載比較高的時候都是因為應用裡面有性能很差的sql語句引起的，控制sql語句的質量是dba的頭等大事。我自己也曾經幫別人優化過很多系統，通常出現問題的時候都是由於sql語句寫的不好，該建立的索引沒有建，不需要關聯的語句去關聯，高並發的全表掃描導致系統負載相當高，這時候一些公司的就會考慮去升級硬件，升級存儲，升級主機，通常會選用高出實際容量很多的硬件，能用pc server的去選用小型機，能用小型機的選用rac，實際上如果有一個比較專業的dba，那麼經過優化後的系統完全沒必要升級，這其中的IT投入都可以省掉。
對於自己開發應用程序的公司，Dba要主動建立sql培訓體系，定期給開發人員講解sql相關知識，最好是把已經出現問題的sql做為案例分析進行講解，這樣效果會比較明顯。這樣做的目的是因為sql語句是程序員寫在應用裡面的，很多時候dba等到應用上線後才發現性能有問題的語句，這個時候通常已經給業務系統帶來或大或小的影響了，dba需要把問題消滅在開始階段。當然只有培訓是不夠的，dba需要借助測試部門的力量把有問題的語句在測試階段盡量都發現，這樣就必定要搭建一套完整的開發數據庫和測試數據庫，開發庫和測試庫與產品庫的表結構和對象要保持一致，以Oracle為例，dba可以自己利用pl/sql腳本對比兩個庫的數據結構並自動同步，還可以做到從產品庫定時同步數據到開發測試庫，
