oracle 补丁种类和升级方法以及oracle RAC Rolling Patch 说明

  • 不一样的天空w

    2017-11-16 17:24:43
  • Oracle
  • 转载
一、oracle 补丁种类和升级方法

oracle有很多种补丁类型，我们应该对oracle的补丁类型有一定了解，特别是一些关键的补丁，可能客户会定期对数据库升级，无论修复bug，还是为了安全。

下面我对数据库的补丁进行一定的讲解：

补丁类型：
1. release

这个是数据库的基本版本，标准产品发布。如OracleDatabase 10g Release 2的第一个发行版本为10.2.0.1,可以在OTN、edelivery等站点上公开下载，现在在网上只能下载oracle 11g和oracle 12c。

2. Patch Set Release

就是早期大家常说的PSR。这是在主版本号上发布的补丁集，修复了较多的Bug，可能会包含一些增强功能（Enhancement）。比如11.2.0.1是一个主版本，那么11.2.0.2、11.2.0.3就是2个不同的Patchset。这种补丁集经过了严格的集成测试，也是累积型的。所以推荐安装最新的Patchsets

这种补丁在oracle 11.2之前都是覆盖方式升级，就是直接补丁覆盖原来软件，这样停机时间会长。如果需要升级到oracle10.2.0.5,那么只能先安装oracle 10.2.0.1,然后升级到oracle 10.2.0.5；
而到oracle11.2之后 oracle使用Out-of-Place，就是补丁可以直接安装了，并且如果想升级到oracle 11.2.0.4的时候不需要先安装oracle11.2.0.1,然后升级到oracle 11.2.0.4,可以直接安装oracle 11.2.0.4。可以将Oracle Database安装到新的OracleHome目录，当安装结束后，旧的database会迁移到新的Oracle HOME目录。 这种方法是oracle推荐的方式，它可以降低停机时间，也相对更安全。但是这种方法需要至少两倍的磁盘空间。

3. Patch Set Update

就是DBA&DMA们常论道的PSU。Oracle选取在每个季度用户下载数量最多，并且得到验证具有较低风险的补丁放入到每个季度的PSU中，修复比较严重的一些问题，包含每个季度的CPU，是累积型的。虽然在描述PSU的时候会用到数据库版本第5位，比如DatabasePSU 11.2.0.3.5，但实际上打完PSU后并不会真正改变数据库的版本，从v$version中看到的版本还是4位的(11.2.0.3.0)，第5位仍然是0。

这种补丁客户会经常进行操作的，也是我们需要必会的。

4. Critical Patch Update

