故障诊断：备库LGWR常见的library cache lock案例分析

我们的文章会在微信公众号Oracle恢复实录和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

随着Oracle ADG（Active Data Guard）技术的不断成熟，越来越多的企业客户选择将只读类业务迁移到容灾环境（即ADG只读库）中运行。这样做不仅可以减轻主库的压力，还能更好地利用备库资源，提高整体系统的可用性和容错能力。然而，虽然ADG只读库和生产主库的数据是一致的，但由于两者在架构和实现机制上存在一些差异，导致很多客户在实际使用只读库时会遇到各种异常问题，影响了业务体验。
本文将结合实际案例，通俗易懂地介绍在使用ADG只读库时常见的一些“坑”，并分析背后的原因，帮助大家更好地理解和规避这些问题。
1，现象描述

本案例来至于于朋友分享，数据库版本为19c，故障现象为备库每天早上8点40左右，备库的LGWR都会被阻塞。从而其他应用因为请求不到instance lock后被LGWR阻塞，LGWR此时出现library cache lock等待事件。客户第二天重现的时候收集了systemstate dump，下面内容根据systemstate dump进行分析。
2，分析过程

[code]LGWR PROCESS STATE OBJECTROCESS 14: LGWR  ----------------------------------------  SO: 0x3d21de9858, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3   proc=0x3d21de9858, name=process, file=ksu.h LINE:12721, pg=0  (process) Oracle pid:14, ser:2, calls cur/top: 0x3ec22fda30/0x3ec22fda30            flags : (0x6) SYSTEM            flags2: (0x0),  flags3: (0x10)             intr error: 0, call error: 0, sess error: 0, txn error 0            intr queue: empty    ksudlp FALSE at location: 0  (post info) last post received: 0 0 26              last post received-location: ksa2.h LINE:285 ID:ksasnd              last process to post me: 0x3da1e98788 1 0              last post sent: 0 0 259              last post sent-location: kgl.h LINE:8873 ID:kgllkdl: post after freeing latch              last process posted by me: 0x3da1eb2980 171 0    (latch info) wait_event=0 bits=0x0    Process Group: DEFAULT, pseudo proc: 0x3d21ec8180    O/S info: user: oracle, term: UNKNOWN, ospid: 172824     OSD pid info: Unix process pid: 172824, image: oracle@FMS11DG (LGWR)    Short stack dump: ksedsts()+465