以下的文章主要介紹的是Oracle SQL執行緩慢的分析問題描述，如果你是Oracle SQL執行實際應用方面的新手，你就可以通過以下的文章對Oracle SQL執行是如何正確使用的方法有一個更好的了解，以下就是文章的詳細內容的介紹。
Oracle SQL執行緩慢的分析問題描述：
Oracle的優化器共有3種:
a. RULE (基於規則) b. COST (基於成本) c. CHOOSE (選擇性)
設置缺省的優化器,可以通過對init.ora文件中OPTIMIZER_MODE參數的各種聲明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你當然也在SQL句級或是會話(session)級對其進行覆蓋.
為了使用基於成本的優化器(CBO, Cost-Based Optimizer) , 你必須經常運行analyze 命令,以增加數據庫中的對象統計信息(object statistics)的准確性.
如果數據庫的優化器模式設置為選擇性(CHOOSE),那麼實際的優化器模式將和是否運行過analyze命令有關. 如果table已經被analyze過, 優化器模式將自動成為CBO , 反之,數據庫將采用RULE形式的優化器.
在缺省情況下,Oracle采用CHOOSE優化器, 為了避免那些不必要的全表掃描(full table scan) , 你必須盡量避免使用CHOOSE優化器,而直接采用基於規則或者基於成本的優化器.
Oracle 數據庫中一張表的數據已經2億多，而且此表創建了4個獨立的索引。由於業務需要，每天需分兩次向此表中插入300萬條記錄。由於數據量大，每次插入耗時3個小時以上，嚴重影響效率。因此，修改了系統的算法，將此表中只存儲當天新增記錄。
將此表truncate後，第二天執行對此表的update操作時，非常耗時。表中有2億多條數據的時候，此sql語句耗時59秒；表中有300萬條數據的時候，此sql語句耗時幾個小時。咨詢DBA後，得出結論，需重建索引。重建後，6秒完成此操作。但第三天問題依然出現。DBA正在查找原因。難道每次truncate表，都需要重建索引？
對於這個問題，DBA也沒有給出合理的解釋，推測主要原因是Oracle復雜的查詢優化算法。
最終，DBA給出的解決方案：
- truncate table ....
- drop index.....
- insert data .....
- create index ...
- analyze table table_name compute statistics;
重新生成統計數據調整後，整個操作耗時非常少。
上述的相關內容就是對Oracle SQL執行緩慢的分析問題\，希望會給你帶來一些幫助在此方面。
