[Oracle] Data Guard CPU/PSU补丁安装详细教程
程序员文章站
2023-11-28 08:46:31
非data guard的补丁安装教程可参考《[oracle] cpu/psu补丁安装详细教程》，data guard需要primary和standby同时打上补丁，所以步骤...
非data guard的补丁安装教程可参考《[oracle] cpu/psu补丁安装详细教程》，data guard需要primary和standby同时打上补丁，所以步骤更复杂一些，其主要步骤如下：
1.在primary停止日志传输服务；
2.关闭standby数据库，在standby的软件上打补丁（注意：不需要为standby数据库打补丁），启动standby为mount状态，不启用managed recovery；
3.关闭primary，在primary的软件和数据库本身都打上补丁；
4.启动primary数据库，重新开启日志传输服务；
5.在standby启动redo apply，这样primary上补丁脚本就会自动同步至standby；
6.检查primary和standby是否都已安装补丁。
下面是一个具体例子：
1. 在primary停止日志传输服务
sys@epay>select database_role from v$database;
database_role
----------------
primary
sys@epay>show parameter log_archive_dest_3
name type value
------------------------------------ ----------- ------------------------------
log_archive_dest_3 string service=sta async valid_for=(o
nline_logfiles,primary_role) d
b_unique_name=epaybk
log_archive_dest_30 string
log_archive_dest_31 string
sys@epay>alter system set log_archive_dest_state_3=defer scope=both;
system altered.
2.在standby的oracle软件打上补丁
2.1 关闭数据库实例，listener，asm实例等
2.2 查看opatch的版本，如果不够，就去下载最新的版本
2.3 在standby的oracle软件上打补丁
2.4 启动standby到mount状态，启动listener
(注意：standby不需要对数据库本身打补丁）
3. 在primary上打补丁
3.1 关闭数据库实例，listener，asm实例等
3.2 查看opatch的版本，如果不够，就去下载最新的版本
3.3 在primary的oracle软件上打补丁
3.4 为primary数据库本身打补丁
cd $oracle_home/rdbms/admin
sqlplus /nolog
sql> connect / as sysdba
sql> startup
sql> @catbundle.sql psu apply
sql> quit
4. 在primary启动日志传输服务
4.1 启动primary listener，数据库实例等
4.2 强制注册services到listener
sys@epay>alter system register;
system altered.
4.3 重新启动日志传输服务
sys@epay>alter system set log_archive_dest_state_3=enable scope=both;
system altered.
注意：启动日志传输，在alert里有可能出现如下错误：
------------------------------------------------------------
check that the primary and standby are using a password file
and remote_login_passwordfile is set to shared or exclusive,
and that the sys password is same in the password files.
returning error ora-16191
------------------------------------------------------------
根据错误信息的提示，应该是主库在做cpu补丁的时候把sys密码修改了，用主库的密码文件替换备库的密码文件即可解决该错误。
5. standby启动redo apply
5.1 open standby 数据库
5.2 启用redo apply
sys@epay>alter database recover managed standby database disconnect from session;
database altered.
5.3 验证primary和standby是否同步
在primary端查询当前最大的归档日志序号：
sys@epay>select max(sequence#) from v$archived_log;
max(sequence#)
--------------
159
在standby端查询已传过来的归档日志：
sys@epay>select sequence#, applied from v$archived_log;
5.4 从alert.log可用看出同步了3个日志文件（即把在primary打的补丁同步到了standby）
alter database recover managed standby database disconnect from session
attempt to start background managed standby recovery process (epay)
wed jul 10 06:03:48 2013
mrp0 started with pid=29, os id=15030
mrp0: background managed standby recovery process started (epay)
started logmerger process
wed jul 10 06:03:53 2013
managed standby recovery not using real time apply
wed jul 10 06:04:01 2013
parallel media recovery started with 32 slaves
waiting for all non-current orls to be archived...
all non-current orls have been archived.
wed jul 10 06:04:01 2013
completed: alter database recover managed standby database disconnect from session
media recovery log /data/oradata/epay/archivelog/1_157_814716635.dbf
media recovery log /data/oradata/epay/archivelog/1_158_814716635.dbf
media recovery log /data/oradata/epay/archivelog/1_159_814716635.dbf
media recovery waiting for thread 1 sequence 160 (in transit)
6. 后期检查补丁是否安装成功
6.1 在primary, standby分别指向opatch lsinventory
6.2 在数据库里检查补丁是否安装成功
1.在primary停止日志传输服务；
2.关闭standby数据库，在standby的软件上打补丁（注意：不需要为standby数据库打补丁），启动standby为mount状态，不启用managed recovery；
3.关闭primary，在primary的软件和数据库本身都打上补丁；
4.启动primary数据库，重新开启日志传输服务；
5.在standby启动redo apply，这样primary上补丁脚本就会自动同步至standby；
6.检查primary和standby是否都已安装补丁。
下面是一个具体例子：
1. 在primary停止日志传输服务
复制代码 代码如下:
sys@epay>select database_role from v$database;
database_role
----------------
primary
sys@epay>show parameter log_archive_dest_3
name type value
------------------------------------ ----------- ------------------------------
log_archive_dest_3 string service=sta async valid_for=(o
nline_logfiles,primary_role) d
b_unique_name=epaybk
log_archive_dest_30 string
log_archive_dest_31 string
sys@epay>alter system set log_archive_dest_state_3=defer scope=both;
system altered.
2.在standby的oracle软件打上补丁
2.1 关闭数据库实例，listener，asm实例等
2.2 查看opatch的版本，如果不够，就去下载最新的版本
2.3 在standby的oracle软件上打补丁
2.4 启动standby到mount状态，启动listener
(注意：standby不需要对数据库本身打补丁）
3. 在primary上打补丁
3.1 关闭数据库实例，listener，asm实例等
3.2 查看opatch的版本，如果不够，就去下载最新的版本
3.3 在primary的oracle软件上打补丁
3.4 为primary数据库本身打补丁
复制代码 代码如下:
cd $oracle_home/rdbms/admin
sqlplus /nolog
sql> connect / as sysdba
sql> startup
sql> @catbundle.sql psu apply
sql> quit
4. 在primary启动日志传输服务
4.1 启动primary listener，数据库实例等
4.2 强制注册services到listener
复制代码 代码如下:
sys@epay>alter system register;
system altered.
4.3 重新启动日志传输服务
复制代码 代码如下:
sys@epay>alter system set log_archive_dest_state_3=enable scope=both;
system altered.
注意：启动日志传输，在alert里有可能出现如下错误：
复制代码 代码如下:
------------------------------------------------------------
check that the primary and standby are using a password file
and remote_login_passwordfile is set to shared or exclusive,
and that the sys password is same in the password files.
returning error ora-16191
------------------------------------------------------------
根据错误信息的提示，应该是主库在做cpu补丁的时候把sys密码修改了，用主库的密码文件替换备库的密码文件即可解决该错误。
5. standby启动redo apply
5.1 open standby 数据库
5.2 启用redo apply
复制代码 代码如下:
sys@epay>alter database recover managed standby database disconnect from session;
database altered.
5.3 验证primary和standby是否同步
在primary端查询当前最大的归档日志序号：
复制代码 代码如下:
sys@epay>select max(sequence#) from v$archived_log;
max(sequence#)
--------------
159
在standby端查询已传过来的归档日志：
复制代码 代码如下:
sys@epay>select sequence#, applied from v$archived_log;
5.4 从alert.log可用看出同步了3个日志文件（即把在primary打的补丁同步到了standby）
复制代码 代码如下:
alter database recover managed standby database disconnect from session
attempt to start background managed standby recovery process (epay)
wed jul 10 06:03:48 2013
mrp0 started with pid=29, os id=15030
mrp0: background managed standby recovery process started (epay)
started logmerger process
wed jul 10 06:03:53 2013
managed standby recovery not using real time apply
wed jul 10 06:04:01 2013
parallel media recovery started with 32 slaves
waiting for all non-current orls to be archived...
all non-current orls have been archived.
wed jul 10 06:04:01 2013
completed: alter database recover managed standby database disconnect from session
media recovery log /data/oradata/epay/archivelog/1_157_814716635.dbf
media recovery log /data/oradata/epay/archivelog/1_158_814716635.dbf
media recovery log /data/oradata/epay/archivelog/1_159_814716635.dbf
media recovery waiting for thread 1 sequence 160 (in transit)
6. 后期检查补丁是否安装成功
6.1 在primary, standby分别指向opatch lsinventory
6.2 在数据库里检查补丁是否安装成功