共计 6113 个字符，预计需要花费 16 分钟才能阅读完成。
最近迁移一台测试环境，准备整合到 12c 的 PDB，常规的思路是用 Datapump 导出导入，对于数据较大的环境来说这个时间会比较长，为此自己也尝试先升级这个测试库，然后加入到 CDB 中去。
升级的过程就不多说了，其实对于大多数常规的业务来说，本身不是难点。
把升级后的 NON-CDB 加入到 CDB 中，基本是下面的思路，先把数据启动到只读模式，然后到处一个配置文件，加载到 CDB 的重要地方就是使用这个配置文件。先做检查。
sqlplus / as sysdba
SQL> select name, CDB from v$database;
NAME CDB
--------- ---
TESTDB YES
SET SERVEROUTPUT ON
DECLARE
compatible CONSTANT VARCHAR2(3) :=
CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
pdb_descr_file => '/tmp/ncdb12c_actvdb.xml',
pdb_name => 'NCDB12C')
WHEN TRUE THEN 'YES'
ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(compatible);
END;
/
NO
PL/SQL procedure successfully completed.仔细一看这个地方竟然输出了 NO，对于这种情况需要查看下面的数据字典来得到更多的信息。
select name,cause,type,message,status from PDB_PLUG_IN_VIOLATIONS where name='NCDB12C';比如会有下面的信息：
NAME CAUSE TYPE MESSAGE STATUS
---------- ------------------------------ --------- -------------------------------------------------- ---------
NCDB12C Parameter WARNING CDB parameter optimizer_index_caching mismatch: PENDING
Previous 90 Current 0
NCDB12C Parameter WARNING CDB parameter pga_aggregate_target mismatch: PENDING
Previous 788M Current 6440M
NCDB12C SQL patch error ERROR (PSU bundle patch 160719 (Database Patch Set PENDING
Update : 12.1.0.2.160719 (23054246)): APPLY
SUCCESS): with status in the PDB.警告的信息没有大的影响，关键就在于 ERROR
但是这个地方我就比较奇怪了，使用 opatch lsinventory 查看，补丁是有的。而且其他的数据库已经都部署多套了。这个为什么就抛出了这个问题呢。
为了尽快修复这个问题，我打开生成的配置文件，把 SQL Patch 的这一段信息删除了，然后再次运行上面的检查脚本就没有问题了。
SQL> @a.sql
YES
PL/SQL procedure successfully completed.
基本的准备工作做完了，也算是有惊又险。
我们创建 PDB, 注意文件路径的映射。
SQL> CREATE PLUGGABLE DATABASE actvdb using '/tmp/ncdb12c_actvdb.xml'
copy file_name_convert=('/U01/app/Oracle/oradata/actvdb','/home/U01/app/oracle/oradata/testdb/pdb/actvdb');
Pluggable database created.这个过程时间会持续稍长一些，不过因为是在本地，所以影响不大，创建好之后，尝试 open 这个 PDB，发现不大对劲。
SQL> alter pluggable database actvdb open;
Warning: PDB altered with errors.
检查这个 PDB 的状态，发现是受限的会话连接。
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO。。。8 ACTVDB READ WRITE YES突然醒悟，还有一个重要的脚本没跑，那就是
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
一遍感叹粗心大意，一边赶紧运行脚本。
运行的过程中查看 PDB 的状态是 MIGRATE
SQL> SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO。。。8 ACTVDB MIGRATE YES但是让我有些意外的是这个脚本执行失败了，而且抛出了 ORA-00600 的错误。
SQL> DECLARE
2 threads pls_integer := &&1;
3 BEGIN
4 utl_recomp.recomp_parallel(threads);
5 END;
6 /
DECLARE
*
ERROR at line 1:
ORA-04045: errors during recompilation/revalidation of SYS.DBMS_QOPATCH
ORA-00600: internal error code, arguments: [kql_tab_diana:new dep],
[0x4C7382A68], [0x7F97536569A0], [1], [2], [], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_UTILITY", line 1294
ORA-06512: at line 1因为也不大确定这个的影响范围，查看 PDB 的状态，发现是受限的会话连接。
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO。。。8 ACTVDB READ WRITE YES 尝试反复启停，还是同样的错误，眼看升级迁移的时间越来越紧，尽管是测试环境，还是不能麻痹大意。
对于这个问题，真是让我一头雾水，查看 MOS 也没有找到直接的解答，而查看 OTN 的问答，发现有些朋友也确实碰到了。有人找到了根上，那就是编译一个包的时候会抛出 ORA-00600 的错误。
我试了下，确实如此。
SQL> ALTER PACKAGE "SYS"."DBMS_QOPATCH" COMPILE BODY REUSE SETTINGS ;
ALTER PACKAGE "SYS"."DBMS_QOPATCH" COMPILE BODY REUSE SETTINGS
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kql_tab_diana:new dep],
[0x149CF37C0], [0x7F9BEA79DBD0], [1], [2], [], [], [], [], [], [], []有些人尝试重新创建编译这个包，我在本地尝试，发现还是抛出了 ORA-00600 的错误。
SQL> @?/rdbms/admin/prvtqopi.plb
Session altered.
CREATE OR REPLACE PACKAGE BODY DBMS_QOPATCH wrapped
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kql_tab_diana:new dep],
[0x149CF37C0], [0x7F9BEAB683B8], [1], [2], [], [], [], [], [], [], []这个问题越发严峻，而我似乎只能找到一个有些相关的 bug
Bug 20981713 : ORA-600 [KQL_TAB_DIANA:NEW DEP] DURING NONCDB_TO_PDB.SQL
过了一会儿之后，我再次尝试停库，然后重新启动，发现竟然可以了。
当然我的内心是忐忑的，我深深知道很可能这个库再停了之后就无法正常 open 了。
但是应用的连接能够正常进来，也算是躲过了一劫，而马上我就发现这个问题不是一般的纠结。因为我碰到了另外一个棘手的问题，那就是主库虽然可以正常 open 了，忽略了里面的警告，但是备库的这个 PDB 却偏偏无法正常 open 到 read only 状态。
对于灾备而言，这是极为严重，而且不合格的。但是问题的原因是什么呢。
为了进一步实验，我在备库开启了 snapshot Standby，这样备库可读可写，就能够模拟测试了，但是我发现问题是接二连三。
马上发现这个 PDB 在 open 的时候报出了其它的 ORA-00600 错误。
Errors in file /home/U01/app/oracle/diag/rdbms/testdb2/testdb/trace/testdb_p005_24365.trc (incident=140313) (PDBNAME=ACTVDB):
ORA-00600: internal error code, arguments: [kqlobjlod-no-result-from-proc$], [1403], [888], [], [], [], [], [], [], [], [], []
Incident details in: /home/U01/app/oracle/diag/rdbms/testdb2/testdb/incident/incdir_140313/testdb_p005_24365_i140313.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details. 查看 MOS 找到了文章，但是还是没有解决的方法。
ORA-600 [kqlobjlod-no-result-from-proc$] (Doc ID 1613402.1)
在查看了不少的文章之后，隐隐发现是在这个 Patch 上。
因为我在 Snapshot Standby 中测试了下面的命令，发现似乎容器的 Patch 没有生效。
$ ./datapatch -verbose
....
Installing patches...
Patch installation complete. Total patches installed: 7所以在做了一个艰难的决定之后，我决定在主库重新给这个 PDB 部署 Patch, 然后运行 noncdb_to_pdb.sql
但是这样做的风险就是这个 PDB 如果还是无法正常 open，很可能的情况就是受限的会话连接，这样的话我只能重新修复了，为此我花了些时间做了一个完整的逻辑备份，然后开始尝试修复。
再次运行 noncdb_to_pdb.sql 的脚本。
SQL> alter session set container=actvdb;
Session altered.
SQL> @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql看到上次抛出 ORA-00600 的地方会快就顺利完成了，心里总算松了口气。然后尝试 open 的时候发现这次抛出了 SQLPatch 的 Error
我在主库端 $ORACLE_HOME/OPatch 下运行 dbpach -verbose 短暂的等待之后，可以看到 PDB 已经部署了新的补丁。
Current state of SQL patches:
Bundle series PSU:
ID 160719 in the binary registry and ID 160719 in PDB ACTVDB然后重启 PDB, 就恢复了正常。
SQL> alter session set container=actvdb;
Session altered.
SQL> shutdown immediate
Pluggable Database closed.
SQL> startup
Pluggable Database opened.
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
8 ACTVDB READ WRITE NO而这个问题在备库就立竿见影，再次尝试启动备库的 PDB。
使用 alter pluggable database all open 就没有问题了。
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO。。。8 ACTVDB READ ONLY NO
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY 这个问题总算告一段落，而对于 SQL Patch 也有了更深一层的理解。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-11/137172.htm
