隨著業務資料的增長，以及新業務的推出，很多企業都面臨著系統性能的問題，並且日益凸顯。似乎用盡了所有招數，但效能就是不見改善，問題到底出在哪裡？

遇到如此問題，我們一般怎麼做呢？是不是都有過下面的體會？

不差錢人的做法：

升級cpu、擴記憶體、換固態盤儲存，只能說一開始很管用，慢慢地老問題又出現了。

老實人做法：

新上線了業務系統性能不佳，怎麼辦呢？我們來玩打游擊。把一些不重要的業務放在晚上執行，調整新業務的功能模組，或者暫時不做資料同步等

扯皮做法：

看看網路有沒有問題呢，有的話就改；是不是儲存的問題呢，有問題就換；運維人員有沒有問題呢，服務商也隨意招；但要誰來承擔責任呢，每次遇到嚴重的故障，是不是時間用來扯皮較多？

現實中，很多運維人員都很拼命地在保障系統高效執行，但根據相關統計，80%的系統性能問題來自SQL方面的問題。所以，在基本保證網路(跟平時比，跟同時段其他業務比)、伺服器(CPU、記憶體使用率)、儲存（IO等待）等資源都問題不大的情況下，可以透過檢視Oracle對應時段的AWR、ASH、ADDM來尋找同時段執行較慢的SQL。有針對性的去最佳化。

而SQL最佳化中最基本的做法就是建立索引（這個需要根據SQL執行計劃去建立合適的索引）、SQL改寫、HINT提示等等

效能最佳化是一個比較複雜的系統工程，以上僅是提示點思路吧，具體還需要根據系統的實際情況多做練習，然後再觀察。最佳化是一個循序漸進的過程，就像我們人生病一樣，先吃藥治病，然後再去醫院複查，看看是否已經治癒一個道理。

你先生成你執行慢那一時間段的效能報告,然後透過裡邊的指數看是你的硬體問題還是你的語句的問題,SGA區小的話加SGA區，接著再分析你的語句,看是不是你這個語句的計劃任務是怎麼走的，是否沒走索引走了全表掃描！以上就是我的觀點

Oracle 執行越來越慢，是有多種原因，我從由易到難的思路，介紹一下我們實際運用的方法分享給大家：

一、Oracle 資料庫層自身的最佳化

1. 表的最佳化。表是Oracle中存放資料的最終載體，表的最佳化是核心。 隨時業務系統使用時間越長，表中的資料就越多，表的最佳化會起到立竿見影的效果。

(1) 表的高水位問題。

表中的資料，因較多的 delete 操作，會產生高水位，此時當發生全表讀的操作，將會額外消耗資源，從而造成業務人員直接感覺到系統使用慢。

補救的辦法是：回收高水位。

（2） 表的統計資訊過舊或者不準確

　　 統計資訊不準確，會引起執行計劃出錯，造成業務系統越來越慢。 表的統計資訊就相當於人的基本情況，當基本情況都不準確時，如何能夠保證正確的執行呢。

補救的辦法是：收集表的統計資訊。

(3) 未實施表分割槽技術

化整為零的思想。 某些表，根據業務的實際需要，未做表分割槽。 比如會經常用按年月來查詢表中某月的資料，如果表中的資料量非常大，比如超100萬條，就可以按月進行分割槽，讓按月的查詢，只需要讀取所需要月份的分割槽表。

補救的辦法是： 對錶實行化整為零，轉為分割槽表

2. 索引的最佳化

(1) 差索引

資料庫執行慢，很多的情況是查詢語句中引用的列，差索引。索引是提升速度非常重要的手段。

補救的辦法是: 分析SQL 語句，對缺失的索引進行建立。

(2) 索引的統計資訊不準

索引的統計資訊與表的資訊資訊思想是一樣的， 只有統計資訊準確，SQL 才能夠最大程度的選擇最好的執行計劃，以最短的時間執行完所需要的業務SQL。

補救的辦法是：收集索引的統計資訊。

3. SQL 語句的最佳化

資料庫慢，很多情況是因為SQL寫法不對，造成執行時間長，消耗了過多的資源。 因此最佳化SQL 是非常重要的方式之一。

補救的辦法是：收集Oracle 資料庫的 AWR， ADDM, ASH 等效能報告，找出執行時間長、消耗資源多的SQL 語句進行最佳化。

4. Oracle 資料庫的引數最佳化

資料庫想要執行速度快，對Oracle的執行引數進行最佳化是重要的手段和方法，比如大家所熟悉的 SGA、PGA、DB_Cache_Size 、Process 等引數進行分析、最佳化。

Oracle 資料庫的執行也是要挑系統平臺的，一般的中、小企業，推薦的是使用 Linux ，從每次Oracle新版本的發行就知道，首先推出的是Linux平臺，然後是 Unix平臺，最後才是Windows平臺。

三、 升級 Oracle 資料庫硬體

如經過前面 2 個大項的最佳化，仍然不能提升Oracle 資料庫的執行速度，則可能是因為現有的硬體不能滿足當前的業務需求，必須採取升級 Oracle 資料庫伺服器的硬體資源比如：升級CPU、記憶體、磁碟（特別是提升 磁碟 I/O 速度），來提升Oracle資料庫的執行速度。