这个指的就是CPU补丁。每季度发布一次，用来修复安全方面的一些补丁，是累积型的。目前(2012年10月）已经更名为Security Patch Update (SPU)
这类问题本来不属于软件错误,在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码 ，绕过数据库系统的安全管理机制,达到非授权存取的目的

这种补丁是偏向安全的，就是修复oracle漏洞。

5. Interim Patch/One-Off Patch

是我们常说的小补丁，为了修复某(几)个Bug而发布的补丁。这种补丁推荐在测试库上测试无误后再安装在生产库上，这种补丁是oracle最小单元。

6. Bundle Patch(BP)

补丁集，修复多个Bug。在Windows平台上的Oracle没有小补丁，只有这种Bundle Patch。 这种累积型的补丁集会周期性的发布（至少每季一次）,也就是每个Bundle Patch会包含之前所有的Bundle Patch。比如Windows Bundle Patch 16，它会包含之前所有15个BundlePatch，所以我们总是推荐安装最新的Bundle Patch。Oracle的集群软件和数据库软件的Window Bundle Patch是同一个，比如Windows Bundle Patch 16(补丁号16167942，既可以打在集群上，也可以打在数据库上)


7.补丁打得方法和注意事项：

以上的补丁除了PSR直接使用runInstaller，其他的补丁类型都是使用opatch命令，在oracle 10g之前，我们需要单独下载此命令，到oracle 10g之后这个命令在 ORACLE_HOME/Opatch下，因此，最好在环境变量path中添加以下.打补丁需要inventory是没有问题的，需要通过opatch lsinventory来验证。

由于rac环境除了PSR，其他补丁类型可以每台服务器单独打，因此在打补丁的时候加上-local。如：
 opatch apply -local

除了PSR，其他补丁可以回退，回退方法：opatch rollback -id 后边跟补丁号


二、 Oracle RAC Rolling Patch 说明
关于Oracle 的Patch安装，之前有整理过几篇文档，如下：

Oracle 补丁体系 及opatch 工具 介绍
http://blog.csdn.net/tianlesoftware/article/details/5809526

Oracle 11g 新特性 --Online Patching （Hot Patching 热补丁）说明
http://blog.csdn.net/tianlesoftware/article/details/8214412

Oracle 更新 OPatch 工具版本 的方法说明
http://blog.csdn.net/tianlesoftware/article/details/6857059

这里看一下RAC的Patch。 这里是针对DB Patch 来说明，如果是RAC的GI升级，或者是PSR，还是需要停机的。因为GI的升级需要停掉整个CRS，但对数据库独立patch则可以采取滚动方式来安装。

 
RAC Patch的几种方法

RAC 环境下有三种不同的patch方法：

1.1 对所有节点同时Patch（All-Node Patch）

对于这种模式，OPatch 先在本地节点apply patch，然后在其他节点apply，最后更新inventory。 在这个patch的过程中，所有实例都必须shutdown。

该模式的操作步骤如下：

（1）关闭所有节点上的实例。
（2）在所有节点上apply patch。
（3）启动所有实例。

 
1.2 使用最小宕机时间来打Patch

在这种模式下，OPatch 先对本地节点打opatch。然后让用户选择其他的节点来进行patch，其他节点也patch完成，最后在更新inventory。

在这种模式下，downtime的时间就是第二个节点关闭到第一个节点起来之间的时间。

最小宕机的操作步骤如下：

（1）关闭节点1的实例
（2）在节点1上apply Patch
（3）关闭节点2上的实例。
（4）在节点2上应用Patch。
（5）关闭节点3上的实例。
（6）在这个时候，节点1和节点2的实例可以启动。
（7）在节点3上应用patch。
（8）启动节点3上的实例。

以上整个过程，downtime就是节点3 shutdown到节点1，2启动这段时间。

 
1.3 Rolling Patch（不需要down time）
在这种方法里，没有downtime 时间。 每个节点都可以打patch，并且其他节点也可以正常运行，这种情况下对系统就没有影响。

Rolling Patch 也不总是不需要downtime时间，因为有些patch支持 rolling patch，有些不支持，对于不支持rolling patch的，只能按照老方法来安装。

Rolling patch的步骤如下：

（1）关闭节点1的实例
（2）在节点1上应用Patch。
（3）在节点1上启动实例。
（4）关闭节点2上的实例。
（5）在节点2上应用Patch。
（6）在节点2上启动实例。
（7）关闭节点3上的实例。
（8）在节点3上应用Patch。
（9）启动节点3上的实例。


1.4 如何判断使用哪种方法

只有满足特定条件的Patch 才可以进行rolling patch。该类patch被称为:rolling updateble patch 或者 rolling patch。
如果用户指定了最小宕机时间，选择最小宕机时间，如果没有指定，就使用rolling patch，最后在考虑同时对所有节点进行patch。

 
三. 如何判断Patch 是否是Rolling Patch？

当oracle 发布一个patch的时候，会对patch 进行标记：rolling 或者是not rolling。大部分的patch 都是rolling的。

Rolling Patch 有如下特性：

（1）Patch 不影响数据库的内容
（2）Patch 和RAC 内部通信结构无关
（3）Patch 改变程序的逻辑，不修改kernel modules的common header definitions。包括客户端的patch，其只影响一些工具，如export,import,sql*plus和sql*loader等。

只有独立的patches才是rollable的。对于patch sets不能进行rolling patch。

将多个rolling patch 合并起来的merge patch 和普通的patch都不是 rolling patch。

从Oracle 9.2.0.4 开始，根据定义的规则，所有的的patches都会被标记为rolling 或者 not rolling patch。 在这之前的patch都会标记为not rolling。

 
检查patch是否是 rolling patch

执行如下命令：
   - 9i or 10gR1: opatch query -is_rolling
   - 10gR2: opatch query -all  [unzipped patchlocation] | grep rolling
   - 10gR2 on Windows: opatch query -all [unzipped patchlocation] | findstr rolling
   - Later 10gR2 or 11g: opatch query -is_rolling_patch [unzipped patch location]

如果我们解压缩的patch 路径包含多个子patch目录，那么opatch命令就不能正常工作。

--不能用root用户执行判断命令：

[root@rac1 16056266]#/u01/app/grid/11.2.0/OPatch/opatch query -is_rolling_patch/u01/software/16056266

The user is root. OPatch cannot continue ifthe user is root.

OPatch failed with error code 255

[root@rac1 16056266]# su - grid

[grid@rac1 ~]$/u01/app/grid/11.2.0/OPatch/opatch query -is_rolling_patch/u01/software/16056266

Oracle Interim Patch Installer version11.2.0.3.4

Copyright (c) 2012, OracleCorporation.  All rights reserved.

Oracle Home       : /u01/app/grid/11.2.0
Central Inventory : /u01/app/oraInventory
  from            :/u01/app/grid/11.2.0/oraInst.loc
OPatch version    : 11.2.0.3.4
OUI version       : 11.2.0.3.0
Log file location :/u01/app/grid/11.2.0/cfgtoollogs/opatch/opatch2013-06-09_04-14-34AM_1.log

Failed to load the patch object.  Possible causes are:
  Thespecified path is not an interim Patch shiphome
 Meta-data files are missing from the patch area
 Patch location = /u01/software/16056266
 Details = Input metadata files are missing.

Patch Location"/u01/software/16056266" doesn't point to a valid patch area.

--因为我们指定的/u01/software/16056266的路径下面还包含其他的子patch，所以报错。

OPatch failed with error code 75


[grid@rac1 ~]$ cd /u01/software/16056266
[grid@rac1 16056266]$ ls
13343438 13696216  13923374  14275605 14727310  16056266  patchmd.xml README.html  README.txt

--对单个patch进行查看：
[grid@rac1 16056266]$  /u01/app/grid/11.2.0/OPatch/opatch query-is_rolling_patch /u01/software/16056266/13343438/

Oracle Interim Patch Installer version11.2.0.3.4
Copyright (c) 2012, OracleCorporation.  All rights reserved.

oracle Home       : /u01/app/grid/11.2.0
Central Inventory : /u01/app/oraInventory
  from           :/u01/app/grid/11.2.0/oraInst.loc
OPatch version    : 11.2.0.3.4
OUI version       : 11.2.0.3.0
Log file location :/u01/app/grid/11.2.0/cfgtoollogs/opatch/opatch2013-06-09_04-15-17AM_1.log

--------------------------------------------------------------------------------
 Patch is a rolling patch: true
 
OPatch succeeded.

[grid@rac116056266]$ /u01/app/grid/11.2.0/OPatch/opatch query -is_rolling_patch/u01/software/16056266/13696216

Oracle Interim Patch Installer version11.2.0.3.4
Copyright (c) 2012, OracleCorporation.  All rights reserved.

Oracle Home       : /u01/app/grid/11.2.0
Central Inventory : /u01/app/oraInventory
  from           :/u01/app/grid/11.2.0/oraInst.loc
OPatch version    : 11.2.0.3.4
OUI version       : 11.2.0.3.0
Log file location :/u01/app/grid/11.2.0/cfgtoollogs/opatch/opatch2013-06-09_04-15-32AM_1.log

--------------------------------------------------------------------------------
 Patch is a rolling patch: true
 
OPatch succeeded.
 
Patch的一些限制
 
1.在Shared File System上进行Patch时，Currently Opatch会把Shared File System当作单实例来进行Patch。OPatch 会把patch file 放在ORACLE_HOME目录，因为是共享的，所以其他节点也可以访问。因此对于Shared FileSystem的环境，就不能使用OPatch 的高级功能：rollingpatch，在打Patch的时候，所有节点都必须shutdown。

2.每次Patch一个节点时，可以在每个节点独立的进行patch，即在opatch的时候只用: -local 关键字，这样就只会在本地节点进行patch。
请使用浏览器的分享功能分享到微信等