Skip to content

All posts by Guang Cai Li - 5. page

测试将GRID_HOME下所有文件属组改变为ORACLE用户的，集群出现异常后的修复方式。
参考MOS文档：Script to capture and restore file permission in a directory (for eg. ORACLE_HOME) (文档 ID 1515018.1)
测试环境：LINUX-x64+oracle11gR2两节点RAC
1.测试，修改节点1 GRID_HOME中所有文件权限为oracle:oinstall
[root@bys1 app]# cd /u01/11.2.0/grid/
[root@bys1 grid]# chown -R oracle:oinstall ./*

2.在正常节点2上获取目录及文件的正确权限
[root@bys2 ~]# ls
anaconda-ks.cfg Documents install.log Music Pictures Templates
Desktop Downloads install.log.syslog permission.pl Public Videos
[root@bys2 ~]# chmod a+x permission.pl
[root@bys2 ~]# ./permission.pl /u01/11.2.0/grid/
Following log files are generated
logfile : permission-Wed-Dec-14-16-16-50-2016
Command file : restore-perm-Wed-Dec-14-16-16-50-2016.cmd
Linecount : 17253

3.使用生成的脚本对权限进行恢复
[root@bys1 ~]# chmod a+x restore-perm-Wed-Dec-14-16-16-50-2016.cmd
[root@bys1 ~]# ./restore-perm-Wed-Dec-14-16-16-50-2016.cmd >/tmp/chown.log
—从如下输出来看，主要是一些日志文件不存在引起的对应CHOWN语句出错；
—注意：1.olr在安装完成时的自动备份文件权限需要手动配置
—注意：2.OCR自动备份权限需要手动配置/u01/11.2.0/grid/cdata/bysrac–权限不对会导致无法覆盖
—注意：3.注意检验GRID/ORACLE 的home下bin目录中oracle程序的权限–6751e及属组

–部分重复的输出已经删除–
chown: cannot access `/u01/11.2.0/grid/cdata/bys1/backup_20161109_205004.olr’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/cdata/bys1/backup_20161109_205004.olr’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/cfgtoollogs/opatch/lsinv/lsinventory2016-11-24_15-50-32PM.txt’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/cfgtoollogs/oui/oraInstall2016-11-09_09-01-09PM.out.bys1′: No such file or directory
chown: cannot access `/u01/11.2.0/grid/log/bys1/client/clsc_7.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/log/bys1/client/gpnptool_13875.log’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/log/bys1/client/ocrcheck_18006.log’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/log/bys1/client/clsc_9.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/log/bys1/client/gpnptool_12955.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/log/bys1/client/clsc_14.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/log/bys1/client/ocrconfig_14761.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/cv/init/start.txt’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/install/root_bys1.bys.com_2016-11-09_20-46-04.log’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/crf/db/bys1/26-NOV-2016-09:36:58.txt’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/crf/db/bys1/10-NOV-2016-13:30:24.txt’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/crf/db/bys1/log.0000000018′: No such file or directory
chown: cannot access `/u01/11.2.0/grid/crf/db/bys1/26-NOV-2016-09:33:56.txt’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/crf/db/bys1/log.0000000017′: No such file or directory
chown: cannot access `/u01/11.2.0/grid/crf/db/bys1/10-NOV-2016-12:07:04.txt’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/crf/db/bys1/29-NOV-2016-18:27:55.txt’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/oc4j/j2ee/home/log/oc4j_2016_11_29_18_05_27.err’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/oc4j/j2ee/home/log/oc4j_2016_11_27_21_25_38.out’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/oc4j/j2ee/home/persistence/MBeanServerEjb.ser’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/.patch_storage/NApply/2016-11-10_12-54-39PM’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/rdbms/log/+asm2_ora_2644.trc’: No such file or directory
大量此类文件
chmod: cannot access `/u01/11.2.0/grid/rdbms/log/+asm2_ora_2478.trc’: No such file or directory
chmod: cannot access `/u01/11.2.0/grid/rdbms/audit/+ASM2_ora_10622_20161109214606892302143795.aud’: No such file or directory
大量此类文件
chmod: cannot access `/u01/11.2.0/grid/rdbms/audit/+ASM2_ora_15864_20161109210021310719143795.aud’: No such file or directory
chown: cannot access `/u01/11.2.0/grid/dbs/ab_+ASM2.dat’: No such file or directory

