需求:最近公司进行Oracle进行服务器硬件升级,顺便把数据库也进行升级,我们目前使用的数据库版本是10.2.0.5
升级到10版本的最新psu 升级数据库到10.2.0.5.19
升级思路:
Oracle 数据库迁移思路:
1.在虚拟机中搭建了三台oracle数据库服务器,其中两台的数据库版本为oracle 10.2.0.5 第三台为oracle10.2.0.5的最终升级版本,分别标记为A,B,C ,其中A,B服务器为没有打补丁的数据库服务器,C为安装了psu的服务器
2.选择其中两台A,B进行主从搭建,A为主,B为备,C暂时空置
3.C机器加入,成为A机器的DG,这样数据库就有了两台DG
4.C和A进行主从切换,这样C变成主,A变成DG
5.A数据库关闭,进行psu补丁更新
6.A补丁升级成功后,C进行字典表更新
7.验证C和A之间同步是否正常,正常的话,B也数据库关闭打psu补丁,B的主数据库变成C
8.上述过程如果都OK,本次升级就圆满完成了

目前的数据库环境是一主已从,采用的是物理DG 环境,考虑到都是线上数据库,都有线上业务在进行的,我们采用滚动升级的模式,升级需要的补丁包:p20299014_10205_Linux-x86-64.zip p6880880_102000_LINUX.zip
第一个是psu软件,第二个是Opatch 软件
升级过程A,B,C 三台为物理服务器,A为主数据库,B为DG数据库,C为硬件升级的服务器
C服务器上执行步骤
1.安装centos操作系统
2.配置环境变量,yum相关补丁包,系统参数,数据库软件安装到10.2.0.5
3.升级OPatch版本
没有升级OPatch版本之前
db03-> /u01/app/oracle/product/10.2.0.5/db_1/OPatch/opatch lsinventory
Invoking OPatch 10.2.0.4.9

Oracle 中间补丁程序安装程序版本 10.2.0.4.9
版权所有 (c) 2009, Oracle Corporation。保留所有权利。

Oracle 主目录 : /u01/app/oracle/product/10.2.0.5/db_1
主产品清单: /u01/app/oracle/oraInventory
从 : /etc/oraInst.loc
OPatch 版本 : 10.2.0.4.9
OUI 版本 : 10.2.0.5.0
OUI 位置 : /u01/app/oracle/product/10.2.0.5/db_1/oui
日志文件位置 : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch2020-05-26_23-33-40下午.log

Patch history file: /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/lsinv/lsinventory2020-05-26_23-33-40下午.txt


已安装的顶级产品 (2):

Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0
此 Oracle 主目录中已安装 2 个产品。

此 Oracle 主目录中未安装任何中间补丁程序。


OPatch succeeded.
升级过程
db03-> cd /u01/app/oracle/product/10.2.0.5/db_1/
db03-> mv OPatch/ OPatchbk
db03-> mv /u01/software/OPatch/ ./
升级之后
db03-> /u01/app/oracle/product/10.2.0.5/db_1/OPatch/opatch lsinventory
Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1
版权所有 (c) 2010, Oracle Corporation。保留所有权利。

Oracle 主目录 : /u01/app/oracle/product/10.2.0.5/db_1
主产品清单: /u01/app/oracle/oraInventory
从 : /etc/oraInst.loc
OPatch 版本 : 10.2.0.5.1
OUI 版本 : 10.2.0.5.0
OUI 位置 : /u01/app/oracle/product/10.2.0.5/db_1/oui
日志文件位置 : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch2020-05-26_23-37-24下午.log

Patch history file: /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/lsinv/lsinventory2020-05-26_23-37-24下午.txt


已安装的顶级产品 (2):

Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0
此 Oracle 主目录中已安装 2 个产品。

此 Oracle 主目录中未安装任何中间补丁程序。


OPatch succeeded.

