#解锁Oracle 11g潜能：精准补丁包与高效数据库升级策略#

Oracle 11g数据库升级通常涉及应用补丁集，这些补丁集是Oracle公司发布的，用于修复已知的错误、提高性能、增强安全性和添加新功能。升级过程应该谨慎进行，因为它可能会影响到生产环境。

本实验用到的三个解压包讲解：

p31718723_112040_Linux-x86-64.zip（Oracle Grid Infrastructure 补丁集）

p31668908_112040_Linux-x86-64.zip（Oracle JavaVM 组件 11.2.0.4.201020 数据库 PSU）

p6880880_112000_Linux-x86-64.zip（升级OPLAN）

实验环境规划：

1.备份数据库

在打补丁之前，应该对数据库进行完整备份。这是为了在补丁过程中发生任何意外时能够恢复数据库到原始状态。

1.1rman全备

两个节点都需要进行操作

创建备份数据存储目录

我这里使用的是oracle用户如果使用root用户需要赋予权限

mkdir /u01/app/oracle/rman
ls /u01/app/oracle/

1.2设置归档

两个节点都需要进行操作

使用RMAN备份时，要确定数据库处于归档模式下

archive log list;

 我的不在归档，那么就要设置到归档，

需要先关闭数据库，再启动数据库到挂载状态

--------关闭数据库----------
SHUTDOWN IMMEDIATE;
--------使数据库挂载--------
startup mount;
--------开启归档-----------
alter database archivelog;

1.3进入rman进行备份

rman target /

-----------把/u01/app/oracle/rman/替换成自己的目录----------
configure channel device type disk format '/u01/app/oracle/rman/%d_db_%u_backup';
--------------备份数据库--------------
backup database;
-------------查看备份信息---------
list backupset;

1.4查看备份文件

OK备份完成，做完发现这里感觉使用backup database备份不是很好，因为它可能不会提供完整的备份，特别是对于大型的数据库。

1.5关闭数据库

2.补丁解压

2.1 上传到虚拟机中

我直接上传到/opt中，把两个节点都传过去，传一个使用scp传输也可以

2.2修改压缩包权限

使用root用户
chown grid:oinstall /opt/p31718723_112040_Linux-x86-64.zip
chown oracle:oinstall /opt/p31668908_112040_Linux-x86-64.zip
chown grid:oinstall /opt/p6880880_112000_Linux-x86-64.zip

2.3创建解压目录

使用root用户，两个节点都需要进行
mkdir /opt/pus
chown grid:oinstall /opt/pus/

解压p31718723_112040_Linux-x86-64.zip（Oracle Grid Infrastructure 补丁集）

把p31718723_112040_Linux-x86-64.zip（Oracle Grid Infrastructure 补丁集）解压到/opt/pus中

unzip /opt/p31718723_112040_Linux-x86-64.zip -d /opt/pus/

解压p6880880_112000_Linux-x86-64.zip

分别在节点1和节点2使用grid用户和oracle用户进行解压 

unzip /opt/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME/

解压后需要查看一下版本是否相同

opatch version

解压p31668908_112040_Linux-x86-64.zip（Oracle JavaVM 组件 11.2.0.4.201020 数据库 PSU）

分别在racnode1和racnode2使用oracle解压p31668908_112040_Linux-x86-64.zip

unzip /opt/p31668908_112040_Linux-x86-64.zip -d /opt/pus/

3.安装补丁

p31718723_112040_Linux-x86-64.zip（Oracle Grid Infrastructure 补丁集）中自带的README.html可以查看解压后每个编号的描述，和适用用户，对此补丁的描述信息也有

还是翻译爽。。。。

 3.1打p31718723_112040_Linux-x86-64.zip（Oracle Grid Infrastructure 补丁集）

以下是在racnode1执行

先打的是grid用户的补丁包

使用root用户
/u01/app/11.2.0/grid/OPatch/opatch auto /opt/pus/31718723 -oh /u01/app/11.2.0/grid

