oracle Update语句卡死,详细情况见下文

按你的描述，应该就是锁表了，并不是卡死。检查是否for update 的 *** 作。

我不知道你是什么检查锁表的，检查锁表时是否有用户名作为条件了？不加条件试试。

怀疑有可能是你 *** 作数据库用户这张表对其他用户进行授权了，被授权的用户进行删除，如果限制了username可能会查不到。

常规查询锁表方法如下：

查出锁定表的sid, serial#,os_user_name, machine_name, terminal，锁的type,mode

SELECT s.sid, s.serial#, s.username, s.schemaname, s.osuser, s.process, s.machine,

s.terminal, s.logon_time, l.type

FROM v$session s, v$lock l

WHERE s.sid = l.sid

AND s.username IS NOT NULL

ORDER BY sid

这个语句将查找到数据库中所有的DML语句产生的锁，还可以发现，

任何DML语句其实产生了两个锁，一个是表锁，一个是行锁。

--杀掉进程 sid,serial#

例如锁表进程的sid = 210 ， serial# = 11562，执行如下命令。

alter system kill session'210,11562'

希望对你有帮助，欢迎采纳！

用的是单机数据库吗？ 如果数据量过大性能可能无法支撑，可以尝试改用分布式数据库。

相对于单机数据库，分布式数据库的数据分布式存储，读写分离，性能高，在线一键平滑扩容，感兴趣可以了解一下。

顺便给个福利，华为云分布式数据库中间件DDM正在做试用体验活动，可以了解一下。

请先select * approved_maininfo t set t.declareflag='y' where 1=1 and t.seqcode=263 按F5出计划解释窗口，分析执行效率，估计select的执行效率也很低，性能优化没做好。查执行时间超过1秒的进程：select event,username,sid,serial#,status,last_call_et,sql_hash_value,prev_hash_value

from v$session wherestatus='ACTIVE' and last_call_et>1 and username is not null查询对应的语句select *from v$sqltext where hash_value='上面查出来的hashvalue' order by piece

---