升级之后OPatch版本变成了10.2.0.5.1
接下来升级数据库软件
验证补丁是否能安装
db03-> $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/20299014 -oh $ORACLE_HOME
Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1
版权所有 (c) 2010, Oracle Corporation。保留所有权利。

PREREQ session

Oracle 主目录 : /u01/app/oracle/product/10.2.0.5/db_1
主产品清单: /u01/app/oracle/oraInventory
从 : /etc/oraInst.loc
OPatch 版本 : 10.2.0.5.1
OUI 版本 : 10.2.0.5.0
OUI 位置 : /u01/app/oracle/product/10.2.0.5/db_1/oui
日志文件位置 : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch2020-05-26_23-40-43下午.log

Patch history file: /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.
可以安装,下面开始打补丁
db03-> $ORACLE_HOME/OPatch/opatch napply -oh $ORACLE_HOME -local /u01/software/20299014
Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1
版权所有 (c) 2010, Oracle Corporation。保留所有权利。

UTIL session

Oracle 主目录 : /u01/app/oracle/product/10.2.0.5/db_1
主产品清单: /u01/app/oracle/oraInventory
从 : /etc/oraInst.loc
OPatch 版本 : 10.2.0.5.1
OUI 版本 : 10.2.0.5.0
OUI 位置 : /u01/app/oracle/product/10.2.0.5/db_1/oui
日志文件位置 : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch2020-05-26_23-41-06下午.log

Patch history file: /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch_history.txt

Invoking utility "napply"
Checking conflict among patches...
Checking if Oracle Home has components required by patches...
Checking conflicts against Oracle Home...
OPatch continues with these patches: 20299014

是否继续? [y|n]
y

....
正在为组件 oracle.dbjava.ic, 10.2.0.5.0 打补丁...
用 "/jdbc/lib/ojdbc14.jar/oracle/jdbc/driver/OracleDatabaseMetaData.class" 更新 jar 文件 "/u01/app/oracle/product/10.2.0.5/db_1/jdbc/lib/ojdbc14.jar"
用 "/jdbc/lib/ojdbc14.jar/oracle/jdbc/driver/OracleSql.class" 更新 jar 文件 "/u01/app/oracle/product/10.2.0.5/db_1/jdbc/lib/ojdbc14.jar"

正在为组件 oracle.oraolap, 10.2.0.5.0 打补丁...
用 "lib/liboraolap10.a/xsfisop.o" 更新归档文件 "/u01/app/oracle/product/10.2.0.5/db_1/lib/liboraolap10.a"
用 "lib/liboraolap10.a/xsiosec.o" 更新归档文件 "/u01/app/oracle/product/10.2.0.5/db_1/lib/liboraolap10.a"
Copying file to "/u01/app/oracle/product/10.2.0.5/db_1/olap/admin/bug20558005.sql"
ApplySession 将中间补丁程序 '20299014' 添加到产品清单

Verifying the update...
Inventory check OK: Patch ID 20299014 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 20299014 are present in Oracle Home.
正在对目标 client_sharedlib 运行 make 命令
正在对目标 ikfod 运行 make 命令
正在对目标 ioracle 运行 make 命令
正在对目标 iwrap 运行 make 命令
正在对目标 client_sharedlib 运行 make 命令
正在对目标 proc 运行 make 命令
正在对目标 irman 运行 make 命令
正在对目标 itnslsnr 运行 make 命令
Execution of 'sh /u01/software/20299014/custom/scripts/post -apply 20299014 ':

Return Code = 0

本地系统已打补丁, 可以重新启动。

UtilSession: N-Apply done.

OPatch succeeded.
看到这说明OPatch已经成功了
下面看下数据库软件补丁是否已经应用成功
db03-> /u01/app/oracle/product/10.2.0.5/db_1/OPatch/opatch lsinventory
Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1
版权所有 (c) 2010, Oracle Corporation。保留所有权利。

