鎖_rac環境kill鎖表會話後出現killed狀態（解決），_rackilled

鎖_rac環境kill鎖表會話後出現killed狀態（解決），_rackilled

原創作品，出自 “深藍的blog” 部落格，深藍的blog：http://blog.csdn.net/huangyanlong/article/details/46876961

rac生產庫殺掉鎖表會話出現killed狀態處理

 

環境：

作業系統：CentOS 6.4 64BIT

資料庫：Oracle RAC 11.2.0.4 R2 64bit

 

       在某項目中，進行大資料幫浦任務時，抽取出現錯誤，需要對大表進行重新抽取。於是取消insert操作，然後執行truncate操作。

如下，報錯了，提示資源正忙，判斷應該是之前的操作沒有完全取消，出現了鎖等待。

於是，嘗試查詢鎖表的使用者，如下：

注意：這裡是rac環境，需要查詢gv$類別檢視。

SELECT  A.OWNER,                        --OBJECT所屬使用者  A.OBJECT_NAME,                  --OBJECT名稱  B.XIDUSN,  B.XIDSLOT,  B.XIDSQN,  B.SESSION_ID,                   --鎖表使用者的session  B.ORACLE_USERNAME,              --鎖表使用者的Oracle使用者名稱  B.OS_USER_NAME,                 --鎖表使用者的作業系統登陸使用者名稱  B.PROCESS,  B.LOCKED_MODE,   C.MACHINE,                      --鎖表使用者的電腦名稱  C.STATUS,                       --鎖表狀態  C.SERVER,  C.SID,  C.SERIAL#,  C.PROGRAM                       --鎖表使用者所用的資料庫管理工具FROM  ALL_OBJECTS A,  GV$LOCKED_OBJECT B,  SYS.GV_$SESSION C WHERE  A.OBJECT_ID = B.OBJECT_ID  AND B.PROCESS = C.PROCESS --AND C.STATUS='ACTIVE'ORDERBY1,2

在查詢結果中，鎖定到需要解鎖的表的會話資訊，如下：

於是，嘗試查詢鎖表的使用者，如下：

注意：這裡是rac環境，需要查詢gv$類別檢視。

SELECT  A.OWNER,                        --OBJECT所屬使用者  A.OBJECT_NAME,                  --OBJECT名稱  B.XIDUSN,  B.XIDSLOT,  B.XIDSQN,  B.SESSION_ID,                   --鎖表使用者的session  B.ORACLE_USERNAME,              --鎖表使用者的Oracle使用者名稱  B.OS_USER_NAME,                 --鎖表使用者的作業系統登陸使用者名稱  B.PROCESS,  B.LOCKED_MODE,   C.MACHINE,                      --鎖表使用者的電腦名稱  C.STATUS,                       --鎖表狀態  C.SERVER,  C.SID,  C.SERIAL#,  C.PROGRAM                       --鎖表使用者所用的資料庫管理工具FROM  ALL_OBJECTS A,  GV$LOCKED_OBJECT B,  SYS.GV_$SESSION C WHERE  A.OBJECT_ID = B.OBJECT_ID  AND B.PROCESS = C.PROCESS --AND C.STATUS='ACTIVE'ORDER BY 1,2

在查詢結果中，鎖定到需要解鎖的表的會話資訊，如下：

嘗試將這個會話kill掉。

查詢該會話屬於哪個執行個體，如下：

select   *  from   gv$session  where  sid=1228

--查看到，這是執行個體2的session

把這個session殺掉

例：alter system kill session 'sid, serial#, @ inst_id '

alter system kill session '1228, 42549, @2 '

提示，這個會話被標記為kill狀態。

說明這個會話沒有被完全殺掉。我們再來查查看。

SELECT  A.OWNER,                           A.OBJECT_NAME,                  --OBJECT名稱（表名）  B.XIDUSN,  B.XIDSLOT,  B.XIDSQN,  B.SESSION_ID,                     --鎖表使用者的session  B.ORACLE_USERNAME,                B.OS_USER_NAME,                 --鎖表使用者的作業系統登陸使用者名稱  B.PROCESS,  B.LOCKED_MODE,   C.MACHINE,                  --鎖表使用者的電腦名稱（例如：WORKGROUP\hyl）  C.STATUS,                    --鎖表狀態  C.SERVER,  C.SID,  C.SERIAL#,  C.PROGRAM                  --鎖表使用者所用的資料庫管理工具（例如：developer.exe）FROM  ALL_OBJECTS A,  GV$LOCKED_OBJECT B,  SYS.GV_$SESSION C WHERE  A.OBJECT_ID = B.OBJECT_ID  AND B.PROCESS = C.PROCESS ORDER BY 1,2

看到該會話的狀態是killed。

下面嘗試在作業系統下，殺掉進程。

通過gv$session視圖查看到sid（sid為1228）對應的addr。

再通過addr到gv$process視圖中，查看到session的spid，最後到作業系統下kill掉這個進程。如下，查看到了這個session的spid，

select   *  from   gv$process   where   addr = 'addr資訊' ;

如下：

到作業系統下，查看一下這個進程，如下：

[oracle@xzxtdb2 ~]$ ps  -ef |grep  71941

