首页 > 代码库 > Upgrade Oracle GI from 11.2 to 12C

Upgrade Oracle GI from 11.2 to 12C

2024-09-02 08:25:15   224人阅读

12.1.0.2已经发布一段时间了，随着用户的增多，目前12C的版本稳定性，以及各个方面的功能性，得到大家的认可。

很多用户，需要将数据库从低版本升级到12C，本文就升级过程，做了详细的记录。（突然想起“多图杀猫”这个词）

 

 

升级前，首选需要查看文档，了解哪些版本可以升级到12C

CompleteChecklist for Upgrading to Oracle Database 12c Release 1 using DBUA (Doc ID1516557.1)                            技术分享

 

另外，12C在很多硬件&系统层面的需求有变更，需要提前准备和调整。

我在升级的过程中就遇到一些问题，不得不终止升级，调整完成后，才重新升级。

Howto Upgrade to Oracle Database 12c Release1 (12.1.0) and Known Issues (Doc ID2085705.1)

Howto Upgrade to/Downgrade from Grid Infrastructure 12c and Known Issues (Doc ID1579762.1)

技术分享

 

技术分享

 

在上面需求之外，补充注意几点：

1.OCR diskgroup，至少需要5G空间，由于12C 有managmentdatabase，需要存放到OCRdiskgroup