Oracle 主目录 : /u01/app/oracle/product/10.2.0.5/db_1
主产品清单: /u01/app/oracle/oraInventory
从 : /etc/oraInst.loc
OPatch 版本 : 10.2.0.5.1
OUI 版本 : 10.2.0.5.0
OUI 位置 : /u01/app/oracle/product/10.2.0.5/db_1/oui
日志文件位置 : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch2020-06-02_09-55-07上午.log

Patch history file: /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u01/app/oracle/product/10.2.0.5/db_1/cfgtoollogs/opatch/lsinv/lsinventory2020-06-02_09-55-07上午.txt


已安装的顶级产品 (2):

Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0
此 Oracle 主目录中已安装 2 个产品。

中间补丁程序 (1) :

Patch 20299014 : applied on Wed May 27 14:48:16 CST 2020
Unique Patch ID: 19074368
Created on 24 Jun 2015, 02:35:37 hrs PST8PDT
Bugs fixed:
20074391, 13596521, 17088068, 8865718, 17201047, 13489660, 9020537
8664189, 10091698, 14275629, 19909862, 17832122, 17832123, 17832124
17832125, 16619894, 8822531, 10139235, 20299014, 8350262, 7119382
19274521, 13632738, 11724962, 20331945, 19274523, 9320130, 16961614
16961615, 13775862, 16961616, 16961617, 19006757, 16961618, 16961619
18221699, 9399589, 14841459, 9672816, 9499302, 20299021, 9659614, 13632743
9949948, 14220725, 8882576, 7612454, 7111619, 9711859, 9714832, 12780098
13561951, 14665116, 11066597, 16703112, 19231857, 17721717, 9713537
14459552, 19458377, 13737773, 13737775, 16212405, 18096714, 16338983
14390396, 10249537, 19006849, 7115910, 8354642, 7602341, 14076510
12565867, 15987029, 16462834, 18641419, 11693109, 14023636, 9024850
8394351, 8224558, 17082365, 14149782, 9109487, 14841558, 9171933
10173237, 16817117, 10068982, 10306945, 8666117, 11725006, 10214450
14205448, 17082371, 9767674, 16306019, 9323583, 9726739, 16279211
8412426, 10326338, 10165083, 6651220, 9145204, 13554409, 11076894
19854436, 11893577, 17865671, 16746190, 14492313, 14492314, 11814891
14492315, 14492316, 16742123, 21048089, 16864562, 14546638, 12419258
16056270, 10010310, 18139709, 9689310, 9390484, 21048090, 21048091
9963497, 12551700, 16362358, 12551701, 17465584, 12551702, 12551703
12551704, 10076669, 12551705, 16270946, 12551706, 12551707, 6076890
9308296, 12551708, 14258925, 12880299, 17381900, 18641451, 17381901
17381902, 11790175, 12796518, 9772888, 8650138, 17056813, 14469008
12551710, 10092858, 7519406, 9821321, 8771916, 13349665, 7509714
10159846, 13257247, 18031728, 18641461, 16372203, 11792865, 19007266
19309466, 16309604, 16309605, 16309606, 18522511, 8966823, 11674645
17551414, 15877957, 15877958, 7026523, 15877959, 17716305, 13503598
18767250, 9150282, 9448311, 10327179, 14774730, 19153980, 9735237
9952230, 15877960, 15877961, 15877962, 15877963, 8660422, 18221700
18221701, 16279401, 14546673, 14105702, 14105703, 14105704, 13483152
14269955, 17285560, 12925532, 12748240, 9694101, 12862186, 12862187
14727319, 8211733, 9586877, 9548269, 6694396, 7710224, 9337325, 11856395
10157402, 15950541, 19699191, 6402302, 10327190, 10269717, 13015379
10017048, 8546356, 13561750, 8821114, 9770451, 9360157, 8488233, 10132870
4180770, 9532911, 7361418, 6157713, 9184754, 8544696, 17850678, 8277300
13343467, 16382448, 13791364, 12419392, 10208905, 20236416, 20236417
20236418, 20236419, 7450366, 8970313, 6690853, 6011045, 10162036, 10248542
9469117, 13359623, 9952270, 13343471, 9842573, 17381899, 12710774
20558005, 10324526, 9322219, 8636407, 12828105, 19289642, 13736501
9824435, 13736502, 18681879, 13736503, 13736504, 13736505, 13736506
9032322, 13736507, 14035825, 19769505, 11858315, 14040433, 13916709
12827745, 14038805, 19567242, 16721594, 13923855, 19567243, 8528171
9072105, 19567244, 11737047


