今天一應用在執行儲存過程，長時間沒有結束，相比正常時的執行，慢了很多，後經分析，需要調整儲存過程中的相關sql語句，不過，等更新編輯後，重新編譯，等待了十分鐘都沒響應，hang，急需處理。
首先檢視了alert日誌正常，hanganalyze分析
16:47:46 sql> oradebug setmypid
statement processed.
16:47:50 sql> oradebug hanganalyze 3
hang analysis in/oracle/admin/hsbfina/udump/hsbfina_ora_19792.trc
16:47:55 sql> exit
查詢trace檔案如下：
*** service name:(sys$users) 2014-01-2316:47:55.658
*** session id:(89.29794) 2014-01-2316:47:55.658
*** 2014-01-23 16:47:55.658
**********====
hang analysis:
**********====
open chains found:
chain 1 ::
<0/129/64355/0xc1d3528/28810/db file sequential read>
--<0/83/41350/0xc1d0588/19678/library cache pin>
other chains found:
chain 2 ::
<0/89/29794/0xf1f4048/19792/no wait>
16:51:05 sql> selectspid from v$process a,v$session b where a.addr=b.paddr and b.status ='killed';
spid
------------
28810
16:51:07 sql> exit
disconnected from oracle database 10genterprise edition release 10.2.0.1.0 - 64bit production
with the partitioning, olap and data miningoptions
rx8640_2ftp資料庫:/oracle>ps -ef|grep 28810
oracle 28810 1 17 13:13:04? 85:48 oraclehsbfina (local=no)
oracle 20266 19778 1 16:51:24pts/tf 0:00 grep 28810
查詢該killed session在做update操作回滾；
select sum(bytes/1048576),status,tablespace_name from dba_undo_extents group by status, tablespace_name;
sum(bytes/1048576) status tablespace_name
1 1630.25 expired undotbs1
2 15036.125 active undotbs1
3 20.125 unexpired undotbs1
select * from dba_segments where segment_name='fact_ftp_zfjxpg'; --分割槽表（按天分割槽，近3年資料，每個幾百兆到幾十kb不等）
確認後系統層kill該killed程序：
rx8640_2ftp資料庫:/oracle> kill -9 28810
然後，再次編譯儲存過程，瞬間通過，應用程式也在更新sql後，執行速度正常。
PL SQL儲存過程
or replace 建立或替換，如果存在就替換，不存在就建立create or replace procedure piscursor cisselect from dept2 for update beginfor row record in c loopif row record.deptno...
pl sql 儲存過程
在這段時間的開發中資料庫用的是oracle以前用的都是mssql它們的儲存過程的寫法還有一點不一樣，所以花了一天的時間看了看！以下是我做的乙個小例子！create table mytesttable id number,name varchar2 10 insert into mytesttable...
PL SQL 儲存過程
1 游標的設計開發 什麼是游標，為什麼用游標，怎樣使用游標 2 儲存過程 儲存過程的建立，引數使用，儲存過程的執行 3 儲存函式的設計 函式的建立，引數使用，函式的呼叫 4 包的設計與應用 什麼是包，包的建立及使用 儲存過程 建立語法 create or replace procedure proc...