Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1551982
  • 博文数量: 350
  • 博客积分: 1860
  • 博客等级: 上尉
  • 技术积分: 3888
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-07 08:51
个人简介

偶尔有空上来看看

文章分类

全部博文(350)

文章存档

2021年(80)

2020年(115)

2019年(11)

2018年(9)

2017年(9)

2016年(17)

2015年(7)

2014年(4)

2013年(1)

2012年(11)

2011年(27)

2010年(35)

2009年(11)

2008年(11)

分类: Oracle

2021-04-02 14:12:25


AIX平台 oracle 19.9 一个测试库,新装2个月后目录 /u01 被撑满。
看了一下cjq的trc达到6G,kill -9 cjq进程,删掉trc文件后,cjq又生成新的trace文件,不断输出以下内容:
 
  1. KGX Atomic Operation Log 700010092238d18
  2.  Mutex 70001005b64d1b8(1276, 0) idn b2958f75 oper EXCL(6)
  3.  Library Cache uid 1276 efd 11 whr 106 slp 0
  4.  oper=0 pt1=70001005b64d068 pt2=0 pt3=0
  5.  pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
  6.  msk=0000-0000-0000-0000-0000

  7. LibraryHandle: Address=70001005b64d068 Hash=b2958f75 LockMode=0 PinMode=0 LoadLockMode=0 Status=0
  8.   ObjectName: Name=pdb2.$BUILD$.e1a9c1cd3f5c4fa9
  9.     FullHashValue=51ef46e5f8c212fa19f29eb1b2958f75 Namespace=SQL AREA BUILD(82) Type=CURSOR(00) ContainerId=4 ContainerUid=2474300379 Identifier=0 OwnerIdn=0
  10.   Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=0 ActiveLocks=0 TotalLockCount=0 TotalPinCount=0
  11.   Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 Version=0 BucketInUse=2069801 HandleInUse=2069801 HandleReferenceCount=0
  12.   Concurrency: DependencyMutex=70001005b64d118(0, 2069802, 0, 0) Mutex=70001005b64d1b8(1276, 2077580, 3, 6)
  13.   Flags=RON/PIN/[00010000] Flags2=[0000]
  14.   WaitersLists:
  15.     Lock=70001005b64d0f8[70001005b64d0f8,70001005b64d0f8]
  16.     Pin=70001005b64d0d8[70001005b64d0d8,70001005b64d0d8]
  17.     LoadLock=70001005b64d150[70001005b64d150,70001005b64d150]
  18.   Timestamp:
  19.   HandleReference: Address=70001005b64d250 Handle=0 Flags=[00] KGX cleanup...
  20. KGX Atomic Operation Log 700010092238d18
  21.  Mutex 700010061cbf5b0(1276, 0) idn c0d2e94c oper EXCL(6)
  22.  Library Cache uid 1276 efd 11 whr 106 slp 0
  23.  oper=0 pt1=700010061cbf460 pt2=0 pt3=0
  24.  pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
  25.  msk=0000-0000-0000-0000-0000

  26. LibraryHandle: Address=700010061cbf460 Hash=c0d2e94c LockMode=0 PinMode=0 LoadLockMode=0 Status=0
  27.   ObjectName: Name=pdb2.$BUILD$.2f08445d7604e6e2
  28.     FullHashValue=098cd86c86f76750740f0c75c0d2e94c Namespace=SQL AREA BUILD(82) Type=CURSOR(00) ContainerId=4 ContainerUid=2474300379 Identifier=0 OwnerIdn=0
  29.   Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=0 ActiveLocks=0 TotalLockCount=0 TotalPinCount=0
  30.   Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 Version=0 BucketInUse=2069801 HandleInUse=2069801 HandleReferenceCount=0
  31.   Concurrency: DependencyMutex=700010061cbf510(0, 2069802, 0, 0) Mutex=700010061cbf5b0(1276, 2077581, 3, 6)
  32.   Flags=RON/PIN/[00010000] Flags2=[0000]
  33.   WaitersLists:
  34.     Lock=700010061cbf4f0[700010061cbf4f0,700010061cbf4f0]
  35.     Pin=700010061cbf4d0[700010061cbf4d0,700010061cbf4d0]
  36.     LoadLock=700010061cbf548[700010061cbf548,700010061cbf548]
  37.   Timestamp:
  38.   HandleReference: Address=700010061cbf648 Handle=0 Flags=[00] KGX cleanup...
  39. KGX Atomic Operation Log 700010092238d18
  40.  Mutex 70001007af4a5f0(1276, 0) idn db6b83d8 oper EXCL(6)
  41.  Library Cache uid 1276 efd 11 whr 106 slp 0
  42.  oper=0 pt1=70001007af4a4a0 pt2=0 pt3=0
  43.  pt4=0 pt5=0 ub4=0 flg=0x0 uw1=0 uw2=0
  44.  msk=0000-0000-0000-0000-0000

  45. LibraryHandle: Address=70001007af4a4a0 Hash=db6b83d8 LockMode=0 PinMode=0 LoadLockMode=0 Status=0
  46.   ObjectName: Name=pdb2.$BUILD$.5e6949f4e4e100a6
  47.     FullHashValue=98f7c004c385c37e8050379fdb6b83d8 Namespace=SQL AREA BUILD(82) Type=CURSOR(00) ContainerId=4 ContainerUid=2474300379 Identifier=0 OwnerIdn=0
  48.   Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=0 ActiveLocks=0 TotalLockCount=0 TotalPinCount=0
  49.   Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 Version=0 BucketInUse=2069802 HandleInUse=2069802 HandleReferenceCount=0
  50.   Concurrency: DependencyMutex=70001007af4a550(0, 2069803, 0, 0) Mutex=70001007af4a5f0(1276, 2077580, 3, 6)
  51.   Flags=RON/PIN/[00010000] Flags2=[0000]
  52.   WaitersLists:
  53.     Lock=70001007af4a530[70001007af4a530,70001007af4a530]
  54.     Pin=70001007af4a510[70001007af4a510,70001007af4a510]
  55.     LoadLock=70001007af4a588[70001007af4a588,70001007af4a588]
  56.   Timestamp:
  57.   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是什么,难道是她?

肯定没错


相关字段延展:


基本脱离本主题:

阅读(1177) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~