个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2021-04-02 14:12:25
aix平台 oracle 19.9 一个测试库，新装2个月后目录 /u01 被撑满。
看了一下cjq的trc达到6g，kill -9 cjq进程，删掉trc文件后，cjq又生成新的trace文件，不断输出以下内容：
-
kgx atomic operation log 700010092238d18
-
mutex 70001005b64d1b8(1276, 0) idn b2958f75 oper excl(6)
-
library cache uid 1276 efd 11 whr 106 slp 0
-
oper=0 pt1=70001005b64d068 pt2=0 pt3=0
-
pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
-
msk=0000-0000-0000-0000-0000
-
-
libraryhandle: address=70001005b64d068 hash=b2958f75 lockmode=0 pinmode=0 loadlockmode=0 status=0
-
objectname: name=pdb2.$build$.e1a9c1cd3f5c4fa9
-
fullhashvalue=51ef46e5f8c212fa19f29eb1b2958f75 namespace=sql area build(82) type=cursor(00) containerid=4 containeruid=2474300379 identifier=0 owneridn=0
-
statistics: invalidationcount=0 executioncount=0 loadcount=0 activelocks=0 totallockcount=0 totalpincount=0
-
counters: brokencount=1 revocablepointer=1 keepdependency=0 version=0 bucketinuse=2069801 handleinuse=2069801 handlereferencecount=0
-
concurrency: dependencymutex=70001005b64d118(0, 2069802, 0, 0) mutex=70001005b64d1b8(1276, 2077580, 3, 6)
-
flags=ron/pin/[00010000] flags2=[0000]
-
waiterslists:
-
lock=70001005b64d0f8[70001005b64d0f8,70001005b64d0f8]
-
pin=70001005b64d0d8[70001005b64d0d8,70001005b64d0d8]
-
loadlock=70001005b64d150[70001005b64d150,70001005b64d150]
-
timestamp:
-
handlereference: address=70001005b64d250 handle=0 flags=[00] kgx cleanup...
-
kgx atomic operation log 700010092238d18
-
mutex 700010061cbf5b0(1276, 0) idn c0d2e94c oper excl(6)
-
library cache uid 1276 efd 11 whr 106 slp 0
-
oper=0 pt1=700010061cbf460 pt2=0 pt3=0
-
pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
-
msk=0000-0000-0000-0000-0000
-
-
libraryhandle: address=700010061cbf460 hash=c0d2e94c lockmode=0 pinmode=0 loadlockmode=0 status=0
-
objectname: name=pdb2.$build$.2f08445d7604e6e2
-
fullhashvalue=098cd86c86f76750740f0c75c0d2e94c namespace=sql area build(82) type=cursor(00) containerid=4 containeruid=2474300379 identifier=0 owneridn=0
-
statistics: invalidationcount=0 executioncount=0 loadcount=0 activelocks=0 totallockcount=0 totalpincount=0
-
counters: brokencount=1 revocablepointer=1 keepdependency=0 version=0 bucketinuse=2069801 handleinuse=2069801 handlereferencecount=0
-
concurrency: dependencymutex=700010061cbf510(0, 2069802, 0, 0) mutex=700010061cbf5b0(1276, 2077581, 3, 6)
-
flags=ron/pin/[00010000] flags2=[0000]
-
waiterslists:
-
lock=700010061cbf4f0[700010061cbf4f0,700010061cbf4f0]
-
pin=700010061cbf4d0[700010061cbf4d0,700010061cbf4d0]
-
loadlock=700010061cbf548[700010061cbf548,700010061cbf548]
-
timestamp:
-
handlereference: address=700010061cbf648 handle=0 flags=[00] kgx cleanup...
-
kgx atomic operation log 700010092238d18
-
mutex 70001007af4a5f0(1276, 0) idn db6b83d8 oper excl(6)
-
library cache uid 1276 efd 11 whr 106 slp 0
-
oper=0 pt1=70001007af4a4a0 pt2=0 pt3=0
-
pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
-
msk=0000-0000-0000-0000-0000
-
-
libraryhandle: address=70001007af4a4a0 hash=db6b83d8 lockmode=0 pinmode=0 loadlockmode=0 status=0
-
objectname: name=pdb2.$build$.5e6949f4e4e100a6
-
fullhashvalue=98f7c004c385c37e8050379fdb6b83d8 namespace=sql area build(82) type=cursor(00) containerid=4 containeruid=2474300379 identifier=0 owneridn=0
-
statistics: invalidationcount=0 executioncount=0 loadcount=0 activelocks=0 totallockcount=0 totalpincount=0
-
counters: brokencount=1 revocablepointer=1 keepdependency=0 version=0 bucketinuse=2069802 handleinuse=2069802 handlereferencecount=0
-
concurrency: dependencymutex=70001007af4a550(0, 2069803, 0, 0) mutex=70001007af4a5f0(1276, 2077580, 3, 6)
-
flags=ron/pin/[00010000] flags2=[0000]
-
waiterslists:
-
lock=70001007af4a530[70001007af4a530,70001007af4a530]
-
pin=70001007af4a510[70001007af4a510,70001007af4a510]
-
loadlock=70001007af4a588[70001007af4a588,70001007af4a588]
-
timestamp:
- handlereference: address=70001007af4a688 handle=0 flags=[00] kgx cleanup...
多租户环境，为了保护原始数据，导入完毕后，把pdb1克隆出一个pdb2，然后pdb2一直处于mount状态。
以下三招不管用：
- kill -9 cjq进程不管用
- 刷新shared_pool不管用
- 删除pdb2也不管用
（删掉pdb2后）重启实例，管用。
原因不明，像是bug。
进一步说明(doc id 2051456.1)：
通常，无论何时访问kgl互斥锁，都会更新互斥锁数据结构，以使访问该互斥锁的当前会话为持有者，并且引用计数会增加。这是一个原子操作，因此非常快，短而小。使用原子操作完成当前会话后，将清除持有者信息，以便其他会话可以重复相同的操作。如果由于某些不可预见的原因，持有kgl互斥锁的进程/会话在清除互斥锁持有人之前被杀死了。同样，在恢复失败的情况下，还有其他实例互斥损坏或损坏的互斥恢复。如果发生这种情况，则pmon会跳过恢复，从而导致kgl互斥锁上的争用过多。请求具有无效持有人信息的互斥锁的任何进程都将挂起，因为永远不会释放持有人并等待“库缓存：互斥锁x”。如果发生这种情况，那么会将kgl mutex分配给分配给无会话进程的伪会话id。这可用于识别发生不良或损坏的互斥恢复。oracle数据库互斥锁是一种用于管理并发性的内存结构。
引自：解决数据库挂起问题，原因是“库高速缓存：互斥x”等待过多（oracle 11.2和更高版本）（文档id 2051456.1）
mutex用途：
这是oracle数据库锁存很长一段时间以来一直在做的事情。
oracle数据库的互斥锁与操作系统的互斥锁不同。
尽管两者都应用了管理并发性的相同原则。
所有这些都是自旋锁的实现。
这意味着，如果进程发现自旋锁以不兼容的模式被获取，
它将重试获取它，直到成功。
其思想是，自旋只会短暂地保持，因此自旋只会持续很短的时间。
进一步分析，根据trace信息：
猜测也许杀掉1276这个session id也能解决问题。
还有个疑问：kgx是什么，难道是她？
肯定没错
相关字段延展：
基本脱离本主题：
原因不明，像是bug。
进一步说明(doc id 2051456.1)：
通常，无论何时访问kgl互斥锁，都会更新互斥锁数据结构，以使访问该互斥锁的当前会话为持有者，并且引用计数会增加。这是一个原子操作，因此非常快，短而小。使用原子操作完成当前会话后，将清除持有者信息，以便其他会话可以重复相同的操作。如果由于某些不可预见的原因，持有kgl互斥锁的进程/会话在清除互斥锁持有人之前被杀死了。同样，在恢复失败的情况下，还有其他实例互斥损坏或损坏的互斥恢复。如果发生这种情况，则pmon会跳过恢复，从而导致kgl互斥锁上的争用过多。请求具有无效持有人信息的互斥锁的任何进程都将挂起，因为永远不会释放持有人并等待“库缓存：互斥锁x”。如果发生这种情况，那么会将kgl mutex分配给分配给无会话进程的伪会话id。这可用于识别发生不良或损坏的互斥恢复。oracle数据库互斥锁是一种用于管理并发性的内存结构。
引自：解决数据库挂起问题，原因是“库高速缓存：互斥x”等待过多（oracle 11.2和更高版本）（文档id 2051456.1）
mutex用途：
这是oracle数据库锁存很长一段时间以来一直在做的事情。
oracle数据库的互斥锁与操作系统的互斥锁不同。
尽管两者都应用了管理并发性的相同原则。
所有这些都是自旋锁的实现。
这意味着，如果进程发现自旋锁以不兼容的模式被获取，
它将重试获取它，直到成功。
其思想是，自旋只会短暂地保持，因此自旋只会持续很短的时间。
进一步分析，根据trace信息：
猜测也许杀掉1276这个session id也能解决问题。
还有个疑问：kgx是什么，难道是她？
肯定没错
相关字段延展：
基本脱离本主题：
给主人留下些什么吧！~~