实战Oracle RAC迁移项目第2篇：RAC-RAC主备切换/IP更换/DG恢复

徐sir（徐慧阳）

已于 2024-02-26 08:50:22 修改

阅读量1k

点赞数 12

分类专栏： Oracle数据库记录文章标签：数据库 oracle

于 2023-12-31 11:48:53 首次发布

本文链接：https://blog.csdn.net/xxddxhyz/article/details/135314589

版权

Oracle数据库记录专栏收录该内容

39 篇文章 4 订阅

订阅专栏

上一篇文章里在原有的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 rac2

1.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          0

17 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_name=orcl）的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 open


Database 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_name=primary
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_name=orcl
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_name=primary的RAC集群进行断网，修改db_uniquer_name=orcl这套RAC的IP地址

3.2、修改新RAC主库的IP地址

接下来对db_uniquer_name=orcl这套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

[root@rac1 ~]# /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
[root@rac1 ~]# /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 local

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string       (ADDRESS=(PROTOCOL=TCP)(HOST=
                                                 192.168.56.12)(PORT=1521))
log_archive_local_first              boolean     TRUE
parallel_force_local                 boolean     FALSE

SQL> show parameter local

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string       (ADDRESS=(PROTOCOL=TCP)(HOST=
                                                 192.168.56.13)(PORT=1521))
log_archive_local_first              boolean     TRUE
parallel_force_local                 boolean     FALSE

---修改语句
alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.12)(PORT=1521))))' scope=both sid='orcl1';
alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.13)(PORT=1521))))' scope=both sid='orcl2';

检查无误后，找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_config='DG_CONFIG=(orcl,orcldg)'  scope=both;
alter system set log_archive_dest_2='service=orcl  ASYNC NOAFFIRM valid_for=(online_logfiles,primary_role) db_unique_name=orcl'  scope=both;
alter system set fal_client=orcldg scope=both;
alter system set fal_server=orcl scope=both;

在db_unique_name=orcl的新主库RAC环境，修改如下参数

alter system set log_archive_config='DG_CONFIG=(orcl,orcldg,primary)'  scope=both;
alter system set log_archive_dest_3='service=orcldg  ASYNC NOAFFIRM valid_for=(online_logfiles,primary_role) db_unique_name=orcldg'  scope=both;

执行之后，单机备库恢复接收日志，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 0
  Mem# 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 0
  Mem# 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_name=primary
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_name=orcl
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_name=primary这套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

[root@rac1 ~]# /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

[root@rac1 ~]# /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=(PROTOCOL=TCP)(HOST=192.168.56.32)(PORT=1521))))' scope=both sid='orcl1';
alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.33)(PORT=1521))))' scope=both sid='orcl2';

6、恢复RAC-RAC的DG环境

修改db_uniquer_name=primary这套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_config='DG_CONFIG=(orcl,primary)'  scope=both;
alter system set log_archive_dest_3='' scope=both;
alter system set log_archive_dest_2='service=racdg  ASYNC NOAFFIRM valid_for=(online_logfiles,primary_role) db_unique_name=orcl'  scope=both;
alter system set fal_client=primary scope=both;
alter system set fal_server=racdg  scope=both;

启动ADG

alter database recover managed standby database using current logfile disconnect from session;

启动后发现接收不到来自db_unique_name=orcl的日志，于是去db_unique_name=orcl的RAC里禁用启用了下归档路径

alter system set log_archive_dest_2='' scope=both;
alter system set log_archive_dest_2='service=primary  ASYNC NOAFFIRM valid_for=(online_logfiles,primary_role) db_unique_name=primary'  scope=both;

然后再检查，恢复通讯

7、总结

至步，其实己经完成整个替换项目的工作，整体来说替换工作需要细心、操作前做好准备工作，捋清工作流程。

下一篇进行一个收尾工作，把备库RAC的存储换了

这样就是有2套备库就都有各自的存储，相当于共有2份数据备份

同时RAC备库不使用和产存储空间，可以把一些查询放到RAC备库来进行，不占用生产存储的资源。上一篇文章里在原有的RAC-单实例的环境里又增加了新的RAC做为备库。

也欢迎关注我的公众号【徐sir的IT之路】，一起学习！

————————————————————————————
公众号：徐sir的IT之路
CSDN ：徐sir（徐慧阳）_数据库记录,系统集成-CSDN博客
墨天轮：徐sir的个人主页 - 墨天轮
PGFANS：PGFans问答社区:全球唯一的PostgreSQL中文技术交流社区

————————————————————————————