oracle   36647 36545  0 16:27 pts/1    00:00:00 grep 71941

oracle   71941     1 41 Jul09 ?        09:34:55 oraclexzxt2 (LOCAL=NO)

殺掉71941這個進程，如下：

[oracle@xzxtdb2 ~]$ kill  -9  71941

[oracle@xzxtdb2 ~]$ ps  -ef |grep 71941

oracle   36687 36545  0 16:28 pts/1    00:00:00 grep 71941

--這條資訊是grep本身

用下面這條指令再發起查詢，更清晰的顯示出來，如下：

[oracle@xzxtdb2 ~]$ ps -ef |grep 71941|grep -v grep

無資訊

說明spid為71941的session已經被kill掉了。

 

再次truncate表，成功。

truncate table  tb_表名 ;

 

小結：

         在rac下kill鎖表會話時，需要注意查看會話歸于于哪個執行個體，然後再對其kill。如果無法在sqlplus下殺掉，嘗試到作業系統下對其kill。

         順序指令如下：

查詢rac下活動的鎖表會話資訊：

SELECT  A.OWNER,                        --OBJECT所屬使用者  A.OBJECT_NAME,                  --OBJECT名稱  B.XIDUSN,  B.XIDSLOT,  B.XIDSQN,  B.SESSION_ID,                   --鎖表使用者的session  B.ORACLE_USERNAME,              --鎖表使用者的Oracle使用者名稱  B.OS_USER_NAME,                 --鎖表使用者的作業系統登陸使用者名稱  B.PROCESS,  B.LOCKED_MODE,   C.MACHINE,                      --鎖表使用者的電腦名稱  C.STATUS,                       --鎖表狀態  C.SERVER,  C.SID,  C.SERIAL#,  C.PROGRAM                       --鎖表使用者所用的資料庫管理工具FROM  ALL_OBJECTS A,  GV$LOCKED_OBJECT B,  SYS.GV_$SESSION C WHERE  A.OBJECT_ID = B.OBJECT_ID  AND B.PROCESS = C.PROCESS AND C.STATUS='ACTIVE'ORDERBY1,2;

查詢gv$session視圖，查看會話屬於哪個執行個體：

select * from gv$session wheresid=1228;

殺掉叢集環境下的某個會話：

altersystemkillsession'1228,42549,@執行個體序號';

查詢會話對應的系統進程號：

select * from gv$session where sid='會話id';select * from gv$process where addr='addr資訊';

在資訊中找到spid。

到作業系統下，kill掉進程（oracle使用者下）：

$ kill -9 進程號即spid 

 

*******************************************藍的成長記系列****************************************************

原創作品，出自 “深藍的blog” 部落格，歡迎轉載，轉載時請務必註明出處（http://blog.csdn.net/huangyanlong）。

藍的成長記——追逐DBA（1）：奔波於路上，挺進山東

藍的成長記——追逐DBA（2）：安裝！安裝！久違的記憶，引起我對DBA的重新認知

藍的成長記——追逐DBA（3）：古董上操作，資料匯入匯出成了問題

藍的成長記——追逐DBA（4）：追憶少年情愁，再探oracle安裝（Linux下10g、11g）

藍的成長記——追逐DBA（5）：不談技術談業務，惱人的應用系統

藍的成長記——追逐DBA（6）： 做事與做人：小技術，大為人

藍的成長記——追逐DBA（7）：基礎命令，地基之石

藍的成長記——追逐DBA（8）：重拾SP報告，回憶oracle的STATSPACK實驗

藍的成長記——追逐DBA（9）：國慶漸去，追逐DBA，新規劃，新啟程

藍的成長記——追逐DBA（10）：飛刀防身，熟絡而非專長：擺弄中介軟體Websphere

藍的成長記——追逐DBA（11）：回家後的安逸，暈暈乎乎醒了過來

藍的成長記——追逐DBA（12）：七天七收穫的SQL

藍的成長記——追逐DBA（13）：協調硬體廠商，六個故事：所見所感的“伺服器、儲存、交換器......”

藍的成長記——追逐DBA（14）：難忘的“雲”端，起步的hadoop部署

藍的成長記——追逐DBA（15）：以為FTP很“簡單”，誰成想一波三折

藍的成長記——追逐DBA（16）：DBA也喝酒，被捭闔了

藍的成長記——追逐DBA（17）：是分享，還是消費，在後IOE時代學會成長

******************************************************************************************************************

 

********************************************足球與oracle系列*************************************************

原創作品，出自 “深藍的blog” 部落格，歡迎轉載，轉載時請務必註明出處（http://blog.csdn.net/huangyanlong）。

足球與oracle系列（1）：32路諸侯點兵，oracle32進程聯盟 之A組巴西SMON進程的大局觀

足球與oracle系列（2）：巴西揭幕戰預演，oracle體繫結構雜談

足球與oracle系列（3）：oracle進程排名，世界盃次回合即將戰罷！

足球與oracle系列（4）：從巴西慘敗於德國，想到，差異的RAC拓撲對比！ 

足球與oracle系列（5）：fifa14遊戲缺失的directX庫類比於oracle的rpm包！

足球與oracle系列（6）：伴隨建庫的亞洲杯——加油中國隊

******************************************************************************************************************

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。