[root@bys1 ~]#

4.重启主机或者集群，检查集群状态，集群可以恢复正常；
[root@bys1 ~]# crsctl stat res -t
——————————————————————————–
NAME TARGET STATE SERVER STATE_DETAILS
——————————————————————————–
Local Resources
——————————————————————————–
ora.DATA.dg
ONLINE ONLINE bys1
ONLINE ONLINE bys2
ora.LISTENER.lsnr
ONLINE ONLINE bys1
ONLINE ONLINE bys2
ora.asm
ONLINE ONLINE bys1 Started
ONLINE ONLINE bys2 Started
ora.gsd
OFFLINE OFFLINE bys1
OFFLINE OFFLINE bys2
ora.net1.network
ONLINE ONLINE bys1
ONLINE ONLINE bys2
ora.ons
ONLINE ONLINE bys1
ONLINE ONLINE bys2
——————————————————————————–
Cluster Resources
——————————————————————————–
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE bys2
ora.bys1.vip
1 ONLINE ONLINE bys1
ora.bys2.vip
1 ONLINE ONLINE bys2
ora.bysrac.db
1 ONLINE ONLINE bys1 Open
2 ONLINE ONLINE bys2 Open
ora.cvu
1 ONLINE ONLINE bys2
ora.oc4j
1 OFFLINE OFFLINE
ora.scan1.vip
1 ONLINE ONLINE bys2

测试将RAC GRID_HOME下所有文件属组修改后的修复方式permission.pl

RAC版本为：12.1.0.2.161018，使用ASM；恢复测试时，恢复到单实例非ASM环境时;
在执行restore database命令时，alert日志中一直报错：WARNING: failed to start ASMB (connection failed) state=0x1 sid=”，RMAN中restore database执行到分配通道后，也无法继续；
此时查询v$session_longops视图也查不到会话信息；

