有客户找到我这边咨询，说他们的一套核心ADG库在业务高峰期报错，因为业务做了读写分离，其备库也实际承担读业务，所以备库故障也会对业务产生影响。
这里也要提醒大家，做读写分离，如果读库出现故障的情况，要有切换到主库的应急方案考虑进去。
客户这里自己通过重启备库暂时解决，但担心故障再现，所以非常着急要分析原因和给出解决方案。
最直接的报错信息ORA-29771，具体如下：
ORA-29771: process USER (OSID 403660) blocks LGWR (OSID 195873) for more than 70 seconds
USER (ospid: 403660) is blocking LGWR (ospid: 195873) in a wait
LMHB (ospid: 195787) kills USER (ospid: 403660).
客户数据库版本是19.13。
我在接手后第一时间就先要求让客户安排人去开一个SR，我们有很多客户明明有买标服，但遇到紧急故障却不第一时间去开SR，而是依赖熟悉的技术人员帮着排查，以为这样就会省时间，其实这是很多客户的一个误区。
首先开SR并不会浪费多少时间，而且也可以让其他有时间的同事帮忙去提。也不会影响熟悉的技术人员排查，两条路一起走，更保险。而且有了SR，原厂的工程师们就可以通过SR号直接了解问题的基础背景信息，可以共同努力协同排查。
开完SR我这边也拿到客户的报错日志去帮助分析，在MOS发现这个错误对应不少bug，但版本不完全匹配，很多也有去设置 _adg_parselock_timeout 这个隐藏参数的workaround，这时具体就需要后台负责分析SR的工程师去进一步确认。
果然，后台最终定位是一个已知bug，根据客户19.13的版本，提供了对应版本的补丁下载。
需要注意的是应用完补丁之后还有其他操作，其中就涉及到上面提到的隐藏参数，老老实实的按文档步骤规范操作即可。
这里要给后台工程师点个赞，工程师在向客户索取了一些必要的TFA信息和ASH DUMP信息，经过分析后最终给出的指导意见也非常清晰，如下(涉及的系统名字等敏感信息已脱敏)：
xxxxx2的lmhb进程的incident文件显示，LGWR多次被user process阻塞，等待状况如下。
--------------
ORA-29771: process USER (OSID 360031) blocks LGWR (OSID 195873) for more than 70 seconds
ORA-29771: process USER (OSID 344407) blocks LGWR (OSID 195873) for more than 70 seconds
ORA-29771: process USER (OSID 359423) blocks LGWR (OSID 195873) for more than 70 seconds
ORA-29771: process USER (OSID 374130) blocks LGWR (OSID 195873) for more than 70 seconds
ORA-29771: process USER (OSID 373345) blocks LGWR (OSID 195873) for more than 70 seconds
--------------
现象发生时的wait chain都具有下面的特征，LGWR等待"library cache lock"，USERS等待
"library cache load lock"。
xxxxx2_lmhb_195787.trc
=============================
*** 2023-04-24T10:28:55.315074+08:00
LGWR (ospid: 195873) has not moved for 64 sec (1682303334.1682303270)
: heartbeat check status 2 (acceptable) (threshold 70 sec)
: heartbeat poke time 0x6445e62b req 0x167aaf ack 0x167aae freq 10
: heartbeat state 0x1.ffff (inwait) pso-flag 0x0
: waiting for event 'library cache lock' for 832 secs with wait_id 206722203.
===[ Wait Chain ]===
LGWR (ospid: 195873) waits for event 'library cache lock'.
USER (ospid: 403660) waits for event 'library cache load lock'.
USER (ospid: 201329) waits for event 'cursor: pin S wait on X'.
USER (ospid: 292695) waits for event 'gc cr request'.
在ADG环境中，有下面的文档描述了USER进程阻塞LGWR引发ORA-29771的相同现象。
该现象在internal Bug 31961214中进行了调查。
ORA-29771 USER Process Blocks LGWR For More Than 70 Seconds Standby database (ADG) (Doc ID 2862283.1)
我确认了一下，针对您的环境DBRU 19.13提供了该Bug的修复补丁。请您访问下面的链
接下载并安装该补丁，确认相同现象是否还有重现性。
https://updates.oracle.com/download/31961214.html
Select a Release 选择 Oracle Database 19.13.0.0.0 DBRU
Platform or Language 选择 Linux x86-64
请注意安装完补丁之后，需要按照Doc ID 2862283.1的说明，修改相应的参数。
所以，通过这个比较简单的已知bug问题定位和处理，也鼓励我们的客户以后遇到问题能够及时提交SR，不要白白浪费了这么好的资源哈。
记录一次开发中遇到的关于 ThreadLocal 问题，场景是数据库表中的操作人总是无缘无故的被更改，排查了几遍代码才发现是 ThreadLocal 没有及时清理导致的。