再打oracle补丁包 

使用root用户
/u01/app/oracle/product/11.2.0/db_1/OPatch/opatch auto /opt/pus/31718723 -oh /u01/app/oracle/product/11.2.0/db_1/ 

3.2查看打的补丁

使用grid用户，oracle用户在racnode1查看补丁情况

opatch lspatches

racnode2和racnode1方法一样这里不写了，代码都一模一样

3.2打p31668908_112040_Linux-x86-64.zip（Oracle JavaVM 组件 11.2.0.4.201020 数据库 PSU）

停服务

使用root用户
crsctl stop crs

在使用racnode2查看crs是否关闭

crsctl stat res -t

没有关于racnode1的服务了

使用oracle 用户打补丁

su oracle
cd /opt/pus/31668908
opatch apply

[oracle@racnode1 31668908]$ opatch apply
Oracle Interim Patch Installer version 11.2.0.3.25
Copyright (c) 2024, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0/db_1/oraInst.loc
OPatch version    : 11.2.0.3.25
OUI version       : 11.2.0.4.0
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2024-03-17_22-17-04PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   31668908  

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/11.2.0/db_1')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '31668908' to OH '/u01/app/oracle/product/11.2.0/db_1'
ApplySession: Optional component(s) [ oracle.sqlj, 11.2.0.4.0 ] , [ oracle.sqlj.companion, 11.2.0.4.0 ]  not present in the Oracle Home or a higher version is found.

Patching component oracle.javavm.server, 11.2.0.4.0...

Patching component oracle.precomp.common, 11.2.0.4.0...

Patching component oracle.rdbms, 11.2.0.4.0...

Patching component oracle.rdbms.dbscripts, 11.2.0.4.0...

Patching component oracle.javavm.client, 11.2.0.4.0...

Patching component oracle.dbjava.jdbc, 11.2.0.4.0...

Patching component oracle.dbjava.ic, 11.2.0.4.0...
Patch 31668908 successfully applied.
Log file location: /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2024-03-17_22-17-04PM_1.log

OPatch succeeded.

通过运行以下命令验证补丁是否已成功安装： 

opatch lsinventory

racnode2一样代码都一样这里不写了

但是也要关闭crs

4.启动数据库，执行脚本

分别在racnode1和racnode2使用root用户开启crs

crsctl start crs

 大概要等个几分钟，服才能起来，这个东西随着电脑越好缩短

crsctl stat res -t

出现上图这种情况说明服务还在启动中

cd $ORACLE_HOME/sqlpatch/31668908
sqlplus / as sysdba

在进去sqlplus 打开数据库

查看数据库状态

select status from v$instance;

        

对于 Oracle RAC 环境，请使用以下命令在其中一个节点上重新装入包。确保远程节点上没有其他数据库实例。

关闭数据库集群参数：（一个节点执行）
 alter system set cluster_database=FALASE scope=spfile;

关闭数据库实例：（所有节点执行）
shutdown immediate;

数据库启动为升级模式：（一个节点执行）
startup upgrade;

#升级模式中的数据库状态：
#SQL> select instance_name,status from v$instance;
#INSTANCE_NAME	 STATUS
#---------------- ------------
#	orcl		 OPEN MIGRATE

执行数据库升级脚本

开数据库数据库集群参数：（一个节点执行）
alter system set cluster_database=TRUE scope=spfile;

关闭数据库：（一个节点执行）
SQL> shutdown immediate;

启动数据库：（所有节点执行）
SQL> startup;

 安装修补程序的 SQL 部分后，某些软件包可能会变得无效。这将在访问时重新编译，或者您可以运行以将它们恢复到 VALID 状态。utlrp.sql

如图就是执行sql事出现的问题

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql

5.查看安装的Oracle补丁 

set line 200
col COMMENTS for a45
col ACTION_TIME for a35
select ACTION_TIME,version,COMMENTS from registry$history;

这里推荐，看原文自带的redme比较好，原文写的也比较清晰明了