下午在公司进行业务的时候，发现有一张表的字段原表是整形类型的，但是在etl在同步到pgsql的时候，给他转换成numberic(64,30)类型了，而我又在数据库查询语句写了拼接，导致展示的字段非常的长,于是就修改了一下表的长度，由numberic（64,30）改成了numberic(64,5),然后没有发现，这张表的数据是3000万行,然后自己开发经验也比较少，在数据库修改没有完成的时候，又跑了查询语句，然后导致表被锁了，查询不出数据。

decode(ool."OPTION_NUMBER",
              null,
              ool."LINE_NUMBER" || '.' || ool."SHIPMENT_NUMBER",
              ool."LINE_NUMBER" || '.' || ool."SHIPMENT_NUMBER" || '.' ||
              ool."OPTION_NUMBER") "LINE_NUMBER"
选中被死锁的表，右键选择工具->会话管理器
 
然后将还是active状态的查询，右键Terminate掉即可
 
执行sql：SELECT  * FROM v$lock
此时可以看到 事务2399被阻塞了，阻塞他的事务是2393，同样我们也可以通过 VTRXWAIT视图查看谁阻塞谁。执行sql：SELECT∗FROMVTRXWAIT 视图查看谁阻塞谁。
执行sql：SELECT * FROM   VTRXWAIT视图查看谁阻塞谁。执行sql：SELECT∗FROMVTRXWAIT;
得出同样的结果，ID 为 2399 的事务正在等待 ID 为 2
                                    背景信息MYSQL的MDL锁，用于解决或者保证DDL操作与DML操作之间的一致性，但是在部分场景下会出现阻塞，例如执行DML操作时执行ALTER操作、存在长时间查询时执行ALTER操作等等。表象如下：出现 Waiting  for table metadata lock 且长时间处于等待状态，并阻塞所有后续对表的操作mysqlMDL锁出现场景创建、删除索引。修改表结构。表维护操作（optimize...
一、查询DB2那张表锁表了，并且其中agent_id为被锁表的进程id
通过DbvVisualizer查询锁表的程序
SELECT * FROM TABLE (SNAP_GET_LOCK (’’, -1)) AS T WHERE lock_object_type = ‘TABLE_LOCK’
二、根据查询的agent_id解锁DB2表
首先连接DB2所在的服务器
然后切换到DB2用户
su db2用户户名
敲命令:db2 “froc...
                                    1年多前上线一套基于PostgreSQL 9.6的主从数据库的业务系统。许多的业务表数据量已经超过千万级别，甚至接近亿级别。日常业务操作中，insert/update大约是十万左右，delete大约是三万左右，从而可能有一些表的统计信息不是十分准确。业务系统也存在一些特殊性(程序呆板)，部分业务SQL回访表等都是三四百万级别的。用户反馈业务系统缓慢，IT运维反馈业务系统磁盘IO高，CPU高…不升级硬件无法抗住。在系统会出现ShareLock错误，参考如下：
PostgreSQL的autovacuu
postgresql版本为9.4
一、先查询出锁死的表名
select pid,query,* from pg_stat_activity where datname='zjd_xian_dev_1'  --and waiting='t'
二、找到pid
select oid,relname from pg_class where relname='d_lz_gz';
select locktype,pid,relation,mode,granted,* from p
                                    查询完成之后接着需要使用rollback，不然其它session没法执行语句。
转载于:https://www.cnblogs.com/vanwoos/p/9391078.html