淄博市 网站建设报价,wordpress里的发消息给我,下载网站模板后本地的网站会自动做跳转,wordpress fancyzoom上一篇文章里在原有的RAC-单实例的环境里又增加了新的RAC做为备库。
这一篇里的主要工作就是把RAC-RAC的DG进行主备切换#xff0c;然后对调IP地址#xff0c;再恢复RAC-RAC-单机DG的环境
描述下主要的工作流程如#xff1a; 为了不混淆新旧RAC或是主备RAC的说法#xff…上一篇文章里在原有的RAC-单实例的环境里又增加了新的RAC做为备库。
这一篇里的主要工作就是把RAC-RAC的DG进行主备切换然后对调IP地址再恢复RAC-RAC-单机DG的环境
描述下主要的工作流程如 为了不混淆新旧RAC或是主备RAC的说法下面操作我以db_unique_name区分在哪个数据库集群上操作。
关于DATAGUARD参数不明确的小伙伴可以参考强哥的文章爆肝一万字终于把 Oracle Data Guard 核心参数搞明白了
1、切换前准备工作
1.1关闭RAC主库2节点实例
切换前先把主库关闭1个节点
srvctl stop instance -d orcl -n rac21.2、备库RAC检查状态
SQL set pagesize 200
SQL SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY ;PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CLOSING 2 103 63488 1393
ARCH CLOSING 1 122 65536 108
ARCH CONNECTED 0 0 0 0
ARCH CLOSING 2 102 63488 681
MRP0 APPLYING_LOG 2 104 1252 102400
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 1 123 8415 1
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 2 104 1254 1
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 017 rows selected.1.3、主库RAC检查是否存在GAP
SQL SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
no rows selected
1.4、主库RAC状态检查
这里返回to standby或session active都表示正常
SQL select open_mode,protection_mode,database_role,switchover_status from v$database;OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
-------------------- -------------------- ---------------- --------------------
READ WRITE MAXIMUM PERFORMANCE PRIMARY TO STANDBY
2、进行RAC主备切换
2.1、关闭RAC主库
在主RAC就是db_unique_name为primary的的RAC1节点上进行切换命令
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
执行之后以下是主库RAC日志输出
Wed Dec 20 20:25:13 2023
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 17546] (orcl1)
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Waiting for all FAL entries to be archived...
All FAL entries have been archived.
Waiting for potential Physical Standby switchover target to become synchronized...
Active, synchronized Physical Standby switchover target has been identified
Switchover End-Of-Redo Log thread 1 sequence 124 has been fixed
Switchover: Primary highest seen SCN set to 0x0.0x215734
ARCH: Noswitch archival of thread 1, sequence 124
ARCH: End-Of-Redo Branch archival of thread 1 sequence 124
ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_3
ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARCH: Standby redo logfile selected for thread 1 sequence 124 for destination LOG_ARCHIVE_DEST_3
ARCH: Standby redo logfile selected for thread 1 sequence 124 for destination LOG_ARCHIVE_DEST_2
Archived Log entry 512 added for thread 1 sequence 124 ID 0x63df8a8b dest 1:
ARCH: Archiving is disabled due to current logfile archival
Primary will check for some target standby to have received alls redo
Final check for a synchronized target standby. Check will be made once.
LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target
LOG_ARCHIVE_DEST_3 is a potential Physical Standby switchover target
Active, synchronized target has been identified
Target has also received all redo
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/primary/orcl1/trace/orcl1_ora_17546.trc
Clearing standby activation ID 1675594379 (0x63df8a8b)
The primary database controlfile was created using the
MAXLOGFILES 192 clause.
There is space for up to 188 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;
ALTER DATABASE ADD STANDBY LOGFILE srl5.f SIZE 52428800;
Archivelog for thread 1 sequence 124 required for standby recovery
Switchover: Primary controlfile converted to standby controlfile succesfully.
Switchover: Complete - Database shutdown required
USER (ospid: 17546): terminating the instance
Instance terminated by USER, pid 17546
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
Shutting down instance (abort)
License high water mark 6
Wed Dec 20 20:25:18 2023
Instance shutdown complete然后是RAC备库
---告警日志
Wed Dec 20 20:25:15 2023
RFS[11]: Assigned to RFS process 16067
RFS[11]: Selected log 11 for thread 1 sequence 124 dbid 1613952925 branch 1086172194
Wed Dec 20 20:25:16 2023
Archived Log entry 29 added for thread 1 sequence 124 ID 0x63df8a8b dest 1:
Wed Dec 20 20:25:16 2023
Resetting standby activation ID 1675594379 (0x63df8a8b)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Waiting for thread 1 sequence 125
Wed Dec 20 20:25:17 2023
RFS[12]: Assigned to RFS process 16065
RFS[12]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[1]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[13]: Assigned to RFS process 15826
RFS[13]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[5]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[2]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[10]: Possible network disconnect with primary database
---查看归档
SQL archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination DATA
Oldest online log sequence 123
Next log sequence to archive 0
Current log sequence 124然后是单机备库
---告警日志
Wed Dec 20 20:25:15 2023
RFS[15]: Assigned to RFS process 29450
RFS[15]: Selected log 11 for thread 1 sequence 124 dbid 1613952925 branch 1086172194
Wed Dec 20 20:25:16 2023
Archived Log entry 77 added for thread 1 sequence 124 ID 0x63df8a8b dest 1:
Wed Dec 20 20:25:16 2023
Resetting standby activation ID 1675594379 (0x63df8a8b)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Waiting for thread 1 sequence 125
Wed Dec 20 20:25:17 2023
RFS[16]: Assigned to RFS process 29447
RFS[16]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[13]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[12]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[14]: Possible network disconnect with primary database
Wed Dec 20 20:25:17 2023
RFS[10]: Possible network disconnect with primary database
---查看归档
SQL archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/oradata/orcldg/archivelog
Oldest online log sequence 123
Next log sequence to archive 0
Current log sequence 124
2.2、在RAC备库上执行切换
在RAC备库db_unique_nameorcl的RAC1节点上执行
alter database commit to switchover toprimary with session shutdown;
---执行后查看alert显示
alter database commit to switchover to primary with session shutdown
ALTER DATABASE SWITCHOVER TO PRIMARY (orcl1)
Maximum wait for role transition is 15 minutes.
Switchover: Media recovery is still active
Role Change: Canceling MRP - no more redo to apply
Wed Dec 20 20:45:40 2023
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_pr00_5121.trc:
ORA-16037: user requested cancel of managed recovery operation
Wed Dec 20 20:45:40 2023
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Wed Dec 20 20:45:41 2023
MRP0: Background Media Recovery process shutdown (orcl1)
Role Change: Canceled MRP
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Wed Dec 20 20:45:42 2023
SMON: disabling cache recovery
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_27390.trc
SwitchOver after complete recovery through change 2185012
Online log DATA/orcl/onlinelog/group_1.257.1156020473: Thread 1 Group 1 was previously cleared
Online log DATA/orcl/onlinelog/group_1.256.1156020475: Thread 1 Group 1 was previously cleared
Online log DATA/orcl/onlinelog/group_2.260.1156020477: Thread 1 Group 2 was previously cleared
Online log DATA/orcl/onlinelog/group_2.261.1156020479: Thread 1 Group 2 was previously cleared
Online log DATA/orcl/onlinelog/group_3.274.1156020481: Thread 2 Group 3 was previously cleared
Online log DATA/orcl/onlinelog/group_3.275.1156020483: Thread 2 Group 3 was previously cleared
Online log DATA/orcl/onlinelog/group_4.270.1156020485: Thread 2 Group 4 was previously cleared
Online log DATA/orcl/onlinelog/group_4.271.1156020487: Thread 2 Group 4 was previously cleared
Standby became primary SCN: 2185010
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
Switchover: Complete - Database mounted as primary
Completed: alter database commit to switchover to primary with session shutdown
--启动备库RAC为主库
SQL SHUTDOWN IMMEDIATE;
ORA-01109: database not openDatabase dismounted.
SQL startup;
ORACLE instance started.Total System Global Area 801701888 bytes
Fixed Size 2257520 bytes
Variable Size 339742096 bytes
Database Buffers 452984832 bytes
Redo Buffers 6717440 bytes
Database mounted.
Database opened.
3、修新RAC主库的IP地址
原始HOSTS文件
----db_unique_nameprimary
192.168.56.10 rac1
192.168.56.11 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.12 rac1-vip
192.168.56.13 rac2-vip
192.168.56.14 rac-scan
----db_unique_nameorcl
192.168.56.30 rac1
192.168.56.31 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.32 rac1-vip
192.168.56.33 rac2-vip
192.168.56.20 rac-scan
3.1、停止两套RAC的CRS服务
在四台RAC主机上使用root用户分别执行
/g01/app/11.2.0/grid/bin/crsctl stop crs
然后先对db_unique_nameprimary的RAC集群进行断网修改db_uniquer_nameorcl这套RAC的IP地址
3.2、修改新RAC主库的IP地址
接下来对db_uniquer_nameorcl这套RAC进行操作
先备份hosts文件
cp /etc/hosts /etc/hosts.bak
然后修改hosts文件新增如下原有的RAC相关全部注释掉
#########new-address##############3
192.168.56.10 rac1
192.168.56.11 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.12 rac1-vip
192.168.56.13 rac2-vip
192.168.56.14 rac-scan
然后分别修改两台主机的IP地址从原来的192.168.56.30、31修改为192.168.56.10、11这个操作我就不描述了修改网卡IP即可
修改完成后连接新的IP地址192.168.56.10、11之后分别在2个节点启动crs
/g01/app/11.2.0/grid/bin/crsctl start crs
起动之后检查VIP己经自动更换SCAN没有更换还是192.168.56.20
[rootrac1 ~]# /g01/app/11.2.0/grid/bin/srvctl config nodeapps -a
Network exists: 1/192.168.56.0/255.255.255.0/eth0, type static
VIP exists: /rac1-vip/192.168.56.12/192.168.56.0/255.255.255.0/eth0, hosting node rac1
VIP exists: /rac2-vip/192.168.56.13/192.168.56.0/255.255.255.0/eth0, hosting node rac2
[rootrac1 ~]# /g01/app/11.2.0/grid/bin/srvctl config scan
SCAN name: rac-scan, Network: 1/192.168.56.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /rac-scan/192.168.56.20
这一步修改SCAN的地址最后一条语句返回修改结果
/g01/app/11.2.0/grid/bin/srvctl stop scan_listener
/g01/app/11.2.0/grid/bin/srvctl stop scan
/g01/app/11.2.0/grid/bin/srvctl modify scan -n 192.168.56.14
/g01/app/11.2.0/grid/bin/srvctl start scan_listener
/g01/app/11.2.0/grid/bin/srvctl config scan
--返回的结果
SCAN name: 192.168.56.14, Network: 1/192.168.56.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /192.168.56.14/192.168.56.14
去两个数据库实例里检查local_listener我这里检查结果是正确的写的都是新的VIP如果不正确修改一下
---检查结果
SQL show parameter localNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string (ADDRESS(PROTOCOLTCP)(HOST192.168.56.12)(PORT1521))
log_archive_local_first boolean TRUE
parallel_force_local boolean FALSESQL show parameter localNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string (ADDRESS(PROTOCOLTCP)(HOST192.168.56.13)(PORT1521))
log_archive_local_first boolean TRUE
parallel_force_local boolean FALSE---修改语句
alter system set local_listener(DESCRIPTION(ADDRESS_LIST(ADDRESS(PROTOCOLTCP)(HOST192.168.56.12)(PORT1521)))) scopeboth sidorcl1;
alter system set local_listener(DESCRIPTION(ADDRESS_LIST(ADDRESS(PROTOCOLTCP)(HOST192.168.56.13)(PORT1521)))) scopeboth sidorcl2;
检查无误后找1出主机连接一下VIP、SCAN分别进行测试没问题那么IP修改成功。
接下来修改这套RAC里的tnsnames.ora文件两个节点都要改 RACDG (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.11)(PORT 1521))(ADDRESS (PROTOCOL TCP)(HOST 192.168.56.12)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))PRIMARY (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.32)(PORT 1521))(ADDRESS (PROTOCOL TCP)(HOST 192.168.56.33)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))
ORCLDG (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.99)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))4、恢复RAC-单机DG环境
修改备库192.168.56.99单机DG的tnsname.ora增加新RAC主库的监听
ORCL (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.12)(PORT 1521))(ADDRESS (PROTOCOL TCP)(HOST 192.168.56.13)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))修改单机DG参数
alter system set log_archive_configDG_CONFIG(orcl,orcldg) scopeboth;
alter system set log_archive_dest_2serviceorcl ASYNC NOAFFIRM valid_for(online_logfiles,primary_role) db_unique_nameorcl scopeboth;
alter system set fal_clientorcldg scopeboth;
alter system set fal_serverorcl scopeboth;
在db_unique_nameorcl的新主库RAC环境修改如下参数
alter system set log_archive_configDG_CONFIG(orcl,orcldg,primary) scopeboth;
alter system set log_archive_dest_3serviceorcldg ASYNC NOAFFIRM valid_for(online_logfiles,primary_role) db_unique_nameorcldg scopeboth;
执行之后单机备库恢复接收日志Fetching gap sequence in thread 1, gap sequence 125-129继续接收日志同步
---查看告警日志
Wed Dec 20 21:58:07 2023
RFS[17]: Assigned to RFS process 30656
RFS[17]: Selected log 11 for thread 1 sequence 130 dbid 1613952925 branch 1086172194
Wed Dec 20 21:58:07 2023
Archived Log entry 78 added for thread 1 sequence 130 ID 0x645e171b dest 1:
Wed Dec 20 21:58:08 2023
Fetching gap sequence in thread 1, gap sequence 125-129
Wed Dec 20 21:58:08 2023
RFS[18]: Assigned to RFS process 30658
RFS[18]: Selected log 21 for thread 2 sequence 108 dbid 1613952925 branch 1086172194
RFS[17]: Opened log for thread 1 sequence 126 dbid 1613952925 branch 1086172194
Archived Log entry 79 added for thread 1 sequence 126 rlc 1086172194 ID 0x645e171b dest 3:
Wed Dec 20 21:58:08 2023
Archived Log entry 80 added for thread 2 sequence 108 ID 0x645e171b dest 1:
Wed Dec 20 21:58:08 2023
RFS[19]: Assigned to RFS process 30662
RFS[19]: Opened log for thread 1 sequence 127 dbid 1613952925 branch 1086172194
Wed Dec 20 21:58:08 2023
RFS[20]: Assigned to RFS process 30660
RFS[20]: Opened log for thread 1 sequence 125 dbid 1613952925 branch 1086172194
Archived Log entry 81 added for thread 1 sequence 125 rlc 1086172194 ID 0x645e171b dest 3:
Archived Log entry 82 added for thread 1 sequence 127 rlc 1086172194 ID 0x645e171b dest 3:
RFS[17]: Opened log for thread 1 sequence 128 dbid 1613952925 branch 1086172194
Archived Log entry 83 added for thread 1 sequence 128 rlc 1086172194 ID 0x645e171b dest 3:
RFS[20]: Opened log for thread 1 sequence 129 dbid 1613952925 branch 1086172194
Archived Log entry 84 added for thread 1 sequence 129 rlc 1086172194 ID 0x645e171b dest 3:
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_125_1086172194.dbf
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_126_1086172194.dbf
Wed Dec 20 21:58:09 2023
Primary database is in MAXIMUM PERFORMANCE mode
RFS[21]: Assigned to RFS process 30664
RFS[21]: Selected log 11 for thread 1 sequence 132 dbid 1613952925 branch 1086172194
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_127_1086172194.dbf
Wed Dec 20 21:58:10 2023
RFS[22]: Assigned to RFS process 30666
RFS[22]: Selected log 12 for thread 1 sequence 131 dbid 1613952925 branch 1086172194
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_128_1086172194.dbf
Wed Dec 20 21:58:10 2023
Archived Log entry 85 added for thread 1 sequence 131 ID 0x645e171b dest 1:
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_129_1086172194.dbf
Media Recovery Waiting for thread 2 sequence 106
Fetching gap sequence in thread 2, gap sequence 106-107
RFS[22]: Opened log for thread 2 sequence 106 dbid 1613952925 branch 1086172194
Archived Log entry 86 added for thread 2 sequence 106 rlc 1086172194 ID 0x645e171b dest 3:
Wed Dec 20 21:58:11 2023
RFS[23]: Assigned to RFS process 30668
RFS[23]: Opened log for thread 2 sequence 107 dbid 1613952925 branch 1086172194
Archived Log entry 87 added for thread 2 sequence 107 rlc 1086172194 ID 0x645e171b dest 3:
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/2_106_1086172194.dbf
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/2_107_1086172194.dbf
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/2_108_1086172194.dbf
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_130_1086172194.dbf
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/1_131_1086172194.dbf
Media Recovery Waiting for thread 2 sequence 109
Wed Dec 20 21:58:16 2023
Primary database is in MAXIMUM PERFORMANCE mode
RFS[24]: Assigned to RFS process 30680
RFS[24]: Selected log 21 for thread 2 sequence 110 dbid 1613952925 branch 1086172194
Wed Dec 20 21:58:17 2023
RFS[25]: Assigned to RFS process 30682
RFS[25]: Selected log 22 for thread 2 sequence 109 dbid 1613952925 branch 1086172194
Archived Log entry 88 added for thread 2 sequence 109 ID 0x645e171b dest 1:
Media Recovery Log /u01/app/oracle/oradata/orcldg/archivelog/2_109_1086172194.dbf
Wed Dec 20 21:58:18 2023
Media Recovery Waiting for thread 1 sequence 132 (in transit)
Recovery of Online Redo Log: Thread 1 Group 11 Seq 132 Reading mem 0Mem# 0: /u01/app/oracle/fast_recover_area/ORCLDG/onlinelog/o1_mf_11_lr1wn405_.log
Media Recovery Waiting for thread 2 sequence 110 (in transit)
Recovery of Online Redo Log: Thread 2 Group 21 Seq 110 Reading mem 0Mem# 0: /u01/app/oracle/fast_recover_area/ORCLDG/onlinelog/o1_mf_21_lr1wn5v2_.log在RAC主库端创建个测试表
create table t2 as select * from scott.emp; //COUNT(*) 结果 14行
然后去单机备库检查
SQL select count(*) from t2; //COUNT(*) 结果 14行
至此恢复到单机完成。
5、修改新RAC备库的IP地址
原始HOSTS文件
----db_unique_nameprimary
192.168.56.10 rac1
192.168.56.11 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.12 rac1-vip
192.168.56.13 rac2-vip
192.168.56.14 rac-scan
----db_unique_nameorcl
192.168.56.30 rac1
192.168.56.31 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.32 rac1-vip
192.168.56.33 rac2-vip
192.168.56.20 rac-scan
接下来对db_uniquer_nameprimary这套RAC进行操作
先备份hosts文件
cp /etc/hosts /etc/hosts.bak
然后修改hosts文件新增如下原有的RAC相关全部注释掉
#########new-address##############3
192.168.56.30 rac1
192.168.56.31 rac2
10.10.10.1 rac1-priv
10.10.10.2 rac2-priv
192.168.56.32 rac1-vip
192.168.56.33 rac2-vip
192.168.56.20 rac-scan
然后分别修改两台主机的IP地址从原来的192.168.56.10、11修改为192.168.56.30、31这个操作我就不描述了修改网卡IP即可
修改完成后连接新的IP地址192.168.56.30、31之后分别在2个节点启动crs
/g01/app/11.2.0/grid/bin/crsctl start crs
起动之后检查VIP己经自动更换SCAN没有更换还是192.168.56.14
[rootrac1 ~]# /g01/app/11.2.0/grid/bin/srvctl config nodeapps -a
Network exists: 1/192.168.56.0/255.255.255.0/eth0, type static
VIP exists: /rac1-vip/192.168.56.32/192.168.56.0/255.255.255.0/eth0, hosting node rac1
VIP exists: /rac2-vip/192.168.56.33/192.168.56.0/255.255.255.0/eth0, hosting node rac2[rootrac1 ~]# /g01/app/11.2.0/grid/bin/srvctl config scan
SCAN name: 192.168.56.14, Network: 1/192.168.56.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /192.168.56.14/192.168.56.14
这一步修改SCAN的地址最后一条语句返回修改结果
/g01/app/11.2.0/grid/bin/srvctl stop scan_listener
/g01/app/11.2.0/grid/bin/srvctl stop scan
/g01/app/11.2.0/grid/bin/srvctl modify scan -n 192.168.56.20
/g01/app/11.2.0/grid/bin/srvctl start scan_listener
/g01/app/11.2.0/grid/bin/srvctl config scan
--返回的结果
SCAN name: 192.168.56.20, Network: 1/192.168.56.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /192.168.56.20/192.168.56.20
启动1个实例
srvctl start instance -d orcl -n rac1
去两个数据库实例里检查local_listener我这里检查结果是正确的写的都是新的VIP如果不正确修改一下
alter system set local_listener(DESCRIPTION(ADDRESS_LIST(ADDRESS(PROTOCOLTCP)(HOST192.168.56.32)(PORT1521)))) scopeboth sidorcl1;
alter system set local_listener(DESCRIPTION(ADDRESS_LIST(ADDRESS(PROTOCOLTCP)(HOST192.168.56.33)(PORT1521)))) scopeboth sidorcl2;
6、恢复RAC-RAC的DG环境
修改db_uniquer_nameprimary这套RAC下两个节点的tnsnames.ora文件
PRIMARY (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.32)(PORT 1521))(ADDRESS (PROTOCOL TCP)(HOST 192.168.56.33)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))
RACDG (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.56.12)(PORT 1521))(ADDRESS (PROTOCOL TCP)(HOST 192.168.56.13)(PORT 1521))(CONNECT_DATA (SERVER DEDICATED)(SERVICE_NAME orcl)))修改RAC参数恢复
alter system set log_archive_configDG_CONFIG(orcl,primary) scopeboth;
alter system set log_archive_dest_3 scopeboth;
alter system set log_archive_dest_2serviceracdg ASYNC NOAFFIRM valid_for(online_logfiles,primary_role) db_unique_nameorcl scopeboth;
alter system set fal_clientprimary scopeboth;
alter system set fal_serverracdg scopeboth;
启动ADG
alter database recover managed standby database using current logfile disconnect from session;
启动后发现接收不到来自db_unique_nameorcl的日志于是去db_unique_nameorcl的RAC里禁用启用了下归档路径
alter system set log_archive_dest_2 scopeboth;
alter system set log_archive_dest_2serviceprimary ASYNC NOAFFIRM valid_for(online_logfiles,primary_role) db_unique_nameprimary scopeboth;
然后再检查恢复通讯
7、总结
至步其实己经完成整个替换项目的工作整体来说替换工作需要细心、操作前做好准备工作捋清工作流程。
下一篇进行一个收尾工作把备库RAC的存储换了
这样就是有2套备库就都有各自的存储相当于共有2份数据备份
同时RAC备库不使用和产存储空间可以把一些查询放到RAC备库来进行不占用生产存储的资源。上一篇文章里在原有的RAC-单实例的环境里又增加了新的RAC做为备库。
也欢迎关注我的公众号【徐sir的IT之路】一起学习
———————————————————————————— 公众号徐sir的IT之路 CSDN 徐sir徐慧阳_数据库记录,系统集成-CSDN博客 墨天轮徐sir的个人主页 - 墨天轮 PGFANSPGFans问答社区:全球唯一的PostgreSQL中文技术交流社区
————————————————————————————
