记一次library cache lock/library cache pin导致的函数编译hang住分析及处理过程

最新推荐文章于 2024-04-28 15:56:10 发布

数据和云

最新推荐文章于 2024-04-28 15:56:10 发布

阅读量197

点赞数

文章标签：数据库 java 编程语言 redis 人工智能

本文链接：https://blog.csdn.net/enmotech/article/details/113577182

版权

本文记录了一次由于library cache lock导致的函数编译hang住的问题，通过排查发现是并发访问同一函数导致的冲突。经过分析，找出问题根源并解决，最终通过结束阻塞会话使得函数编译正常完成。

摘要由CSDN通过智能技术生成

墨墨导读：业务在进行alter function my_function_name compile时，有两个函数编译无法通过，现象就是会hang住，这里分享处理的整个过程。

一、前言

业务在进行alter function my_function_name compile的时候，正常来说会非常快(不涉及无法访问的dblink时)，但是今天一大早，业务告诉我，他们有两个函数编译无法通过，现象就是会hang住，需要我进行分析并处理下问题。

二、问题排查

看到这个问题的时候，最初就是认为，数据库肯定是有锁了，导致这个编译过程的语句，执行无法通过。所以，第一时间检查了下数据库中是否存在行锁：

SQL> @block
no rows selected

可以看到，此时并没有排查到数据库有行锁。

此时，我在sqlplus中，手动执行该函数的编译过程：

SQL> select * from v$mystat where rownum<2;
       SID STATISTIC#      VALUE---------- ---------- ----------      4994          0          0
SQL>alter function XXX compile;

确实，发现编译过程hang住了。

接着，打开另一个会话，查看该会话的运行情况、等待事件及阻塞情况：

SQL> select sid,seq#,event,wait_class from v$session_wait where sid=4994;
                                           WAIT       SID       SEQ# EVENT                CLASS---------- ---------- -------------------- ---------------      4994         41 library cache lock   Concurrency

可以发现，执行函数编译的会话，被sid为368的会话阻塞，而该会话的等待事件则是library cache lock，且wait_class为Concurrency。

那么，在什么情况下，可能会造成library cache lock等待事件，并且会阻塞住会话呢？

从官方文档上可以看到对library cache lock等待事件有如下描述：

This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either:

One client can prevent other clients from accessing the same object.

The client can maintain a dependenc