Oracle臨時(shí)表游標(biāo)未釋放導(dǎo)致回滾段空間不足時(shí)會(huì)報(bào)出多個(gè)ORA-01650錯(cuò)誤，造成數(shù)據(jù)庫無法運(yùn)行。本文我們主要就介紹了這一問題的解決方案，接下來就讓我們來一起了解一下這部分內(nèi)容。

先分析一下相關(guān)背景。產(chǎn)生報(bào)錯(cuò)的程序是一個(gè)數(shù)據(jù)處理模塊，每天會(huì)將其他系統(tǒng)傳過來的平面文件中的內(nèi)容處理后放入數(shù)據(jù)庫中，事務(wù)量很大。我們的系統(tǒng)是9i，劃分了16個(gè)回滾段，其中兩個(gè)大的batch回滾段，每個(gè)batch回滾段有6G的足夠空間。而數(shù)據(jù)處理模塊會(huì)在事務(wù)中指定使用BATCH1。

再分析報(bào)錯(cuò)的模塊。檢查相關(guān)的數(shù)據(jù)事務(wù)處理部分，由于業(yè)務(wù)需要保持?jǐn)?shù)據(jù)的一致性，需要處理完1個(gè)文件后才能提交，中間如果出錯(cuò)就要全部回滾。經(jīng)過確認(rèn)，這部分代碼有很長時(shí)間沒有做改動(dòng)了。然后再確認(rèn)數(shù)據(jù)量，可以確認(rèn)，今天（周五）是一周之內(nèi)文件內(nèi)容最少的一天。也就是說，如果由于數(shù)據(jù)量引起錯(cuò)誤，其他時(shí)間的概率應(yīng)該更大。

但是，有一點(diǎn)需要注意。指定回滾段是針對(duì)事務(wù)的，不是針對(duì)回滾段。也就是說，我們可以指定某個(gè)事務(wù)只使用某個(gè)回滾段，但是不能保證這個(gè)回滾段只被這個(gè)事務(wù)事務(wù)。當(dāng)一個(gè)事務(wù)申請(qǐng)使用回滾段時(shí)，如果沒有自己指定，oracle就會(huì)根據(jù)當(dāng)時(shí)的各個(gè)回滾段的使用情況，分配一個(gè)最合適的回滾段給這個(gè)事務(wù)使用。因此，報(bào)回滾段空間不足的事務(wù)可能不一定就是導(dǎo)致回滾段空間不足的事務(wù)。還有一種可能就是，事務(wù)所指定的回滾段被其他事務(wù)所占用了。

于是我們就檢查是否還有其他事務(wù)占用了該回滾段。

SELECT s.sid, s.username, s.osuser, s.machine, s.program,  
t.xidusn,t.ubafil,t.ubablk,t.used_ublk, t.log_io, t.phy_io, t.cr_get, t.cr_change,  
r.name, q.sql_text  
FROM v$session s,v$transaction t, v$RollName r, v$sqlarea q  
WHERE s.saddr=t.ses_addr  
and t.xidusn = r.usn  
and s.sql_address = q.address(+)  
and s.sql_hash_value = q.hash_value(+)And r,name = 'RBS_BATCH1'; 

果然發(fā)現(xiàn)有5個(gè)事務(wù)在占用BATCH1。但是發(fā)現(xiàn)會(huì)話狀態(tài)為INACTIVE。這說明它們當(dāng)時(shí)并沒有運(yùn)行INSERT/UPDATE/DELETE語句（曾經(jīng)運(yùn)行過，事務(wù)沒有結(jié)束），而是將回滾段資源hung住了。

再查下那些對(duì)象被hung在BATCH1中，

select l.session_id, l.os_user_name, l.oracle_username, o.owner, o.object_name, t.xidusn,t.ubafil,t.ubablk,t.used_ublk, t.used_urec,  
t.log_io, t.phy_io, t.cr_get, t.cr_change, r.name  
from v$locked_object l, dba_objects o, v$transaction t, v$RollName r  
where l.object_id = o.object_id  
and l.xidusn = t.xidusn  
and l.xidslot = t.xidslot  
and l.xidsqn = t.xidsqn  
and t.xidusn = r.usn; 