OPatch succeeded.
我们的补丁升级是成功的
接下来获取主库的最近有效全备,在主库生成备库的standby controlfile
alter database create standby controlfile as '/tmp/std.ctl'
注意主库必须的force logging 模式
通过主库的spfile生成可编辑的文本pfile,编写standby pfile,然后生成standby spfile
拷贝主库的orapwd+sid文件到备库编写sid名称,保证主从的账号密码一致
备库启动到nomount 状态,拷贝std.ctl到spfile的中的控制文件的位置
rman 备份集catalog startwith ,注册备份集
进行restore ,recover
备库添加standby logfile日志组,默认比主库多一组
SQL*Plus: Release 10.2.0.5.0 - Production on Mon May 25 10:59:48 2020

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database add standby logfile group 4 ('/u01/app/oracle/oradata/devdbdg1/stdredo4') size 50M;

Database altered.

SQL> alter database add standby logfile group 5 ('/u01/app/oracle/oradata/devdbdg1/stdredo5') size 50M;
alter database add standby logfile group 6 ('/u01/app/oracle/oradata/devdbdg1/stdredo6') size 50M;

Database altered.

SQL>
Database altered.

SQL> alter database add standby logfile group 7 ('/u01/app/oracle/oradata/devdbdg1/stdredo7') size 50M;

Database altered.

然后开始开启mrp进程,看主库数据库是否能同步
C机器执行
db03-> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Wed May 27 13:43:47 2020

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> recover managed standby database disconnect from session;
Media recovery complete.
SQL>
SQL> recover managed standby database cancel;
Media recovery complete.
SQL>
SQL> alter database open;

Database altered.

DG能打开说明我们的DG容灾功能是完善的,辅助查看验证是根据主从服务器的日志来查看,通过主库的lns进程和从库的rfs进程来辅助判断主从是否同步
如果lns发现没有激活,可以手动激活
SQL> alter system set log_archive_dest_state_2=enable scope=both;

System altered.
主库内容
LNS1 started with pid=18, OS id=3440
Wed May 27 14:15:01 CST 2020
Thread 1 advanced to log sequence 52 (LGWR switch)
Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/devdb/redo01.log
从库内容
RFS[3]: Assigned to RFS process 3472
RFS[3]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/u01/app/oracle/oradata/devdb/stdredo4'
Wed May 27 14:15:05 CST 2020
Media Recovery Log /u01/arch/1_51_1041355484.dbf
Media Recovery Waiting for thread 1 sequence 52 (in transit)
这个是比较直接的,说明从库启用了mrp进程

验证DG是否正常一个是rfs一个数据库能打开到open模式
下面开始本次进行A机器和C机器的切换
A机器执行:
SQL> set linesize 1000
SQL> select dbid,name,current_scn,protection_mode,database_role,force_logging,open_mode,switchover_status from gv$database;

  DBID NAME      CURRENT_SCN PROTECTION_MODE      DATABASE_ROLE    FOR OPEN_MODE  SWITCHOVER_STATUS

946085465 DEVDB 464878 MAXIMUM PERFORMANCE PRIMARY YES READ WRITE SESSIONS ACTIVE

SQL>
SQL> alter system switch logfile;

System altered.

SQL> alter database commit to switchover to physical standby with session shutdown;

Database altered.

SQL> select open_mode from v$database;
select open_mode from v$database
*
ERROR at line 1:
ORA-01507: database not mounted

SQL> shutdown immediate;
ORA-01507: database not mounted

ORACLE instance shut down.

