一、环境描述
操作系统: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