一起ORA-00028案例的處理過程

空白葛發表於2019-04-18

 前言

 　　最近客戶在測試新系統A時，遭遇ORA28，回話被終止的問題。

　　先了解一下大致環境，系統A由系統B通過rman還原恢復，應用程式已經在系統B跑批通過，現在系統A上遇到下面問題。

　　應用程式報錯如下

　　

　　Oracle alert日誌也有相關ORA 28報錯

　　

 

分析過程

　　Oracle 官網對ORA 28解釋如下，很明顯此錯誤產生是由於正在執行的回話被kill掉，準確點說就是被語句alter system kill session 'xx,xx'殺掉。

那麼問題來了，操作時沒有DBA對此回話進行kill操作，難道資料庫有相關設定，開始檢查資料庫相關項。

　　[oracle@redhat3 ~]$ oerr ora 28

　　00028, 00000, "your session has been killed"
　　// *Cause: A privileged user has killed your session and you are no longer
　　// logged on to the database.
　　// *Action: Login again if you wish to continue working.

　　1、檢查監聽檔案配置，sqlnet.ora，並沒有特殊引數配置，明顯不是此處的問題。

　　

　　2、檢查資料庫資源配置，並沒有配置resource_manager_plan引數，也不是此處的問題。

　　

　　3、靜下來想想，資料庫肯定不會自己執行alter system kill session，既然資料庫方面沒有問題，那就從客戶端應用方面開始查詢問題。

　　4、檢查客戶端sqlnet.ora配置，無異常。

　　

　　5、現在就剩下前臺應用程式沒有檢查，由於前臺應用程式為C++編寫，生成了一個.exe執行程式，並不能直接看到其業務邏輯，好在可以通過其他方法檢視

部分程式碼，首先將AAAA.exe單獨複製出來，修改其字尾名AAAA.txt，這樣用txt記事本的方式開啟，就會出現下面程式碼，雖然是亂碼，但還有部分可以檢視，搜尋

kill sesion相關語句，果然查到相關kill sesion語句，至此，問題來源基本查明，剩下的移交給應用商，檢查業務邏輯就可以了。

　　

　　6、最後的深思，為什麼系統A由系統B還原恢復所得，而系統B確沒有問題，後來聽應用說明才知道，系統B後來是經過補丁升級，所以避開了kill session的

邏輯處理，並沒有對測試系統A進行升級。。。。。。倒騰這麼久，竟是應用的一不留神。

總結

　　雖說問題是由應用商大意所致，但是從此次問題的排查過程，可以收穫一下幾點：

　　1、在分析問題時，例如ORA報錯，首先分析其報錯觸發原因，在分析誰能觸發此報錯

　　2、排查問題時，從多方面入手，資料庫和應用都可能觸發，不要一看ORA就把問題定位到資料庫伺服器

　　3、對應用不了解的情況下，可從其他方面探查。

 

　　下面附上ORA28報錯的情景重現。

　　

Session 1 
================ 
SQL>  select SID, SERIAL# from v$session where sid=(select distinct sid from v$mystat); 

       SID    SERIAL#
---------- ----------
        63          7

SQL>  declare 
  2  pp number; 
  3  begin 
  4  for i in 1..1000000 loop 
  5  select count(1) into pp from SYS_TEST;  <<<<<<<<<<Runing the scripts then kill session in the session 2 
  6  end loop; 
  7  end; 
  8  /

Session 2 
================ 
SQL>  alter system kill session '63,7'; 

System altered.

Alert log 
============ 
Thu Apr 18 07:39:04 2019
opiodr aborting process unknown ospid (30547) as a result of ORA-28

 

 

 

 

 

　　

 

相關文章