命令类似如下：
run
set newname for datafile 56 to ‘/oradata/**db/data/indx03.dbf’;
restore database;
switch datafile all;
}
输出到如下时停止：
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=188 device type=DISK

alert日志中的信息如下：

————–
根据ALERT中信息，查下mos，匹配如下bug:
WARNING: failed to start ASMB after RAC Database on ASM converted to Single Instance Non-ASM Database (文档 ID 2138520.1)
12c RMAN Operations from ASM To Non-ASM Slow (文档 ID 2081537.1)
BUG 19503821: RMAN CATALOG EXTREMELY SLOW WHEN MIGRATING DATABASE FROM ASM TO FILE SYSTEM
———
解决：
参照MOS建议，打了补丁19503821之后，restore database可以正常恢复完成。
–最终alert日志中还有其它一些warning，未影响此次恢复，不折腾了；感觉12cR1还是有不少bug，慎用吧~
——2016/12/30遇到的问题，记录于2016/12/31 22:50分，银行结算保障加班中~~

RAC12.1.0.2.161018PSU从RAC+ASM恢复到单实例非ASM遇到的BUG

被同事指出备份脚本中缺少手动切换日志的命令，事实上在10G及以上版本已经不需要此在脚本中加上此语句。主要通过查阅官方文档及实验，验证10G/11G/12cr1版本中backup archivelog命令是否会触发归档current logfile操作。

结果如下；
如果数据库在OPEN状态，运行BACKUP ARCHIVELOG命令时，如果不使用UNTIL/SEQUENCE关键字，会自动执行日志切换命令。

参考官方文档中描述：http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta007.htm#CHDCFGEI
http://docs.oracle.com/database/121/RCMRF/rcmsynta006.htm

If the database is open when you run BACKUP ARCHIVELOG, and if the UNTIL clause or SEQUENCE parameter is not specified, then RMAN runs ALTER SYSTEM ARCHIVE LOG CURRENT. —这一句，如果数据库在OPEN状态，运行BACKUP ARCHIVELOG命令时，如果不使用UNTIL/SEQUENCE关键字，会执行日志切换命令。

Note: If you run BACKUP ARCHIVELOG ALL, or if the specified log range includes logs from prior incarnations, then RMAN backs up logs from prior incarnations to ensure availability of all logs that may be required for recovery through an OPEN RESETLOGS.
———————————-

以下以11.2.0.4版本验证：
开始备份操作：
[oracle@bys1 ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 – Production on Sat Jan 21 18:04:53 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

connected to target database: BYS1 (DBID=4052277609)

RMAN> backup archivelog from time ‘sysdate-1’ format ‘/home/orcale/arch_%d_%t_%s.bak’;

Starting backup at 2017/01/21 18:04:55 ————>备份命令开始时间，与ALERT日志中可以对应。
current log archived ————>这句输出可以发现是做了current redolog的归档；
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=58 device type=DISK

观察ALERT日志：
Sat Jan 21 18:02:20 2017
ALTER SYSTEM ARCHIVE LOG
Sat Jan 21 18:02:20 2017
Thread 1 advanced to log sequence 99 (LGWR switch)
Current log# 3 seq# 99 mem# 0: /u01/app/oradata/bys1/redo03.log
Sat Jan 21 18:02:20 2017
Archived Log entry 131 added for thread 1 sequence 98 ID 0xf1898b69 dest 1:
Sat Jan 21 18:04:55 2017 ————>ALTER SYSTEM ARCHIVE LOG命令执行时间，与备份时输出可以对应。
ALTER SYSTEM ARCHIVE LOG
Sat Jan 21 18:04:55 2017
Thread 1 advanced to log sequence 100 (LGWR switch)
Current log# 1 seq# 100 mem# 0: /u01/app/oradata/bys1/redo01.log
Sat Jan 21 18:04:56 2017
Archived Log entry 132 added for thread 1 sequence 99 ID 0xf1898b69 dest 1:

———————11GR2 RAC环境的验证–在任意节点上执行两个节点都进行切换

RAC节点1执行备份backup archivelog操作
[oracle@bys1 ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 – Production on Tue Feb 7 12:06:02 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

connected to target database: BYSRAC (DBID=2682487210)

RMAN> backup archivelog from time ‘sysdate-1/12’ format ‘/home/oracle/arch_%d_%t_%s.bak’;

Starting backup at 20170207 12:06:29
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 instance=bysrac1 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=49 RECID=79 STAMP=935323590
input archived log thread=2 sequence=34 RECID=80 STAMP=935323591
channel ORA_DISK_1: starting piece 1 at 20170207 12:06:39
channel ORA_DISK_1: finished piece 1 at 20170207 12:06:40
piece handle=/home/oracle/arch_BYSRAC_935323599_3.bak tag=TAG20170207T120639 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 20170207 12:06:40

RMAN> backup archivelog from time ‘sysdate-1/12’ format ‘/home/oracle/arch_%d_%t_%s.bak’;

Starting backup at 20170207 12:08:32
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=49 RECID=79 STAMP=935323590
input archived log thread=2 sequence=34 RECID=80 STAMP=935323591
input archived log thread=1 sequence=50 RECID=81 STAMP=935323713
input archived log thread=2 sequence=35 RECID=82 STAMP=935323713
channel ORA_DISK_1: starting piece 1 at 20170207 12:08:36
channel ORA_DISK_1: finished piece 1 at 20170207 12:08:37
piece handle=/home/oracle/arch_BYSRAC_935323716_4.bak tag=TAG20170207T120835 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 20170207 12:08:37

观察两个节点的ALERT日志：
节点1
Tue Feb 07 12:06:29 2017
ALTER SYSTEM ARCHIVE LOG
Tue Feb 07 12:06:30 2017
Thread 1 advanced to log sequence 50 (LGWR switch)
Current log# 2 seq# 50 mem# 0: +DATA/bysrac/onlinelog/group_2.258.927541487
Current log# 2 seq# 50 mem# 1: +DATA/bysrac/onlinelog/group_2.257.927541487
Tue Feb 07 12:06:30 2017
Archived Log entry 79 added for thread 1 sequence 49 ID 0x9fe402a6 dest 1:
Tue Feb 07 12:08:32 2017
ALTER SYSTEM ARCHIVE LOG
Tue Feb 07 12:08:33 2017
Thread 1 advanced to log sequence 51 (LGWR switch)
Current log# 1 seq# 51 mem# 0: +DATA/bysrac/onlinelog/group_1.267.927541485
Current log# 1 seq# 51 mem# 1: +DATA/bysrac/onlinelog/group_1.259.927541485
Tue Feb 07 12:08:33 2017
Archived Log entry 81 added for thread 1 sequence 50 ID 0x9fe402a6 dest 1:

节点2
Tue Feb 07 12:06:30 2017
Thread 2 advanced to log sequence 35 (LGWR switch)
Current log# 3 seq# 35 mem# 0: +DATA/bysrac/onlinelog/group_3.261.927541697
Current log# 3 seq# 35 mem# 1: +DATA/bysrac/onlinelog/group_3.269.927541699
Tue Feb 07 12:06:31 2017
Archived Log entry 80 added for thread 2 sequence 34 ID 0x9fe402a6 dest 1:
Tue Feb 07 12:08:33 2017
Thread 2 advanced to log sequence 36 (LGWR switch)
Current log# 4 seq# 36 mem# 0: +DATA/bysrac/onlinelog/group_4.270.927541701
Current log# 4 seq# 36 mem# 1: +DATA/bysrac/onlinelog/group_4.271.927541701
Tue Feb 07 12:08:33 2017
Archived Log entry 82 added for thread 2 sequence 35 ID 0x9fe402a6 dest 1:

查看备份集信息
RMAN> list backup of archivelog all;

List of Backup Sets
===================

BS Key Size Device Type Elapsed Time Completion Time
——- ———- ———– ———— —————–
3 3.00K DISK 00:00:00 20170207 12:06:39
BP Key: 3 Status: AVAILABLE Compressed: NO Tag: TAG20170207T120639
Piece Name: /home/oracle/arch_BYSRAC_935323599_3.bak

List of Archived Logs in backup set 3
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- —————– ———- ———
1 49 2344159 20170207 12:04:32 2344293 20170207 12:06:30
2 34 2344163 20170207 12:04:33 2344297 20170207 12:06:30

BS Key Size Device Type Elapsed Time Completion Time
——- ———- ———– ———— —————–
4 4.50K DISK 00:00:00 20170207 12:08:36
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20170207T120835
Piece Name: /home/oracle/arch_BYSRAC_935323716_4.bak

List of Archived Logs in backup set 4
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- —————– ———- ———
1 49 2344159 20170207 12:04:32 2344293 20170207 12:06:30
1 50 2344293 20170207 12:06:30 2344410 20170207 12:08:33
2 34 2344163 20170207 12:04:33 2344297 20170207 12:06:30
2 35 2344297 20170207 12:06:30 2344414 20170207 12:08:33

10G/11G/12cr1版本中backup archivelog命令是否会触发归档current logfile操作

AIX6.1安装RAC12.1.0.2遇到在GRID安装图形界面选择OCR磁盘处无法识别共享磁盘问题;

排查权限属组PVID/no_reserve设置需要检查等均正常；使用silent 模式安装时，报错 [INS-30508] Invalid ASM disks.，根据此报错查MOS，最终定位到是IOCP未开启。—是11G RAC环境升级安装12C，如果按照12C官方安装文档来检查设置一遍就没这问题了~~~
12C安装无法识别共享磁盘的排查过程(后面总结的)：
—>>>PVID/no_reserve设置需要检查、
—>>>权限与属组
—>>>IOCP是否开启
—>>>grid软件的文件系统（/u01）为jfs类型。创建/u01文件系统时，没有选择jfs2文件系统，导致安装在该文件系统上的grid软件无法识别磁盘。重新创建该文件系统为jfs2类型，重新安装grid软件，问题解决。
参考MOS文档:

INS-30508 Invalid ASM Disks on Grid Infrastructure Installation (文档 ID 1999903.1)

[INS-30508] Invalid ASM disks (文档 ID 1941922.1)

Oracle Universal Installer (OUI) in silent mode fails with INS-30508 (文档 ID 987393.1)

11gR2 Grid Infrastructure Installer Sees no ASM disks When 10.2 Clusterware Environment Exists (文档 ID 1277148.1)

aix6.1安装12.1.0.2rac无法识别共享磁盘的问题

物理DG主、备库从11.2.0.4升级到12.1.0.2方式：在升级过程中，需要DG备库停止应用日志，主库停止对外服务，即停止业务，所需停机时间即主库升级的时间;

–另一种停机短的方式：如果对停机时间要求很短则可考虑主库对应一物理备库一逻辑备库，通过逻辑备库方式进行升级，进行逻辑备库与主库的主备切换来实现升级，最后再同步到物理备库来实现整个DG架构的升级，测试充分的话这种停机时间应该10分钟左右就够。对硬件及逻辑、物理备库互转等测试会要求较多;其它的第三方同步软件方式就不说了。

当前方式优点是主库升级时DG备库不升级，状态不变，如升级失败，业务回退比较方便，适合于数据库量大、对回退时间要求严格的场景；当然如果一主多备库环境，可以直接升主库同时应用日志到一个备库，另一个备库不升级做回退用—所需停机时间即主库升级的时间。。
—-主要步骤
1.物理DG主、备库状态检查，取消备库的日志恢复应用，但是保留接收REDO日志
2.主库进行升级
—–>升级前检查及处理–主库：SQL> @dbupgdiag.sql –MOS文档：556610.1有提供，SQL> @preupgrd.sql，并根据输出进行相应的修改
—–>将连接DG备库的tnsnames.ora文件复制到新的12C RDBMS_HOME相应目录
—–>DBUA升级–图形界面，中间遇到问题进行相应处理； 注意如果是RAC，此时已经安装了12C的GI并正常运行，需要通过11G的RDBMS_HOME下srvctl工具将11G的数据库资源注册到集群并启动两节点数据库到OPEN–数据库资源的ORACLE_HOME需要是11G的RDBMS_HOME–不然DBUA界面无法正确选择待升级的RDBMS_HOME及DB版本。
—–>DBUA升级完成后的配置修改compatible=’12.1.0.2.0′–主库

3.备库开启日志恢复应用，通过应用日志完成升级
—–>首先备库的spfile修改compatible=’12.1.0.2.0’（主库升级期间备库MOUNT但是不RECOVER，后面可能遇到600错误，不影响）
—–>将备库的spfile、密码文件、连接到主库的tnsnames.ora文件复制到12C软件的$ORACLE_HOME的相应目录
—–>使用12C的软件，启动备库到MOUNT，日志中有设置compatible相关信息
—–>在12C软件下启用DG备库的日志恢复应用—注意监控alert日志
—–>恢复完成后，启动备库至OPEN READ ONLY状态，并开启日志应用
4.检查主、备库同步情况及版本信息
—–>检查DG主备库同步情况–通过观察主、备库的ALERT日志来监控
—–>主库版本信息检查：—备库同样命令检查，不重复贴了。
—–>注意主、备库使用12C的监听器
—–>如果主机上有多个数据库实例，升级后存在多个版本数据库，如果监听使用11G，升级后的12C数据库可能无法动态注册到11G监听，建议使用12C监听器，低版本数据库均可以注册到12C监听。

############################单实例升级–详细的过程介绍及部分命令示例：
1.物理DG主、备库状态检查，取消备库的日志恢复应用，但是保留接收日志
备库：SQL> alter database recover managed standby database cancel;

2.主库进行升级
—–>升级前检查及处理
主库：
SQL> @dbupgdiag.sql –MOS文档：556610.1有提供
[oracle@bys1 ~]$ cd /u01/app/oracle/product/12.1/dbhome_1
[oracle@bys1 admin]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Sat Mar 18 20:57:22 2017
SQL> startup
SQL> @preupgrd.sql
根据输出进行相应的修改
—–>DBUA升级–图形界面，中间遇到问题进行相应处理
—–>升级后的配置修改–主库
SQL> show parameter com
NAME TYPE VALUE
———————————— ———– ——————————
compatible string 11.2.0.4.0
SQL> alter system set compatible=’12.1.0.2.0′ scope=spfile;

3.备库开启日志恢复应用，通过应用日志完成升级
—–>首先备库的spfile修改compatible=’12.1.0.2.0′
—–>将备库的spfile、密码文件复制到12C软件的$ORACLE_HOME/dbs目录
—–>使用12C的软件，启动备库到MOUNT
—–>启用DG备库的日志恢复应用—注意监控alert日志
[oracle@bys1 dbs]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Sun Mar 19 19:44:24 2017

Copyright (c) 1982, 2014, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 536870912 bytes
Fixed Size 2926472 bytes
Variable Size 213911672 bytes
Database Buffers 314572800 bytes
Redo Buffers 5459968 bytes
Database mounted.
SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

—–>恢复完成后，启动备库至OPEN READ ONLY状态，并开启日志应用

4.检查主、备库同步情况及版本信息
—–>检查DG主备库同步情况–通过观察主、备库的ALERT日志来监控
—–>主库版本信息检查：—备库同样命令检查，不重复贴了。
SQL> select comp_name,version,status from dba_registry;

COMP_NAME VERSION STATUS
———————————– ————— ——-
Oracle Application Express 4.2.5.00.08 VALID
OWB 11.2.0.4.0 VALID
OLAP Catalog 11.2.0.4.0 OPTION
OFF
Spatial 12.1.0.2.0 VALID
Oracle Multimedia 12.1.0.2.0 VALID
Oracle XML Database 12.1.0.2.0 VALID
Oracle Text 12.1.0.2.0 VALID
Oracle Workspace Manager 12.1.0.2.0 VALID
Oracle Database Catalog Views 12.1.0.2.0 VALID
Oracle Database Packages and Types 12.1.0.2.0 VALID
JServer JAVA Virtual Machine 12.1.0.2.0 VALID
Oracle XDK 12.1.0.2.0 VALID
Oracle Database Java Packages 12.1.0.2.0 VALID
OLAP Analytic Workspace 12.1.0.2.0 VALID
Oracle OLAP API 12.1.0.2.0 VALID

15 rows selected.

SQL> select action_time,action,id,version,comments from dba_registry_history;

ACTION_TIME ACTION ID VERSION COMMENTS
—————————— ————— ———- ————— ——————————
24-AUG-13 12.03.45.119862 PM APPLY 0 11.2.0.4 Patchset 11.2.0.2.0
13-JUL-16 12.27.19.064373 AM APPLY 0 11.2.0.4 Patchset 11.2.0.2.0
18-MAR-17 10.31.36.080528 PM VIEW INVALIDATE 8289601 view invalidation

11204单实例DG升级到12102版本-有停机-包含升级12cRAC注意事项