从下面日志可以看出,这是主库其实大部分进程已经关闭了,接下来我们手动关闭数据库,安装psu

相关日志如下:
alter database commit to switchover to physical standby with session shutdown
Wed May 27 14:02:23 CST 2020
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY (devdb)
Wed May 27 14:02:23 CST 2020
Thread 1 advanced to log sequence 47 (LGWR switch)
Current log# 2 seq# 47 mem# 0: /u01/app/oracle/oradata/devdb/redo02.log
Wed May 27 14:02:24 CST 2020
Waiting for all non-current ORLs to be archived...
Wed May 27 14:02:24 CST 2020
Waiting for the ORL for thread 1 sequence 46 to be archived...
Wed May 27 14:02:34 CST 2020
ORL for thread 1 sequence 46 has been archived...
Wed May 27 14:02:34 CST 2020
All non-current ORLs have been archived.
Wed May 27 14:02:34 CST 2020
Waiting for all FAL entries to be archived...
Wed May 27 14:02:34 CST 2020
All FAL entries have been archived.
Wed May 27 14:02:34 CST 2020
Waiting for potential switchover target to become synchronized...
Wed May 27 14:02:34 CST 2020
Active, synchronized switchover target has been identified
Wed May 27 14:02:34 CST 2020
Thread 1 advanced to log sequence 48 (LGWR switch)
Current log# 3 seq# 48 mem# 0: /u01/app/oracle/oradata/devdb/redo03.log
Wed May 27 14:02:34 CST 2020
ARCH: Standby redo logfile selected for thread 1 sequence 47 for destination LOG_ARCHIVE_DEST_3
ARCH: Standby redo logfile selected for thread 1 sequence 47 for destination LOG_ARCHIVE_DEST_2
Wed May 27 14:02:34 CST 2020
Stopping background process CJQ0
Wed May 27 14:02:34 CST 2020
SMON: disabling tx recovery
Wed May 27 14:02:34 CST 2020
Stopping background process MMNL
Wed May 27 14:02:35 CST 2020
Stopping background process MMON
Wed May 27 14:02:36 CST 2020
Stopping background process QMNC
Wed May 27 14:02:38 CST 2020
Job queue slave processes stopped
Waiting for dispatcher 'D000' to shutdown
All dispatchers and shared servers shutdown
Active process 3229 user 'oracle' program 'oracle@db01'
Active process 3209 user 'oracle' program 'oracle@db01'
CLOSE: waiting for server sessions to complete.
CLOSE: all sessions shutdown successfully.
Wed May 27 14:02:42 CST 2020
SMON: disabling cache recovery
Wed May 27 14:02:42 CST 2020
Shutting down archive processes
Archiving is disabled
Wed May 27 14:02:47 CST 2020
ARCH shutting down
ARC1: Archival stopped
Wed May 27 14:02:52 CST 2020
ARCH shutting down
ARC0: Archival stopped
Wed May 27 14:02:53 CST 2020
Thread 1 closed at log sequence 48
Successful close of redo thread 1
Wed May 27 14:02:53 CST 2020
ARCH: Noswitch archival of thread 1, sequence 48
ARCH: End-Of-Redo Branch archival of thread 1 sequence 48
ARCH: Standby redo logfile selected for thread 1 sequence 48 for destination LOG_ARCHIVE_DEST_3
ARCH: Archiving is disabled due to current logfile archival
Clearing standby activation ID 946092889 (0x38643b59)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Archivelog for thread 1 sequence 48 required for standby recovery
Switchover: Primary controlfile converted to standby controlfile succesfully.

C机器执行,C机器变成主库:

SQL> alter database commit to switchover to primary;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter system switch logfile;

System altered.
SQL> select open_mode from v$database;

OPEN_MODE

READ WRITE

