打补丁笔记

Oracle对于其产品每个季度发行一次的安全补丁包CPU（Critical Patch Update）与PSU（Patch Set Update）补丁，通常是为了修复产品中的安全隐患，并可能包含对一些严重bug以及功能组件的修复。
对于已知的安全漏洞及安全小组检测到的安全漏洞，通过安装数据库安全补丁的方式修复安全漏洞。
打psu前准备
两节点清理小文件
ls -aR /u01 2>/dev/null | awk ‘/😒/{if(fileCount>999){print fileCount,dirName};dirName=substr($0,1,length($0)-1);fileCount=-2}{fileCount++}’
find /u01/app/oracle/admin/zwdb/adump -name “*.aud” -mtime +30 -exec rm {} ;

两节点备份/oracle/bin权限
perl perm1.pl $ORACLE_HOME

两节点备份oracle软件目录
cp -r /u01/app/12.2.0/grid /u01/app/12.2.0/gridbak
cp -r /u01/app/oracle/product/12.2.0/db_1 /u01/app/oracle/product/12.2.0/db_1bak

两节点冲突性检测(grid用户，oracle用户)
./opatch prereq CheckConflictAgainstOHWithDetail -phBasedir /soft/patch/30116802/30138470/

11G使用auto和manual方式打补丁
注意：如果有dg环境需要主库关闭传输，备库停dg应用，并且备库不需要跑catbundle.sql脚本。

Auto
首先验证opatch工具版本，根据readme把opatch升级到所需要的版本，opatch下载参考文档https://updates.oracle.com/download/6880880.html

首先创建响应文件：cd $ORACLE_HOME/OPatch/ocm/bin
./emocmrsp -no_banner -output /tmp/ocm.rsp

之后opatch auto需要root用户执行（调用GRID_HOME下的OPatch工具），会自动停、起集群和数据库，并完成所有home目录的补丁安装。
[root@ytbxdb01 OPatch]# ./opatch auto /backup/patch/28813878/ -ocmrf /tmp/ocm.rsp

最后在执行相关的升级脚本catbundle.sql和重新编译无效对象的脚本utlrp.sql，之后进行升级之后的校验（./opatch lspatches）
Manual
同样是先验证opatch版本，进行兼容性测试。
之后两节点先停掉has再执行unlock脚本
[root@zhlcdb1 install]# pwd
/u01/app/grid/11.2.0.4/ghome/crs/install
[root@zhlcdb1 install]# perl rootcrs.pl -unlock

然后进行打补丁操作
/u01/app/11.2.0/grid/OPatch/opatch napply -oh $ORACLE_HOME -local /u01/software/21523375/21352649

之后验证补丁，然后再在oracle用户进行打补丁操作（需要修改补丁包权限），最后再启动has，启动实例，最后在执行相关的升级脚本catbundle.sql和重新编译无效对象的脚本utlrp.sql，之后进行升级之后的校验（./opatch lspatches），自动打psu需要打2遍，手动需要打4遍。

12c使用auto和manual方式打补丁
Auto
进行补丁冲突检测
进行预安装检查
/u01/app/12.2.0/grid/OPatch/opatchauto apply /u01/software/28980109/28828733 -analyze
查看生成文件：
/u01/app/12.2.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2019-04-02_15-13-05PM_1.log
文件内部应全为PASSED

预安装可能出现错误PRKC-1094：
The bootstrap execution failed because oracle.ops.mgmt.cluster.ClusterInfoException: PRKC-1094 : Failed to retrieve the active version of crs: .

原因：
he issue was investigated in Bug 18338874, Bug 18520928, they are closed as base Bug 19178517 - CRSCTL COMMAND SHOW ADDITIONAL TRACE LOGS ( KGFN) IN OUTPUT

This is due to sqlnet.ora parameter “DIAG_ADR_ENABLED” set to OFF/FALSE (non-default) but environment variable “ORA_CLIENTTRACE_DIR” not set.

解决：
修改sqlnet.ora中的参数，将DIAG_ADR_ENABLED = OFF暂时备注
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.INBOUND_CONNECT_TIMEOUT=0
#DIAG_ADR_ENABLED = OFF

之后在节点一，二上依次进行打补丁操作
/u01/app/12.2.0/grid/OPatch/opatchauto apply /u01/software/28980109/28828733

之后单节点oracle用户注册psu到数据库
cd /u01/app/oracle/product/12.2.0/dbhome_1/OPatch
./datapatch -verbose

最后检查失效对象时如果是PDB数据库需要一次连接PDB检查。
Manual
首先冲突性检测，之后停止crs并执行unlock操作
/u01/app/12.2.0/grid/crs/install/rootcrs.sh -prepatch -nonrolling
./crsctl status resource -t

然后再grid和oracle用户应用补丁
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local /soft/patch/30116802/30138470/

之后在root下执行脚本
su - root
<GI_HOME> /rdbms/install/rootadd_rdbms.sh
/u01/app/12.2.0/grid/crs/install/rootcrs.sh -postpatch -nonrolling（自动启动了crs）

最后重新编译无效对象

补丁回退
回滚补丁和打补丁之前必须要停止EM
12c数据库中已经没有oemctl控制命令，改为在sqlplus中调用dbms_xdb_config.gethttpsport、dbms_xdb_config.gethttpport包的方式来查看oem端口的打开情况，当查询有端口号时代表打开，为0时代表关闭
开启
exec DBMS_XDB_CONFIG.SETHTTPSPORT(5500);
查询
SELECT dbms_xdb_config.gethttpsport FROM DUAL;
关闭
exec DBMS_XDB_CONFIG.SETHTTPSPORT(0);

