cjq进程的trc文件非常大

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是什么，难道是她？

肯定没错


相关字段延展：


基本脱离本主题：