怎么解决12cRAC打补丁后PDB进入受限模式问题

这篇文章主要讲解了“怎么解决12cRAC打补丁后PDB进入受限模式问题”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决12cRAC打补丁后PDB进入受限模式问题”吧！一、环境描述操作系统：Redhat 7.4数据库:12cRAC 4节点PD免费主机域名B数量：20多个总体数据量：30TRU：DATABASE JAN 2020 RELEASE UPDATE 12.2.0.1.200114二、主要问题在节点1运行datapatch verbose后，其中一个PDB进入受限模式。三、问题描述晚上12点左右在节点1运行./datapatch verbose后，然后一直等待，2个小时后，终端开始反馈信息。反馈的信息是：2免费主机域名0几个PDB打补丁成功No errors。剩下3个PDB和CDB$ROOT显示等待超时的错误：然后数据库又开始自动对这4个PDB进行datapatch，等了大概半个小时，CDB$ROOT、PDB1、PDB2显示打补丁成功NO erros，PDB3失败，然后数据库就自动结束打补丁了，错误信息如下：/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，果然重现了这个问题。最后经过不断的测试，发现可以通过如下方法修复这个问题：强行打补丁，并指定补丁包的号码。感谢各位的阅读，以上就是“怎么解决12cRAC打补丁后PDB进入受限模式问题”的内容了，经过本文的学习后，相信大家对怎么解决12cRAC打补丁后PDB进入受限模式问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是云技术，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: MySql快速插入以及批量更新的方法

这篇文章主要讲解了“MySql快速插入以及批量更新的方法”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“MySql快速插入以及批量更新的方法”吧！插入：　　MySql提供了可以一次插入多条数据的用法：　　[sql…