需求：最近公司进行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_archive_format='%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_archive_format='%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_archive_format='%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'