首先停止节点实例，停止集群
$ORACLE_HOME/crs/install/rootcrs.pl –unlock

依次回退crs补丁
[grid@rac1 ~]$ $ORACLE_HOME/OPatch/opatch rollback -local -id xxxxxx -oh $ORACLE_HOME

DB补丁回退前执行脚本（使用oracle用户执行）
[oracle@rac1 ~]$ cd /u01/app/oracle/patches
[oracle@rac1 patches]$ 14275572/custom/server/14275572/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME

依次回退db补丁
[oracle@rac1 patches]$ $ORACLE_HOME/OPatch/opatch rollback -local -id xxxxx -oh $ORACLE_HOME

回退DB补丁后执行脚本（oracle用户执行）
[root@rac1 ~]# $ORACLE_HOME/rdbms/install/rootadd_rdbms.sh
[root@rac1 ~]# $ORACLE_HOME/crs/install/rootcrs.pl –patch

开启实例执行回退脚本
@catbundle_PSU__ROLLBACK.sql

查询回退状态，补丁状态

PostgreSql数据库打补丁
源码方式的小版本升级，由12.0升级至12.1
首先安装pg12.0
然后停止pg12.0并编译安装12.1
最后启动12.1，之前12.0版本安装的插件经测试会继承过来
大版本升级
转储方式（pg_dumpall）
实质是在旧版本备份，新版本还原，数据量大升级会持续很长时间。
以11升级12的大版本为例
首先安装新版本数据库软件，然后把配置文件复制到新版本
如（pg_hba.conf,pg_ident.conf,postgresql.conf）
最后尝试启动新实例

升级前把11版本的数据库设置为只读模式
然后使用pg_dumpall命令备份数据文件
/opt/pg11/bin/pg_dumpall -p 5555 > backup.sql

然后在新版本还原备份文件
/opt/pg12/bin/psql -p 6666 -f backup.sql
升级成功可以关闭旧版本数据库，可以相应的修改新版本端口为旧版本端口。
Pg_upgrade方式
不需要费时的转储，升级前需进行数据库备份，先升级扩展插件到新版本。
通过pg_upgrade –help可查看命令帮助
安装新版本数据库软件，停止旧版本数据库，升级前检查兼容性
/opt/pg12/bin/pg_upgrade -b /opt/pg11/bin/ -B /opt/pg12/bin/ -d /soft/data11/ -D /soft/data12/ -k -c
最后一行输出Clusters are compatible说明通过兼容性测试

使用pg_upgrade普通模式升级（copy）
/opt/pg12/bin/pg_upgrade -b /opt/pg11/bin/ -B /opt/pg12/bin/ -d /soft/data11/ -D /soft/data12/
之后还原旧配置文件后启动数据库再依次执行sh脚本
./analyze_new_cluster.sh
./delete_old_cluster.sh（会删除旧版本的数据文件）
注意：从9版本升级10或者以上版本需要重建hash索引

使用pg_upgrade的link模式升级
使用链接模式可以减少占用空间，使用链接模式会把旧版本的pg_control文件命名为pg_control.old，如果仍想运行旧实例，需要重命名回来，但是一旦使用新版本启动数据库实例，旧实例无法访问，实质是新数据数据目录中建立链接到老数据目录。
/opt/pg12/bin/pg_upgrade -b /opt/pg11/bin/ -B /opt/pg12/bin/ -d /soft/data11/ -D /soft/data12/ -k
更新统计信息
./analyze_new_cluster.sh命令只是快速创建最少的优化统计信息让数据库可用，之后可以手动运行vacuum命令。
启动新实例执行完analyze脚本后可以手动vacuum一下
/opt/pg12/bin/vacuumdb -a --analyze-in-stages -p 6666

link模式 新数据数据目录中建立链接到老数据目录，此种模式老数据库和新数据库无法同时启动使用
copy模式 完全复制老数据目录到信数据目录，此目录调整端口后不影响老数据库运行 新旧数据库可以同时运行

升级从库
一主多从升级从库时需要同步复制模式，不能是异步模式。
首先查询模式：select application_name,sync_state from pg_stat_replication;
主库修改配置文件postgres.conf中的synchronous_standby_names参数为*表示所有从库都使用同步复制模式。之后select pg_reload_conf();使其生效。

关闭集群，先关主库再关从库，通过pg_controldata验证主库从库最后的检查点位置是否相同：
/opt/pg11/bin/pg_controldata /soft/11.5/data_master |grep “Latest checkpoint location”
/opt/pg11/bin/pg_controldata /soft/11.5/data_slave | grep “Latest checkpoint location”

先升级主库到新版本
安装新软件后复制一份到从库服务器并与从库检验下database system identifier
/opt/pg11/bin/pg_controldata /soft/11.5/data_master |grep “Database system identifier”
/opt/pg11/bin/pg_controldata /soft/11.5/data_slave | grep “Database system identifier”

之后使用pg_upgrade方式升级主库，之后升级从库

之后启动主库从库检验升级，检验同步
Pglogical方式
使用pglogical优点是可以在更短时间内完成升级，并且即使失败也可以很容易的进行回滚（实质类似于使用ogg进行高低版本的数据同步）但是升级前需要做大量检查工作

1. 数据库必须9.4以上版本
2. 每张表必须有主键和唯一值
3. 不能复制临时表和unlogged表
4. 一次只能复制一个实例的一个数据库
5. 无法复制ddl