【原創】當一個有效能問題的資料庫擺在你的面前，作為責任人，你的處理思路是什麼？

元芳曰：這種情況基本都成為了DBA的家常便飯，經常要去處理使用者提交來的效能問題或者是工程人員提交上來的AWR報告，一般遇到這種情況，解決的方法有很多。
OLTP
（1）先要弄清楚資料庫的型別是什麼 OLTP 線上事務處理 or OLAP 線上分析系統，因為不同的資料庫型別選擇最佳化的方法也不同。例如 OLTP 強調系統的記憶體命中率，記憶體的效率決定資料庫效率。
（2）如果使用者的併發數很大可擴大記憶體的容量快取更多的資料，還可以調整data buffer cache、shared pool、java pool、large pool的大小及PGA大小包括sort區hash區等。
（3）如果使用者的線上請求數較多，可以嘗試著進行SQL的變數繫結，緩解SQL的硬解析，當遇到成千上萬的查詢操作時，能夠不經過解析過程直接使用快取的執行計劃，那效率可以提高n倍。因為硬解析會做2個分析。第一 語法分析：檢查程式碼的語法是否正確。第二 語義分析：檢查程式碼執行的物件是否存在及對執行物件的許可權是否有。解析過程十分的耗費CPU資源。
（4）資料塊的爭用，是因為資料分配的不均勻造成的，可以使用hash演算法平均打散到各個磁碟上來減少熱塊的產生
（5）還有很多系統效能間接的反應為資料庫效能，例如 網路的延遲  主機的應用程式較多  沒有采用中介軟體策略構建預處理緩衝池
OLAP
（6）如果是OLAP 線上分析系統的話，當一個使用者找你來說查詢一張報表很慢，你可以透過使用者會話來找到查詢的SQL語句，檢查這條語句邏輯上效率如何，可以使用Hint方式來改變sql的執行計劃，檢查資料的訪問方式，是走全表掃描還是走索引效率最高，調整SQL的執行計劃，選擇合適的索引
（7）因為SQL大多數就是集合的數學運算操作，SQL表的關聯方式是不是最最佳化，哪種join最適合，這都是要考慮的範圍
（8）當你手工測試完後，對錶進行統計分析，看看最佳化器和你選的執行計劃是不是相同的
（9）CBO模式的選擇，對於需要快速響應使用者的請求，可以設定成first_rows(優先把部分資料返回)，對於使用者響應不是很嚴格的業務，可以設定成all_rows（所有處理資料一次性返回）
（10）如果系統的整體開銷不大，可以考慮並行技術
（11）對於OLAP系統最直接的提高資料庫效能方法增加磁碟I/O和CPU吞吐量，如果硬體搞不了，可以採用資料庫壓縮技術，減少空間提高I/O
（12）隨著資料量的增加，以前不是問題的問題也變成了問題，對於OLAP系統SQL的效率決定資料庫效率