转载：19.6.2 DBCA建库后,PDB处于受限模式

注意：本篇文档是转载自微信公众号：ANBOB手记  weejar 

 

 

1.1问题现象

LINUX REDHAT 6.9,2节点RAC

安装19.3 GI,ORACLE软件后，打19.6.2 RUR补丁 GI,ORACLE软件后。

DBCA建库，需要3个小时，并且DBCA成功完成后，观察到种子库及PDB均处于受限模式。

Version 19.6.2.0.0
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  YES
         3 PDB1                              READ WRITE YES

之前检索很多文档没有找到答案，直到公众号分享的一篇文章，找到了答案，如下截取信息。

1.2问题场景

 

Alert: Orace 19c DBCA花4小时完成，如何避免？
原创 weejar  ANBOB手记  4月11日

上周同事在安装Oracle 19c RAC环境时，全新的软件在安装了当前最新的19.6 RU后，DBCA创建数据库居然花了4个小时左右，环境RHEL 7.5 , 本地全SSD 硬盘，
共享存储是”菊厂”的高端全闪阵列，这样的速度不能忍。目前在MOS没有相关记录的BUG,  不过最终找到了原因，这里记录分享一下这个问题。
这个有问题有一定的场景，能否遇到取决于安装方法的选择，养成好习惯受益终身。
场景1， 安装步骤
1， 安装全新的Oracle 19.3 GI 和DB 环境, DB 选择只安装软件
2， 安装应用19.6 RU到当前环境中GI 和DB
3,   使用DBCA 创建新的数据库， 在OUI 图形的Deployment Type选项卡，如果是习惯性的选择“Custom Database”
然后接下的安装会非常顺利。
场景2， 安装步骤
1， 安装全新的Oracle 19.3 GI 和DB 环境, DB 选择只安装软件
2， 安装应用19.6 RU到当前环境中GI 和DB
3,   使用DBCA 创建新的数据库， 在OUI 图形的Deployment Type选项卡，选择任何现有include datafiles=Yes的库模板如DWOLTP.

接下来可能就出现这个问题，安装的进度条长时间在50%多，整个安装过程可能需要等待3-4个小时。在安装完成后会发现数据库存在SDO组件INVALID，
所有PDBS处于RESTRICTED限制访问模式，同时数据库中包含大量的Invalid 无效对象。
SQL*Plus: Release 19.0.0.0.0 - Production on Sun Feb 16 20:40:31 2020
Version 19.6.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.6.0.0.0
SQL> select count(*) from dba_objects where status='INVALID';

  COUNT(*)
----------
       256
后来Google发现Mike Dietrich也在他的BLOG记录了他的客户向他反应相同的问题，解决方法是应用 OJVM 19.6 patch.
MOS 2118136.2

1.3问题处理

安装并应用DB OJVM patch 30484981.
su - oracle
 -- Shutdown DB and Listener
 sqlplus / as sysdba
 shutdown immediate
 exit

 lsnrctl stop

 -- Run: opatch apply
 cd $ORACLE_HOME/OPatch
 ./opatch apply /u01/orasw/patches/30463595/30484981 -oh $ORACLE_HOME

 -- Startup DB and Listener
 sqlplus / as sysdba
 startup
 exit

 lsnrctl start

 -- Run: datapatch
 cd $ORACLE_HOME/OPatch
 ./datapatch -verbose
Check dba_registry
 COL version     FORMAT a10
 COL action      FORMAT a10
 COL status      FORMAT a10
 COL action_time FORMAT a30
 COL description FORMAT a65
 SELECT patch_id,patch_type,action,status,action_time,description FROM dba_registry_sqlpatch;
1,重新编译
$ cd $ORACLE_HOME/rdbms/admin
oracle@anbob:/u01/app/oracle/product/19JVM/rdbms/admin
$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl --n 1 --e --b utlrp --d '''.''' utlrp.sql

SQL> select count(*) from cdb_objects where status='INVALID';

  COUNT(*)
----------
     0

2, 或删库重新DBCA 该问题已消失.

删除，重建时，选择Custom Database，不会触发这个问题！！！

1.3为什么会出现这个问题？？？

为什么创建CUSTOM数据库不会发生这种情况？
创建CUSTOM数据库时，因为不包含datafiles,将运行所有用于构建词典的脚本。因此，您将获得一个全新的干净字典，而选择预构建的DW和OLTP数据库已经带来了它的SYSTEM表空间datafile，
可能存在一些不兼容的问题，这个问题是有些奇怪，相信以后会是常见现象。
经验总结
在安装19c数据库 在安装了DBRU后，记的安装对应的OJVM patch。 如果有注意DBRU中也有升级 JDK。另外在DBUA中尽可能选择Custom database根据自己的需要选择安装对应的组件，
减少不必要的升级时间。
–enjoy it


如下，使用单实例环境进行测试，安装19.6.2 PSU补丁+ OJVM19.6 DB补丁后，DBCA建库！！！ 正常的理解是没有问题（使用Custom database没问题，就是慢一点），
使用General Purpose or Transaction processing方式创建，还是报错！！！

executing command: SET NEWNAME
Starting restore at 31-OCT-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=430 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/app/oracle/oradata/ORCL3/system01.dbf
channel ORA_DISK_1: reading from backup piece /u02/app/oracle/product/11.2.0/dbhome_1/assistants/dbca/templates/Seed_Database.dfb
channel ORA_DISK_1: ORA-19870: error while restoring backup piece /u02/app/oracle/product/11.2.0/dbhome_1/assistants/dbca/templates/Seed_Database.dfb
ORA-19599: block number 12069 is corrupt in backup piece /u02/app/oracle/product/11.2.0/dbhome_1/assistants/dbca/templates/Seed_Database.dfb
failover to previous backup
creating datafile file number=1 name=/u02/app/oracle/oradata/ORCL3/system01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/31/2020 06:42:04
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '/u02/app/oracle/oradata/ORCL3/system01.dbf'
RMAN>

报错的内容很有意思 ORA-19870 ORA-19599，我有理由相信是Oracle的模板的文件自身就存在问题，因此选择非 Custom database方式，需要使用Oracle的模板文件进行restore快速还原文件进行DBCA快速搭建。   但是模板文件就有问题，因此生产环境19.6.2 DBCA之后，PDB及种子库都处于受限模式，进一步查询都是ODU组件失效！！！  

实测:19.8.2、19.6.2 DBCA打PSU后，无安装OJVM补丁，DBCA使用Custom database方式，检查PDB无异常！！！

这篇文档的作用是进行警示，建议Oracle没解决这个问题之前，建议>19.6的版本DBCA建库，选择Custom database方式。   
19.5.2建库多套，没有发现必须使用Custom database方式，19.6.2就遇到了。
遇到了也不要慌，按照OJVM补丁修复或者删库重建即可。