这篇文章主要讲解了“怎么解决12cRAC打补丁后PDB进入受限模式问题”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决12cRAC打补丁后PDB进入受限模式问题”吧！
一、环境描述
操作系统：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关闭后，只开启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感谢各位的阅读，以上就是“怎么解决12cRAC打补丁后PDB进入受限模式问题”的内容了，经过本文的学习后，相信大家对怎么解决12cRAC打补丁后PDB进入受限模式问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