结论:在同一个大版本的不同psu之间数据库可以进行DG切换,同一个大版本的数据库软件(字典未更新)同步没问题
C机器进行字典表升级
db03-> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Wed May 27 14:42:06 2020

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @?/rdbms/admin/catbundle.sql psu apply
这个时间段大致为10分钟左右
检查字典表错误
SQL> @?/rdbms/admin/utlrp.sql
select * from dba_registry_history 可以看到如下记录
27-5月 -20 02.37.41.727217 下午 jvmpsu.sql SERVER 10.2.0.5.2OJVMBP 0 RAN jvmpsu.sql
27-5月 -20 02.37.55.591871 下午 jvmpsu.sql SERVER 10.2.0.5.2OJVMBP 0 RAN jvmpsu.sql
27-5月 -20 02.40.10.293275 下午 APPLY SERVER 10.2.0.5 19 PSU PSU 10.2.0.5.19
A机器升级opatch,psu需要关闭,和C机器一样升级即可
A机器升级完成之后,mrp进程进行应用,发现过了一段时间C机器的字典表升级A机器也应用了

select * from dba_registry_history

27-5月 -20 02.37.41.727217 下午 jvmpsu.sql SERVER 10.2.0.5.2OJVMBP 0 RAN jvmpsu.sql
27-5月 -20 02.37.55.591871 下午 jvmpsu.sql SERVER 10.2.0.5.2OJVMBP 0 RAN jvmpsu.sql
27-5月 -20 02.40.10.293275 下午 APPLY SERVER 10.2.0.5 19 PSU PSU 10.2.0.5.19

到此主从数据库的切换完成

B机器也是一样的套路,只不过B机器原来为A机器的DG,现在变成C机器的DG,需要修改tnsname.ora文件和spfile文件

总结:Oracle同一个大版本的数据库之间的DG是没有问题的,PSU升级过程中,主备库都需要数据库软件进行升级,但是字典表需要在主库执行,备库无需执行

相关补丁包升级的链接:
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=159867243924612&parent=EXTERNAL_SEARCH&sourceId=REFERENCE&id=1922396.1&_afrWindowMode=0&_adf.ctrl-state=ze724xlyf_158#aref_section313