嗯，都是同一個(gè)對(duì)象：“TMP_CNT_GRP”。通過SID確認(rèn)，確實(shí)上面的事務(wù)都是將這個(gè)對(duì)象hung在RBS中的。

經(jīng)過檢查，原來這個(gè)對(duì)象是一個(gè)臨時(shí)表。我們知道，臨時(shí)表對(duì)象平時(shí)是不存在數(shù)據(jù)的。只有當(dāng)一個(gè)會(huì)話使用臨時(shí)表，并向表中插入數(shù)據(jù)后，oracle才會(huì)在臨時(shí)表空間上創(chuàng)建它的數(shù)據(jù)對(duì)象。臨時(shí)表數(shù)據(jù)之所以只被所調(diào)用會(huì)話看到，是實(shí)際上是在每個(gè)會(huì)話中創(chuàng)建了一個(gè)單獨(dú)的數(shù)據(jù)對(duì)象，有各自的數(shù)據(jù)對(duì)象標(biāo)號(hào)。因此盡管是同一個(gè)臨時(shí)表，每個(gè)會(huì)話只是copy一個(gè)表結(jié)構(gòu)，而創(chuàng)建了不同的數(shù)據(jù)對(duì)象，這樣，會(huì)話之間就不會(huì)有數(shù)據(jù)干擾。而在一個(gè)會(huì)話中，對(duì)臨時(shí)表數(shù)據(jù)對(duì)象的處理跟普通數(shù)據(jù)對(duì)象處理基本相同，其中就包括臨時(shí)表對(duì)象在事務(wù)中的數(shù)據(jù)改動(dòng)也會(huì)有回滾信息的產(chǎn)生。

回到我們的問題中。通過V$SESSION和V$SQL_AREA查到，這些會(huì)話都是調(diào)用了一個(gè)PLSQL函數(shù)，而且都是通過java調(diào)用的。

Review代碼，終于發(fā)現(xiàn)潛在問題了：這個(gè)函數(shù)的結(jié)果是返回一個(gè)游標(biāo)，而游標(biāo)恰恰關(guān)聯(lián)了這張臨時(shí)表。

INSERT INTO TMP_CNT_GRP ...  
    SELECT...... ...      open v_cursor FOR  
 select TMP.CDE,  
         CAR.ID,  
         CAR.NME,  
         COUNT(DISTINCT TMP.NUM) TOTAL_CNT  
   from TMP_CNT_GRP       TMP,  
        CSS_CAR           CAR  
   WHERE TMP.ID    = CAR.ID  
  GROUP BY TMP.CDE, CAR.ID, CAR.NME;  
 
 RETURN v_cursor;  
 
 DELETE TMP_CNT_GRP; 

(這段代碼其實(shí)還存在一個(gè)問題，也就是***的DELETE語句根本不會(huì)被調(diào)用)

從這段代碼中可以看到，實(shí)際上在整個(gè)函數(shù)當(dāng)中，臨時(shí)表的數(shù)據(jù)根本不會(huì)被釋放；而且也沒有提交和回滾事務(wù)（盡管這是一個(gè)會(huì)話級(jí)的臨時(shí)表）。占用的回滾段也不會(huì)被釋放。這就存在這樣的潛在問題，如果調(diào)用者不關(guān)閉會(huì)話或提交/回滾事務(wù)的話，它所占用的回滾段就不會(huì)被釋放。事實(shí)上，經(jīng)過讓java開發(fā)人員檢查代碼，果然發(fā)現(xiàn)客戶端在打開會(huì)話后，就沒有關(guān)閉，知道客戶端本身結(jié)束。

解決辦法：

1、因?yàn)檫@是一個(gè)會(huì)話級(jí)的臨時(shí)表，數(shù)據(jù)在事務(wù)提交后繼續(xù)保留，因此在PLSQL函數(shù)中的insert語句后加上commit；

2、Java代碼在使用完游標(biāo)后關(guān)閉會(huì)話。

關(guān)于Oracle數(shù)據(jù)庫的臨時(shí)表游標(biāo)未釋放導(dǎo)致回滾段空間不足的問題就介紹到這里了，希望本次的介紹能夠?qū)δ兴鶐椭?/p>