2.需要明确在ASMinstance中设定参数asm_diskstring=‘/dev/raw/*‘, 如果不设置的话，在升级过程中，重启cssd进程会失败，无法找到voting disk

原因：如果不设置这个参数，11.2版本，默认是到/dev/raw/*查找voting disk，但是12C默认是到/dev/sd*去查找voting disk。势必会遇到读取权限问题，进而启动cssd失败。（如果使用ASMlib，也是相同的道理，在升级前，就明确设置这个参数，不让oracle使用默认的方式去查找磁盘）

3.需要保证两个节点的全部资源都正常运行，才可以升级

 

上面的准备条件完成后，开始实际的升级步骤。

 

1.创建需求目录

 

~~~~~~~~~~oracle目录~~~~~~~~~~~~~~~~

#mkdir -p /u01/app/oracle/product/12.1.0/dbhome_1

#chown -R oracle:oinstall /u01/app/oracle/product/12.1.0

#chmod -R 755 /u01/app/oracle/product/12.1.0

 

~~~~~~~~~~grid目录~~~~~~~~~~~~~~~~

#mkdir -p /u01/app/12.1.0/grid

#chown -R grid:oinstall /u01/app/12.1.0/grid

#chmod -R 755 /u01/app/12.1.0/grid

 

修改环境变量

~~~~~~~~~~~~~~oracle用户~~~~~~~~~~~~~~两个节点ORACLE_SID设置不同

$vi ~/.bash_profile

exportPATH

exportORACLE_SID=orcl

exportORACLE_BASE=/u01/app/oracle

exportORACLE_HOME=$ORACLE_BASE/product/12.1.0/dbhome_1

exportLD_LIBRARY_PATH=$ORACLE_HOME/lib

exportPATH=$ORACLE_HOME/bin:$PATH

umask022

==========原有设定===========

exportORACLE_SID=orcl1

exportORACLE_BASE=/u01/app/oracle

exportORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1

exportPATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:${PATH}

exportLD_LIBRARY_PATH=$ORACLE_HOME/lib

 

~~~~~~~~~~grid用户~~~~~~~~~~~~~~~~两个节点ORACLE_SID设置不同

exportORACLE_SID=+ASM1

exportORACLE_BASE=/u01/app/grid

exportORACLE_HOME=/u01/app/12.1.0/grid

exportPATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:${PATH}

exportLD_LIBRARY_PATH=$ORACLE_HOME/lib

==========原有设定===========

exportORACLE_SID=+ASM1

exportORACLE_BASE=/u01/app/grid

exportORACLE_HOME=/u01/app/11.2.0/grid

exportPATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:${PATH}

exportLD_LIBRARY_PATH=$ORACLE_HOME/lib

 

2.开始执行升级过程，其实与新安装的步骤基本是相同的

su - grid

cd /tmp/patch/

unzip linuxamd64_12c_grid_1of2.zip

unzip linuxamd64_12c_grid_2of2.zip

cd /tmp/patch/grid

./runInstaller

 

3. 选择Upgrade Oracle Grid

技术分享

 

技术分享

 

技术分享

 

这里开始遇到问题，由于之前的OCR空间只有3G，这里提示，至少需要4424MB

技术分享

检查一下磁盘组空间，我由于是测试环境，磁盘设置较小，并且使用external redundancy，如果是生产环境，建议使用normal redundancy，并且根据实际情况分配磁盘组

技术分享

 

 

OCR磁盘空间不够，扩展OCR磁盘组，扩展步骤如下（物理磁盘添加，裸设备分配，这里不做详细解释）：

a. 查询当前的ASM 磁盘分配情况

SQL> set line400

SQL> col pathfor a20

SQL> selectname,PATH,GROUP_NUMBER from v$asm_disk;

NAME PATHGROUP_NUMBER

-------------------------------------------------- ------------

/dev/raw/raw4 0<<<<<<<<<<<<<<<<<<<新增加的6G空盘

OCR_0000/dev/raw/raw1 3

FRA_0000/dev/raw/raw3 2

DATA_0000/dev/raw/raw2 1

 

b. 查询磁盘组当前空间

SQL> selectGROUP_NUMBER,NAME,TOTAL_MB from v$asm_diskgroup;

 

GROUP_NUMBER NAMETOTAL_MB

------------------------------------------ ----------

1 DATA 8192

2 FRA 8192

3 OCR 3072

 

增加磁盘到磁盘组OCR

SQL> ALTERDISKGROUP ocr ADD DISK ‘/dev/raw/raw4‘ NAME ocr001;

 

Diskgroup altered.

 

d. 再次查询磁盘组空间

SQL> selectGROUP_NUMBER,NAME,TOTAL_MB from v$asm_diskgroup;

 

GROUP_NUMBER NAMETOTAL_MB

------------------------------------------ ----------

1 DATA 8192

2 FRA 8192

3 OCR 9216<<<<<<<<<<<<<<<<<<<扩展完成

 

查询磁盘，现在可以看到，磁盘已经有属主

SQL> selectname,PATH,GROUP_NUMBER from v$asm_disk;

 

NAME PATHGROUP_NUMBER

-------------------------------------------------- ------------

OCR_0000/dev/raw/raw1 3

OCR001/dev/raw/raw4 3<<<<<<<<<<<<<<<<<<<新扩展的OCR磁盘

FRA_0000 /dev/raw/raw32

DATA_0000/dev/raw/raw2 1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

需要保证两个节点的全部资源都正常运行，才可以升级

由于节点2的DB instace没有启动，手动启动，然后点击OK重试解决

技术分享

 

测试环境，没有使用EM，没有选择。

根据实际请求确定是不是要使用EM

技术分享

 

检查一下用户实际的组是不是对，没有问题的话，下一步

技术分享

 

手动修改成，之前创建的路径

技术分享

 

技术分享

 

技术分享

这里有一些告警，建议将内一个告警的解决掉。

提ASM磁盘组的问题，注意下面的描述，12C开始如果不设置ASM_diskstring,默认就会查找/dev/sd*。

个人比较懒，也就注定后面遇到了问题。

技术分享

 

技术分享

 

技术分享

 

技术分享

 

在node1执行脚本，失败！！！

技术分享

 

查询错误，搜索到下面文档，提及ASM参数设置的问题

FAILS TO STARTORA.CSSD WHEN UPGRADING GRID 12C ON NODE 1 (Doc ID 1917543.1)

 

检查OCSSD log，可以看到voting disk是无法识别的，而之前11.2是正常运行的，为什么？

就是由于12C默认扫描磁盘的方式变为/dev/sd*导致的

~~~~~~~~~~~~~upgrade.sh执行失败~~~~~~~~~~~~~~~~~~~~

 

2017-01-1814:12:14.881694 : CSSD:1102797120: clssscthrdmain: Starting thread GMPResponse

2017-01-1814:12:14.883050 : CSSD:486086176: clssscUpdateInitState: Set state to0x000c1e46, based on prior state of 0x000c1e06 and requested change of0x00000040

2017-01-1814:12:14.883097 : CSSD:486086176: clssnmReadDiscoveryProfile: voting filediscovery string()

2017-01-1814:12:14.883101 : CSSD:486086176: clssnkInit: NK generic layer initializing.

2017-01-1814:12:14.884219 : CSSD:1100556608: clssscthrdmain: Starting threadclssnmvDDiscThread

2017-01-1814:12:14.884454 : GPNP:1100556608: clsgpnp_Init: [at clsgpnp0.c:654]‘/u01/app/12.1.0/grid‘ in effect as GPnP home base.

2017-01-1814:12:14.884461 : GPNP:1100556608: clsgpnp_Init: [at clsgpnp0.c:708] GPnPpid=29401, cli=clsuGpnpg GPNP comp tracelevel=1, depcomp tracelevel=0,tlsrc:ORA_DAEMON_LOGGING_LEVELS, apitl:0, complog:1, tstenv:0, devenv:0,envopt:0, flags=2003

2017-01-1814:12:14.887900 : GPNP:1100556608: clsgpnpkwf_initwfloc: [at clsgpnpkwf.c:402]Using FS Wallet Location : /u01/app/12.1.0/grid/gpnp/node1/wallets/peer/

 

2017-01-1814:12:14.887926 : GPNP:1100556608: clsgpnpkwf_initwfloc: [at clsgpnpkwf.c:414]Wallet readable. Path: /u01/app/12.1.0/grid/gpnp/node1/wallets/peer/

 

2017-01-1814:12:14.913073 : GPNP:1100556608: clsgpnp_profileGetXmlAttrValVA: [at clsgpnp.c:3351](:GPNP00135:)Didn‘t find attribute Mode in profile

2017-01-1814:12:14.913101 : GPNP:1100556608: clsgpnp_Term: [at clsgpnp0.c:1347] GPnPcli=clsuGpnpg

2017-01-1814:12:14.914477 : CLSF:1100556608: Allocated CLSF context

2017-01-1814:12:14.914484 : CSSD:1100556608: clssnmvDDiscThread: using discovery stringfor initial discovery

2017-01-1814:12:14.914492 : SKGFD:1100556608: Discovery with str::

 

2017-01-1814:12:14.914537 : SKGFD:1100556608: UFS discovery with ::

 

2017-01-1814:12:14.914545 : SKGFD:1100556608: Execute glob on the string /dev/sd*

2017-01-1814:12:14.914639 : SKGFD:1100556608: running stat on disk:/dev/sde

2017-01-1814:12:14.914656 : SKGFD:1100556608: running stat on disk:/dev/sdd

2017-01-1814:12:14.914663 : SKGFD:1100556608: running stat on disk:/dev/sdc

2017-01-1814:12:14.914669 : SKGFD:1100556608: running stat on disk:/dev/sdb

2017-01-1814:12:14.914675 : SKGFD:1100556608: running stat on disk:/dev/sda1

2017-01-1814:12:14.914681 : SKGFD:1100556608: running stat on disk:/dev/sda2

2017-01-1814:12:14.914687 : SKGFD:1100556608: running stat on disk:/dev/sda

2017-01-1814:12:14.914696 : SKGFD:1100556608: Fetching UFS disk :/dev/sda:

 

2017-01-1814:12:14.914697 : CLSF:1100556608: Ignoring 0-byte file /dev/sda

 

2017-01-18 14:12:14.914700: SKGFD:1100556608: Fetching UFS disk :/dev/sda2:

 

2017-01-1814:12:14.914703 : CLSF:1100556608: Ignoring 0-byte file /dev/sda2

 

2017-01-1814:12:14.914705 : SKGFD:1100556608: Fetching UFS disk :/dev/sda1:

 

2017-01-1814:12:14.914706 : CLSF:1100556608: Ignoring 0-byte file /dev/sda1

 

2017-01-1814:12:14.914708 : SKGFD:1100556608: Fetching UFS disk :/dev/sdb:

 

2017-01-1814:12:14.914709 : CLSF:1100556608: Ignoring 0-byte file /dev/sdb

 

2017-01-1814:12:14.914710 : SKGFD:1100556608: Fetching UFS disk :/dev/sdc:

 

2017-01-1814:12:14.914712 : CLSF:1100556608: Ignoring 0-byte file /dev/sdc

 

2017-01-1814:12:14.914713 : SKGFD:1100556608: Fetching UFS disk :/dev/sdd:

 

2017-01-1814:12:14.914714 : CLSF:1100556608: Ignoring 0-byte file /dev/sdd

 

2017-01-1814:12:14.914716 : SKGFD:1100556608: Fetching UFS disk :/dev/sde:

 

2017-01-1814:12:14.914717 : CLSF:1100556608: Ignoring 0-byte file /dev/sde

 

2017-01-1814:12:14.914718 : SKGFD:1100556608: OSS discovery with ::

 

2017-01-1814:12:14.915332 : CSSD:1100556608: clssnmvDiskVerify: Successful discovery of 0disks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

根据文档，是建议downgrade到11.2之后，修改asm_diskstring=‘/dev/raw/*‘，然后再次升级。无非就是磁盘没有权限读取，我直接修改/dev/sd* 为777，然后再次执行rootupgrade.sh脚本

（注意，两个节点都需要修改）

技术分享

 

成功执行

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[root@node1 ~]#/u01/app/12.1.0/grid/rootupgrade.sh

Performing rootuser operation.

 

The followingenvironment variables are set as:

ORACLE_OWNER= grid

ORACLE_HOME=/u01/app/12.1.0/grid

 

Enter the fullpathname of the local bin directory: [/usr/local/bin]:

The contents of"dbhome" have not changed. No need to overwrite.

The contents of"oraenv" have not changed. No need to overwrite.

The contents of"coraenv" have not changed. No need to overwrite.

 

Entries will beadded to the /etc/oratab file as needed by

DatabaseConfiguration Assistant when a database is created

Finished runninggeneric part of root script.

Nowproduct-specific root actions will be performed.

Using configurationparameter file: /u01/app/12.1.0/grid/crs/install/crsconfig_params

2017/01/18 18:29:20CLSRSC-4015: Performing install or upgrade action for Oracle Trace FileAnalyzer (TFA) Collector.

 

2017/01/18 18:29:21CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector.

 

2017/01/18 18:29:23CLSRSC-464: Starting retrieval of the cluster configuration data

 

2017/01/18 18:33:49CLSRSC-465: Retrieval of the cluster configuration data has successfullycompleted.

 

2017/01/18 18:33:49CLSRSC-363: User ignored prerequisites during installation

 

2017/01/18 18:48:06CLSRSC-472: Attempting to export the OCR

 

2017/01/18 18:48:06CLSRSC-482: Running command: ‘ocrconfig -upgrade grid oinstall‘

 

2017/01/18 18:48:18CLSRSC-473: Successfully exported the OCR

 

2017/01/18 18:48:22CLSRSC-486:

At this stage ofupgrade, the OCR has changed.

Any attempt todowngrade the cluster after this point will require a complete cluster outageto restore the OCR.

 

2017/01/18 18:48:22CLSRSC-541:

To downgrade thecluster:

1. All nodes thathave been upgraded must be downgraded.

 

2017/01/18 18:48:22CLSRSC-542:

2. Before downgradingthe last node, the Grid Infrastructure stack on all other cluster nodes must bedown.

 

2017/01/18 18:48:22CLSRSC-543:

3. The downgradecommand must be run on the node node1 with the ‘-lastnode‘ option to restoreglobal configuration data.

 

2017/01/18 18:48:38CLSRSC-343: Successfully started Oracle Clusterware stack

 

clscfg: EXISTINGconfiguration version 5 detected.

clscfg: version 5is 11g Release 2.

Successfully takenthe backup of node specific configuration in OCR.

Successfullyaccumulated necessary OCR keys.

Creating OCR keysfor user ‘root‘, privgrp ‘root‘..

Operationsuccessful.

2017/01/18 18:49:08CLSRSC-474: Initiating upgrade of resource types

 

2017/01/18 18:49:48CLSRSC-482: Running command: ‘upgrade model -s 11.2.0.4.0 -d 12.1.0.2.0 -pfirst‘

 

2017/01/18 18:49:48CLSRSC-475: Upgrade of resource types successfully initiated.

 

2017/01/18 18:50:02CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster ... succeeded

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

检查确认一下，GI已经升级成功

[grid@node1 ~]$/u01/app/12.1.0/grid/OPatch/opatch lsinventory

Oracle InterimPatch Installer version 12.1.0.1.3

Copyright (c) 2017,Oracle Corporation. All rights reserved.

 

Oracle Home :/u01/app/12.1.0/grid

Central Inventory :/u01/app/oraInventory

from :/u01/app/12.1.0/grid/oraInst.loc

OPatch version :12.1.0.1.3

OUI version :12.1.0.2.0

Log file location :/u01/app/12.1.0/grid/cfgtoollogs/opatch/opatch2017-01-18_19-02-38PM_1.log

 

Lsinventory Outputfile location : /u01/app/12.1.0/grid/cfgtoollogs/opatch/lsinv/lsinventory2017-01-18_19-02-38PM.txt

 

--------------------------------------------------------------------------------

Installed Top-levelProducts (1):

 

Oracle GridInfrastructure 12c 12.1.0.2.0

There are 1products installed in this Oracle Home.

 

 

There are noInterim patches installed in this Oracle Home.

--------------------------------------------------------------------------------

 

OPatch succeeded.

 

 

节点2 也升级成功

[grid@node2 ~]$/u01/app/12.1.0/grid/OPatch/opatch lsinventory

Oracle InterimPatch Installer version 12.1.0.1.3

Copyright (c) 2017,Oracle Corporation. All rights reserved.

 

 

Oracle Home :/u01/app/12.1.0/grid

Central Inventory :/u01/app/oraInventory

from :/u01/app/12.1.0/grid/oraInst.loc

OPatch version :12.1.0.1.3

OUI version :12.1.0.2.0

Log file location :/u01/app/12.1.0/grid/cfgtoollogs/opatch/opatch2017-01-18_19-12-36PM_1.log

 

Lsinventory Outputfile location : /u01/app/12.1.0/grid/cfgtoollogs/opatch/lsinv/lsinventory2017-01-18_19-12-36PM.txt

 

--------------------------------------------------------------------------------

Installed Top-levelProducts (1):

 

Oracle GridInfrastructure 12c 12.1.0.2.0

There are 1products installed in this Oracle Home.

 

 

There are noInterim patches installed in this Oracle Home.

 

 

Patch level statusof Cluster nodes :

 

Patching LevelNodes

-------------------

0 node1,node2

 

--------------------------------------------------------------------------------

 

脚本执行完截图

技术分享

 

 

在GI升级和安装的过程，CVU在这里经常报错，一般是由于没有使用DNS，CVU会调用nslookup进行检测，自然会返回失败，但是我们使用的是/etc/hosts，这里可以忽略。

技术分享

 

 

技术分享

 

错误日志

技术分享

 

技术分享

 

至此，GI部分升级已经完成了！！

大功告成了吗？

是不是少点什么？

 

/dev/sd* 手动修改的777权限，这个是隐患，在每次OS重启之后，它们的权限还是会变回去的。

解决方法有两种：

1. 在/etc/inittab中添加 chmod 777 /dev/sd*

2. 修改asm_diskstring参数

 

作为DBA，我们自然是要通过DB的手段解决这个问题：

 

在其中一个节点上修改asm_diskstring

 

[grid@node2 ~]$sqlplus / as sysasm

SQL> showparameter asm_diskstring

NAME TYPE VALUE

----------------------------------------------- ------------------------------

asm_diskstringstring

 

SQL> altersystem set asm_diskstring=‘/dev/raw/*‘ scope=spfile;--<<<<<<<<<< asm_diskstring 设置为/dev/raw/*

 

这样明确告诉OCSSD进程去/dev/raw/*查找voting disk，问题解决。

 

 


本文出自 “小小狗窝” 博客，请务必保留此出处http://hsbxxl.blog.51cto.com/181620/1894111

Upgrade Oracle GI from 11.2 to 12C


联系
我们