附上A机器的pfile文件:
devdb.db_cache_size=796917760
devdb.
java_pool_size=4194304
devdb.large_pool_size=4194304
devdb.
shared_pool_size=251658240
devdb.streams_pool_size=0
.audit_file_dest='/u01/app/oracle/admin/devdb/adump'
.background_dump_dest='/u01/app/oracle/admin/devdb/bdump'
.compatible='10.2.0.5.0'
.control_files='/u01/app/oracle/oradata/devdb/control01.ctl','/u01/app/oracle/oradata/devdb/control02.ctl','/u01/app/oracle/oradata/devdb/control03.ctl'
.core_dump_dest='/u01/app/oracle/admin/devdb/cdump'
.db_block_size=8192
.db_domain=''
.db_file_multiblock_read_count=16
.db_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1'
.db_name='devdb'
.dispatchers='(PROTOCOL=TCP) (SERVICE=devdbXDB)'
.fal_client='devdbpri'
.fal_server='devdbnew'
.job_queue_processes=10
.log_archive_config='dg_config=(devdb,devdbdg1,devdbnew)'
.log_archive_dest_1='location=/u01/arch valid_for=(all_logfiles,all_roles) db_unique_name=devdb'
.log_archive_dest_2='service=devdbdg1 reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdbdg1'
.log_archive_dest_3='service=devdbnew reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdbnew'
.log_archive_dest_state_2='ENABLE'
.log_archive_dest_state_3='ENABLE'
.log_archiveformat='%t%s_%r.dbf'
.log_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1'
.open_cursors=300
.pga_aggregate_target=353370112
.processes=150
.remote_login_passwordfile='EXCLUSIVE'
.sga_target=1062207488
.standby_file_management='auto'
.undo_management='AUTO'
.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/devdb/udump'
B机器的pfile文件
devdbdg1.
db_cache_size=796917760
devdbdg1.java_pool_size=4194304
devdbdg1.
large_pool_size=4194304
devdbdg1.shared_pool_size=251658240
devdbdg1.
streams_pool_size=0
.audit_file_dest='/u01/app/oracle/admin/devdbdg1/adump'
.background_dump_dest='/u01/app/oracle/admin/devdbdg1/bdump'
.compatible='10.2.0.5.0'
.control_files='/u01/app/oracle/oradata/devdbdg1/control01.ctl','/u01/app/oracle/oradata/devdbdg1/control02.ctl','/u01/app/oracle/oradata/devdbdg1/control03.
ctl'
.core_dump_dest='/u01/app/oracle/admin/devdbdg1/cdump'
.db_block_size=8192
.db_domain=''
.db_file_multiblock_read_count=16
.db_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1','/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdb'
.db_name='devdb'
.db_unique_name='devdbdg1'
.dispatchers='(PROTOCOL=TCP) (SERVICE=devdbdg1XDB)'
.fal_client='devdbdg1'
.fal_server='devdb,devdbpri'
.job_queue_processes=10
.log_archive_config='dg_config=(devdb,devdbdg1,devdbnew)'
.log_archive_dest_1='location=/u01/arch valid_for=(all_logfiles,all_roles) db_unique_name=devdbdg1'
.log_archive_dest_2='service=devdbpri reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdb'
.log_archive_dest_3='service=devdbnew reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdbnew'
.log_archive_dest_state_1='enable'
.log_archive_dest_state_2='enable'
.log_archive_dest_state_3='enable'
.log_archiveformat='%t%s_%r.dbf'
.log_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1','/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdb'
.open_cursors=300
.pga_aggregate_target=353370112
.processes=150
.remote_login_passwordfile='EXCLUSIVE'
.sga_target=1062207488
.standby_file_management='auto'
.undo_management='AUTO'
.undo_tablespace='UNDOTBS1'
.user_dump_dest='/u01/app/oracle/admin/devdbdg1/udump'
C机器的pfile文件
devdbnew.db_cache_size=763363328
devdbnew.
java_pool_size=37748736
devdbnew.large_pool_size=4194304
devdbnew.
shared_pool_size=251658240
devdbnew.__streams_pool_size=0
.audit_file_dest='/u01/app/oracle/admin/devdbnew/adump'
.background_dump_dest='/u01/app/oracle/admin/devdbnew/bdump'
.compatible='10.2.0.5.0'
.control_files='/u01/app/oracle/oradata/devdb/control01.ctl','/u01/app/oracle/oradata/devdb/control02.ctl','/u01/app/oracle/oradata/devdb/control03.ctl'
.core_dump_dest='/u01/app/oracle/admin/devdbnew/cdump'
.db_block_size=8192
.db_domain=''
.db_file_multiblock_read_count=16
.db_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdb' '/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1'
.db_name='devdb'
.db_unique_name='devdbnew'
.dispatchers='(PROTOCOL=TCP) (SERVICE=devdbnewXDB)'
.fal_client='devdbnew'
.fal_server='devdbpri'
.job_queue_processes=10
.log_archive_config='dg_config=(devdb,devdbdg1,devdbnew)'
.log_archive_dest_1='location=/u01/arch valid_for=(all_logfiles,all_roles) db_unique_name=devdbnew'
.log_archive_dest_2='service=devdbpri reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdb'
.log_archive_dest_3='service=devdbdg1 reopen=120 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=devdbdg1'
.log_archive_dest_state_1='enable'
.log_archive_dest_state_2='ENABLE'
.log_archive_dest_state_3='enable'
.log_archiveformat='%t%s_%r.dbf'
.log_file_name_convert='/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdb' '/u01/app/oracle/oradata/devdb','/u01/app/oracle/oradata/devdbdg1'
.open_cursors=300
.pga_aggregate_target=353370112
.processes=150
.remote_login_passwordfile='EXCLUSIVE'
.sga_target=1062207488
.standby_file_management='auto'
.undo_management='AUTO'
.undo_tablespace='UNDOTBS1'
.user_dump_dest='/u01/app/oracle/admin/devdbnew/udump'