Oracle 12c PDB迁移及ORA-00600错误分析和解决

最近迁移一台测试环境,准备整合到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也有了更深一层的理解。

时间: 2024-10-25 03:10:32

Oracle 12c PDB迁移及ORA-00600错误分析和解决的相关文章

Oracle 12c PDB迁移(一)

    最近在整理测试环境的服务器资源,发现真是混乱,问题比较多.首先是服务器配置较低(很多都是KVM或者openstack虚机),资源使用率不高,有些数据的版本较低(10gR2),没有开启归档,没有备库(有些都是异机备份的形式).而且数据库比较散乱,整合起来难度较大,最大的难点就是数据库用户重复,大量重名的同义词等.之前尝试整合了一番,遇到了瓶颈,就暂停了整合的过程,现在来看12c还是一个不错的选择.当然我的选择似乎还是晚了些,下午在看很多人的博客的时候,发现不少人三四年前就在玩12c的很多特

ORACLE 12C PDB 维护基础知识介绍_oracle

先说基本用法: 先按11G之前进行 conn / as sysdba; create user test identifed by test; ORA-65096: 公用用户名或角色名无效. 查官方文档得知"试图创建一个通用用户,必需要用C##或者c##开头",这时候心里会有疑问,什么是common user?不管先建成功了再说 create C##user test identifed by test; 创建成功 SQL>show con_name; CON_NAME ----

Oracle 12c PDB浅析(二)

之前写了第一篇Oracle 12c PDB浅析 http://blog.itpub.net/23718752/viewspace-1823792/?          在上次的基础上继续来学习学习.     首先关于多租户的架构设计来说,就好比在一座已经几十年的老房子上动地基一般,这个变化着实够大,如此重大的变化Oracle不遗余力的想引入进来,肯定有更深层次的原因,当然关于这种设计在SQLServer中确实已经早有实现,在Oracle中却被大家相传为一种略带神奇的架构设计.不过话说回来,这个和

Oracle 12c PDB中碰到的DG问题

Oracle 12c中的PDB一下子让数据文件的格式复杂了一些,所以Data Guard就很有必要了,一旦出现问题,受损失的数据库是全局的.没想到在搭建Data Guard的时候还是碰到了一些小问题. 问题源自于一次PDB创建的时候,早些时候我在搭建好Data Guard后,主备库的日志应用都没有问题,过了几天,根据需求需要再添加一个PDB,导入一些数据供应用使用.按照要求创建了数据文件然后导入数据,但是查看备库的状态发现MRP异常停止了. DG Broker检测的状态如下: DGMGRL> s

Oracle 12c PDB浅析

不管怎么样,12c出来这么久,总是因为各种各样的原因没有开始学习,现在似乎还是有些晚了.总是耳闻PDB在12c是一种全新的架构模式,在各种技术聊天也大概知道是一种可插拨的新型架构模式,但是似乎SQLServer中也有类似的架构,不管怎么样Oracle圈内还是很火,而且听说12c r2可以支持4096个pdb,这个也太大了,docker装一下试试:) 自己也在本地尝试了一下,其实中间了花了些时间,中途总是被各种事情打断,所以留下的都是一些零碎的知识片段,自己索引把环境重新删了再做几次. 在这种尝试

Oracle 12c PDB的数据备份恢复

今天测试了一下12c中的PDB还原恢复,里面还是有不少的差别. 我就简单模拟了一个破坏场景,是在一个未打开的PDB tcymob0从中删除了数据文件usres01.dbf,然后尝试备份恢复. 当然在这个操作前,我们使用RMAN来备份,使用命令backup database即可备份整个数据库. 手工破坏的语句如下: $ rm /U01/app/oracle/oradata/test12cs/tcymob0/pdbseed/users01.dbf这个时候的还原工作就很清晰了,直接还原对应的表空间或者

oracle 12c数据泵导入报错KUP-11014错误解决办法

将10.2.0.5的一个大表导入到12.1.0.2的时候, 导出参数是: [oracle10g@testdb tmp]$ cat expdp.par userid='/ as sysdba' DIRECTORY=DUMPDIR dumpfile=mytable_%U.dmp tables=schema.mytable logfile=mytable.log job_name=mytable parallel=8 filesize=100M 导入参数是: userid='/ as sysdba'

ORACLE 12C创建用户之ORA-65096

ORACLE 12C创建用户之ORA-65096   2016年2月25日,一北京北方人瑞教育咨询公司的同事遇到以.sql文件导入数据时遇到ORA-65096报错,如下图所示:      出现上图导入报错,原因初步定为创建数据库用户AJAO的方法不正确,经过查询发现DBA_USERS视图中已有C###AJAO用户,AJAO用户并不存在,所以在.sql导入时报ORA65096:错误原因是用户想在PDBORCL中创建AJAO用户,却未设置会话container到PDB,而在CDB中创建公有用户因无法

Oracle 12c远程克隆PDB的问题及修复(r12笔记第78天)

 Oracle 12c里面的PDB迁移还是有很多花样的,玩法很多,如果想达到一种平滑方式的迁移,克隆远程PDB也是一种方法,保证网络畅通,即可远程克隆PDB到指定的目标容器数据库中,当然这种方式还是推荐数据量不大的PDB.   要实现远程克隆,主要就是创建DB link,然后使用create pluggable database语句指定db link复制的路径即可.当然这个过程中还是可能出现一大堆的问题.我就抛砖引玉,提一个比较有代表性的. 首先在目标端容器数据库创建DB link,指向源端的P