锁_rac环境kill锁表会话后出现killed状态(解决)
原创作品,出自 “深蓝的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
锁_rac环境kill锁表会话后出现killed状态(解决)的更多相关文章
- MySQL 全局锁、表级锁、行级锁,你搞清楚了吗?
大家好,我是小林. 最近重新补充了<MySQL 有哪些锁>文章内容: 增加记录锁.间隙锁.net-key 锁 增加插入意向锁 增加自增锁为 innodb_autoinc_lock_mode ...
- MySQL学习笔记(五):MySQL表级锁和行级锁
一:概述 相对其他数据库而言,MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制.比如,MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking ...
- MySQL表级锁和行级锁
一:概述 相对其他数据库而言,MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制.比如,MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking ...
- MySQL锁(表锁,行锁,共享锁,排它锁,间隙锁)使用详解
锁,在现实生活中是为我们想要隐藏于外界所使用的一种工具.在计算机中,是协调多个进程或县城并发访问某一资源的一种机制.在数据库当中,除了传统的计算资源(CPU.RAM.I/O等等)的争用之外,数据也是一 ...
- MySQL行级锁、表级锁、页级锁详细介绍
原文链接:http://www.jb51.net/article/50047.htm 页级:引擎 BDB.表级:引擎 MyISAM , 理解为锁住整个表,可以同时读,写不行行级:引擎 INNODB , ...
- Mysql 的表级锁和行级锁
表级锁 MySQL表级锁分为读锁和写锁. 读锁 用法:LOCK TABLE table_name [ AS alias_name ] READ 释放锁使用UNLOCK tables.可以为表使用别名, ...
- Mysql的表级锁和行级锁
表级锁 MySQL表级锁分为读锁和写锁. 读锁 用法:LOCK TABLE table_name [ AS alias_name ] READ 释放锁使用UNLOCK tables.可以为表使用别名, ...
- mysql--->innodb引擎什么时候表锁什么时候行锁?
mysql innodb引擎什么时候表锁什么时候行锁? InnoDB基于索引的行锁 InnoDB行锁是通过索引上的索引项来实现的,这一点MySQL与Oracle不同,后者是通过在数据中对相应数据行加锁 ...
- 【问答分享第一弹】MySQL锁总结:MySQL行锁、表锁、排他锁、共享锁的特点
大家好,我是小于哥哈.前几天能分享了第一期面试题,MySQL 中有哪几种锁 和 这些锁各有哪些特点 ,这道面试题是经常会被问到的一个面试题,大家反馈的都挺不错的.今天特此来总结一下. 首发于公众号[终 ...
随机推荐
- 找不到库文件地址,修改修改方法framework
直接双击地址行修改
- solr学习之入门篇
一,简介 Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口.用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引:也可以通过Http ...
- (转)JSON数据格式和js操作json总结
原:http://niutuku.com/tech/javaScript/273643.shtml JSON数据格式和js操作json总结 来源:niutuku.com | vince ...
- hdu 2092
Ps:wa了两次....一次是从加法那边暴力,然而算法错误..应该从乘法那边暴力破解...然而又没算负数..加上负数..直接暴力AC. 代码: #include "stdio.h" ...
- UID 修改 & UID 锁死修复
首先是UID修改的问题,只要卡是UID卡,就都可以修改UID,首先读卡器连接电脑,卡片放到读卡器上. 然后我们要用一个工具,UID207.打开UID207.exe,点Initialize,初始化. 然 ...
- Varnost slovenskih GSM omrežij III
V torek smo pisali tudi o tem, da Si.Mobil v svojem omrežju dovoli uporabo A5/0 (nešifriranega preno ...
- css3制作六边形图片
效果图: 实现原理: 这个效果的主要css样式有: 1.>transform: rotate(120deg); 图片旋转 2.>overflow:hidden; 超出隐藏 3.>v ...
- false等于0???
看到一个函数strpos($string,$str),用于在字符串$string中查找$str,如果在$string中查找到$str,则返回第一次出现的位置,起始位置为0:如果$string中不包含$ ...
- Anniversary party_树形DP
Description There is going to be a party to celebrate the 80-th Anniversary of the Ural State Univer ...
- LeetCode Bulls and Cows (简单题)
题意: 给出两个数字,输出(1)有多少位是相同的(2)有多少位不在正确的位置上. 思路: 扫一遍,统计相同的,并且将两串中不同的数的出现次数分别统计起来,取小者之和就是第2个答案了. class So ...