一、环境描述

操作系统：Redhat 7.4

数据库:12cRAC 4节点

PDB数量：20多个

总体数据量：30T

RU：DATABASE JAN 2020 RELEASE UPDATE 12.2.0.1.200114

二、主要问题

在节点1运行datapatch verbose后，其中一个PDB进入受限模式。

三、问题描述

晚上12点左右在节点1运行./datapatch verbose后，然后一直等待，2个小时后，终端开始反馈信息。

反馈的信息是：20几个PDB打补丁成功No errors。剩下3个PDB和CDB$ROOT显示等待超时的错误：

CDBROOT:

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_STATS

PDB1:

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_SPACE_ADMIN

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_STATS

PDB2:

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_SPACE_ADMIN

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_SNAPSHOT_UTL

PDB3：

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_STATS

然后数据库又开始自动对这4个PDB进行datapatch，等了大概半个小时，CDB$ROOT、PDB1、PDB2显示打补丁成功NO erros，PDB3失败，然后数据库就自动结束打补丁了，错误信息如下：

OACX:

ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_STATS

/datapatch verbose后，查看PDB3的日志，显示的ORA-报错都是有IGNORED ERROR标志。然后show pdbs，查看PDB的状态，发现PDB3进入了受限状态。

PDB_PLUG_IN_VIOLATIONS信息如下图：

将所有PDB关闭后，只开启PDB3。尝试单独对这个PDB3重新运行./datapatch verbose：

只会显示Nothing to roll back Nothing to apply

检查DBA_REGISTRY_SQLPATCH视图，会显示PATCH的status为WITH ERRORS(RETRYABLE)

四、问题分析

当时现场就对该PDB进行重打和回滚尝试，一概显示Nothing to roll back Nothing to apply。然后提SR，让oracle原厂的人到现场分析，他们也没遇到过这种情况，给的建议是进入startup upgrade后重新运行datapatch，但是还是一样的状况。

通过查看具体的日志，可能的原因是当时刚好是数据库自动收集统计信息的时间段，SYS.DBMS_STATS被锁了，而这个PDB又比较大，而且有大量的全文索引，导致这个PDB失败打补丁失败。

五、临时处理方法

PDB进入受限模式后，普通用户是无法连接数据库的，必须授予restricted session的权限才能连接。另外所有的job都是不能自动跑起来的。通过手工授予所有业务用户restricted session和crontab跑job的方式解决。

六、最后的解决方法

通过数据泵的方式在测试库上恢复了这个PDB，然后尝试将SYS.DBMS_STATS这个包通过收集全库统计信息的方式锁住，然后再运行datapatch，果然重现了这个问题。最后经过不断的测试，发现可以通过如下方法修复这个问题：强行打补丁，并指定补丁包的号码。

/datapatch -force -verbose -bundle_series 200114 -apply 30593149 -pdb PDB3