Postgresql 解决锁表
##一、postgresql解决锁表
--查询是否锁表了
select oid from pg_class where relname='可能锁表了的表'
select pid from pg_locks where relation='上面查出的oid'
--如果查询到了结果,表示该表被锁 则需要释放锁定
select pg_cancel_backend(上面查到的pid)
12345
转载地址:https://yq.aliyun.com/ask/184?order=ctime
-- 用一个函数来将锁转换为数字,
create or replace function f_lock_level(i_mode text) returns int as
$$
begin
case i_mode
when 'INVALID' then return 0;
when 'AccessShareLock' then return 1;
when 'RowShareLock' then return 2;
when 'RowExclusiveLock' then return 3;
when 'ShareUpdateExclusiveLock' then return 4;
when 'ShareLock' then return 5;
when 'ShareRowExclusiveLock' then return 6;
when 'ExclusiveLock' then return 7;
when 'AccessExclusiveLock' then return 8;
else return 0;
end case;
end;
language plpgsql strict;
-- 修改查询语句,按锁级别排序:
with t_wait as
( select a.mode,a.locktype,a.database,a.relation,a.page,a.tuple,a.classid,a.objid,a.objsubid,
a.pid,a.virtualtransaction,a.virtualxid,a,transactionid,b.query,b.xact_start,b.query_start,
b.usename,b.datname
from pg_locks a,pg_stat_activity b
where a.pid=b.pid and not a.granted
),
t_run as
(
select a.mode,a.locktype,a.database,a.relation,a.page,a.tuple,a.classid,a.objid,a.objsubid,
a.pid,a.virtualtransaction,a.virtualxid,a,transactionid,b.query,b.xact_start,b.query_start,
b.usename,b.datname
from pg_locks a,pg_stat_activity b
where a.pid=b.pid and a.granted
)
select r.locktype,r.mode r_mode,r.usename r_user,r.datname r_db,r.relation::regclass,r.pid r_pid,
r.page r_page,r.tuple r_tuple,r.xact_start r_xact_start,r.query_start r_query_start,
now()-r.query_start r_locktime,r.query r_query,w.mode w_mode,w.pid w_pid,w.page w_page,
w.tuple w_tuple,w.xact_start w_xact_start,w.query_start w_query_start,
now()-w.query_start w_locktime,w.query w_query
from t_wait w,t_run r
where r.locktype is not distinct from w.locktype
and r.database is not distinct from w.database
and r.relation is not distinct from w.relation
and r.page is not distinct from w.page
and r.tuple is not distinct from w.tuple
and r.classid is not distinct from w.classid
and r.objid is not distinct from w.objid
and r.objsubid is not distinct from w.objsubid
and r.transactionid is not distinct from w.transactionid
and r.pid <> w.pid
order by f_lock_level(w.mode)+f_lock_level(r.mode) desc,r.xact_start;
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455
--现在可以排在前面的就是锁级别高的等待,优先干掉这个。
-[ RECORD 1 ]-+---------------------------------------------------------------------
locktype | relation -- 冲突类型
r_mode | ShareUpdateExclusiveLock -- 持锁模式
r_user | postgres -- 持锁用户
r_db | postgres -- 持锁数据库
relation | tbl -- 持锁对象
r_pid | 25656 -- 持锁进程
r_xact_start | 2015-05-10 14:11:16.08318+08 -- 持锁事务开始时间
r_query_start | 2015-05-10 14:11:16.08318+08 -- 持锁SQL开始时间
r_locktime | 00:01:49.460779 -- 持锁时长
r_query | vacuum freeze tbl; -- 持锁SQL,注意不一定是这个SQL带来的锁,也有可能是这个事务在之前执行的SQL加的锁
w_mode | AccessExclusiveLock -- 等待锁模式
w_pid | 26731 -- 等待锁进程
w_xact_start | 2015-05-10 14:11:17.987362+08 -- 等待锁事务开始时间
w_query_start | 2015-05-10 14:11:17.987362+08 -- 等待锁SQL开始时间
w_locktime | 00:01:47.556597 -- 等待锁时长
w_query | truncate tbl; -- 等待锁SQL
-[ RECORD 2 ]-+---------------------------------------------------------------------
locktype | relation
r_mode | ShareUpdateExclusiveLock
r_user | postgres
r_db | postgres
relation | tbl
r_pid | 25656
r_xact_start | 2015-05-10 14:11:16.08318+08
r_query_start | 2015-05-10 14:11:16.08318+08
r_locktime | 00:01:49.460779
r_query | vacuum freeze tbl;
w_mode | RowExclusiveLock
w_pid | 25582
w_xact_start | 2015-05-10 14:11:22.845+08
w_query_start | 2015-05-10 14:11:22.845+08
w_locktime | 00:01:42.698959
w_query | insert into tbl(crt_time) select now() from generate_series(1,1000); -- 这个SQL其实等待的是truncate tbl的锁;
......
Postgresql 解决锁表的更多相关文章
- postgresql解决锁表
--查询是否锁表了select oid from pg_class where relname='可能锁表了的表'select pid from pg_locks where relation='上面 ...
- oracle 解决锁表问题
--首先查看有哪些锁 select /*+ rule */ s.username, decode(l.type,'TM','TABLE LOCK','TX','ROW LOCK',nu ...
- orcal解决锁表
1.查看历史运行纪录 select * from dba_jobs_running: 2查看锁住的sid和pid select s.sid,s.serial# fromv$session s wher ...
- Oracle故障排查之oracle解决锁表问题
--step 1:查看被阻塞会话等待事件 select sid, event, username, lockwait, sql.sql_text from v$session s, v$sql sq ...
- MYSQL锁表问题的解决方法
本文实例讲述了MYSQL锁表问题的解决方法.分享给大家供大家参考,具体如下: 很多时候!一不小心就锁表!这里讲解决锁表终极方法! 案例一 mysql>show processlist; 参看sq ...
- MYSQL锁表问题解决
本文实例讲述了MYSQL锁表问题的解决方法.分享给大家供大家参考,具体如下: 很多时候!一不小心就锁表!这里讲解决锁表终极方法! 案例一 ? 1 mysql>show processlist; ...
- 关于oracle的锁表解决session marked for kill
oracle 使用的过程中,有时候会遇到锁表的情况,数据库增.删.改.查都是会锁表的,但是锁的类型会不同, 大多是行锁,部分会是表锁. 在oracle运行中,一直是有表在锁的,只不过很快一个操作结束, ...
- Mysql错误: ERROR 1205: Lock wait timeout exceeded解决办法(MySQL锁表、事物锁表的处理方法)
Java执行一个SQL查询未提交,遇到1205错误. java.lang.Exception: ### Error updating database. Cause: java.sql.SQLExc ...
- MySQL锁表解决方法
https://blog.csdn.net/a5582ddff/article/details/79566678 MySQL锁表解决方法 一.我的处理过程 1.查进程,主要是查找被锁表的那个进程的ID ...
随机推荐
- ORAchk - 数据库配置检查工具
1.概要2.下载和安装3.如何执行4.执行过程5.报告6.参考 1.概要 ORAchk之前被称为RACcheck,后来它的检查范围进行了扩展,改名为了ORAchk,它是在数据库系统进行健康检查的一个专 ...
- 通过tushare获取股票价格
# Author llll # coding=utf-8 # ---描述# 完成股票 价格查询和展示# 不直接根据网页进行爬虫获取股票价格,而是通过已有组件查询股票价格,并保存到csv文件或者exce ...
- 05 IO流(三)——IO流标准流程
流程 选择源 选择合适的流 操作 关闭流:先打开的后关闭 演示 import java.io.File; import java.io.InputStream; import java.io.File ...
- AX 中临时表应用
临时表,只要让表的Temporary属性设为yes就行. 今天写代码时发现,假如在一个循环里面把数据插入到临时表里, 假如没有在每次开始时没加clear的话,假如有个字段下一条没数据,会自动带到下一条 ...
- PB笔记之第一行数据不能删除的解决方法
如果第一行数据不能删除,则单独写SQL进行删除 window lw_sheet //dw_1.event pfc_deleterow()long i String ls_manidInteger ls ...
- jquery滚动到顶部
<script> $.fn.scrollTo = function (options) { var defaults = { toT: , //滚动目标位置 durTime: , //过渡 ...
- .NET Standards
.net的创始者们在一开始的时候,就意识到了他们的编程技术可以用在不通的操作系统和不同类型的cpu上.他们改进了20世纪90年代编程语言实现技术.最主要的一条是,不同的编程语言对应统一个运行时,及CL ...
- 前端开发 Vue -4promise解读2
https://www.runoob.com/vue2/vue-tutorial.html promise promise是什么? 1.主要用于异步计算 2.可以将异步操作队列化,按照期望的顺序执 ...
- PCA(Principal Component Analysis)笔记
PCA是机器学习中recognition中的传统方法,今天下午遇到了,梳理记一下 提出背景: 二维空间里,2个相近的样本,有更大概率具有相同的属性,但是在高维空间里,由于样本在高维空间里,呈现越来越稀 ...
- PLSQL登录的时候Warning提示:Using a filter for all users can lead to poor performance!
转自: https://blog.csdn.net/athena2015/article/details/81811908