因為第一次遇到這個問題，所以以下方法，都來源於網上。
版本：oracle11g
遇到這個問題，可以查看oracle日志，分析問題的原因。
oracle數據庫的最常用問題定位日志是alert日志，oracle數據庫的日志文件alert_$ORACLE_SID.log記錄了重作日志的轉換，數據庫啟動和關閉，數據庫結構的改變，回退段的修改，死鎖，內部錯誤等信息。
路徑是：ORACLE_BASE/admin/ORACLE_SID/bdump/alert_ORACLE_SID.log
新的Oracle數據庫的日志文件在ORACLE_BASE/diag/rdbms下面，如：D:\app\Administrator\diag\rdbms\orcl\orcl\trace
也可以通過sql語句查找位置：
Alert log XML文件位置：select value from v$diag_info where name ='Diag Alert';
Alert log文本文件位置：select value from v$diag_info where name ='Diag Trace';
解決方法1：
alter system set "_optimizer_connect_by_cost_based" = false scope=both ;
參考詳情
_optimizer_connect_by_cost_based 為使用基於成本的轉換進行連接，默認為true
scope 就是這個參數修改的SQL的影響的范圍，總共有三個值：both、memory，spfile。
1.scope=memory修改后當前就起作用，重啟數據庫不起作用
2.scope=spfile修改后當前不起作用，下次重啟數據庫才起作用
3.scope=both修改后當前起作用，下次重啟數據庫也起作用
更多未歸檔隱藏參數，參考未歸檔隱藏參數
解決方法2:
alter system set "_optim_peek_user_binds"=false;
_optim_peek_user_binds 為能夠窺視用戶綁定，默認為true
開啟bind主要是為了提高性能，因為這樣做可以盡量避免不必要的硬分析(Hard Parse)，節約了時間，同時節約了大量的CPU資源。
當一個Client提交一條Sql給Oracle后，Oracle 首先會對其進行解析(Parse)，然后將解析結果提交給優化器(Optimiser)來進行優化而取得Oracle認為的最優的Query Plan，
然后再按照這個最優的Plan來執行這個Sql語句(當然在這之中如果只需要軟解析的話會少部分步驟)。
當Oracle接到Client提交的Sql后會首先在共享池(Shared Pool)里面去查找是否有之前 已經解析好的與剛接到的這一個Sql完全相同的Sql
(注意這里說的是完全相同，既要求語句上的字符級別的完全相同，又要求涉及的對象也必須完全相同)。
當發現有相同的以后解析器就不再對新的Sql在此解析而直接用之前解析好的結果了。這里就節約了解析時間以及解析時候消耗的CPU資源。尤其是在OLTP中運行着的大量的短小Sql，效果就會比較明顯了。
因為一條兩條Sql的時間可能不會有多少感覺，但是當量大了以后就會有比較明顯的感覺了。
但是，使用綁定變量的一個缺點是，給出的執行計划並不一定就是SQL在真正應用程序里所使用的執行計划。這時我們就可以通過event 10053 事件來查看。
解決方法3：
如果臨時表空間不能自動擴展的話，可以給用戶新建臨時表空間。
1、新建一個臨時表空間
2、將當前用戶的臨時表空間切換到新建的臨時表空間上