站点故障转移和恢复

如果您的基础设施发生计划外事件，导致主站点不可用且在将对业务产生负面影响的一段时间内完全无法访问，则需要进行站点故障转移。在此方案中，备用数据库承担主角色。

主要站点可能由于各种原因而变得不可用，包括但不限于以下各项：

可能导致主数据库实例无法启动的问题，例如介质发生故障或严重损坏，或者操作系统或固件升级有缺陷
OCI 区域基础设施出现完全断电或冷却系统故障等基础设施故障
完全网络故障
自然灾害，如地震、火灾和洪水

虽然计划外事件很少见，但它们可以而且确实会发生。

执行站点故障转移

由于真正的故障转移具有破坏性，并可能导致少量数据丢失，因此请在 TEST 环境中测试您的站点故障转移。

以下示例将测试环境中的名称用于阿什本的主数据库 (CDBHCM_iad1dx) 和凤凰城的备用数据库 (CDBHCM_phx5s)。

强制停止主数据库上的所有数据库 Oracle Real Application Clusters (Oracle RAC) 实例。

注意：
请勿在生产环境中执行此测试。
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
从这一点上，我们的主要假设（模拟）是完全不可用。我们将使我们的次区域成为我们的新主要站点。
以下步骤使用我们的测试实现，所有步骤都在次级站点（新主站点）执行。

在辅助站点上，登录到任一 Oracle Exadata Database Service on Dedicated Infrastructure domUs，成为 oracle OS 用户，然后调用 Data Guard Broker 命令行界面。

节点：一个 Oracle Exadata Database Service on Dedicated Infrastructure domU
用户：oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

请注意该错误。

使用 Oracle Data Guard Broker 命令行接口执行故障转移。
- 节点：一个 Oracle Exadata Database Service on Dedicated Infrastructure domU（位于辅助站点）
- 用户：oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
如果主中间层（包括共享文件系统）仍然完好无损，则手动执行从发生故障的主站点到 DR 站点的“强制”rsync。

应用程序和 Web 层可能仍正常工作，但应用程序和进程调度程序进程在尝试连接到失败的数据库时将开始失败。这将导致 rsync 脚本停止执行 rsync。
- 节点：一个中间层，发生故障的主站点
- 用户：psadm2
1. 执行强制 rsync。脚本目录中提供了示例 rsync_psft.sh 脚本。
  如果禁用了 rsync 脚本，则 -f 参数将提示继续强制执行 rsync。强制 rsync 不会查询数据库以确定站点的角色，然后将执行请求的 rsync。
  
  注意：
  只有在站点故障转移期间强制执行最终刷新时才应执行此操作。将记录使用 FORCE 选项的情况。
```
$ rsync_psft.sh path to file system/parameter file -f
```
  例如：
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. 监视 rsync 进程日志以验证进程是否成功完成。
如果站点故障已完成，并且无法运行最终的 rsync 进程，则通过运行 disable_psft_rsync.sh 脚本在新主服务器上禁用 rsync。
- 节点：一个中间层，新的主站点
- 用户：psadm2
```
disable_psft_rsync.sh
```
如果在配置主数据库服务器和备用数据库服务器时配置了活动数据卫士支持，请确保在新主数据库上启动了 PeopleSoft (PSQUERY) 的活动数据卫士服务。
- 节点：一个 Oracle Exadata Database Service on Dedicated Infrastructure domU（位于辅助站点）
- 用户：oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
此服务应在所有 Oracle Real Application Clusters (Oracle RAC) 实例上运行。

注意：
必须在启动进程调度程序之前启动此服务。否则，进程调度器将在启动时失败。
验证基于角色的数据库服务是否在新主数据库上正常运行。
- 站点：站点 2
- 节点：所有 Oracle Exadata Database Service on Dedicated Infrastructure domUs
- 用户：oracle
例如，对托管 PeopleSoft Oracle RAC 数据库实例的每个 domU 发出以下命令：
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
此服务应在所有 Oracle RAC 实例上运行。

启动应用服务器和进程调度器域。

站点：站点 2
节点：应用程序和进程调度程序服务器计算实例
用户：psadm2

登录托管 PeopleSoft 应用服务器和进程调度程序的计算实例，成为 psadm2。
使用 GitHub 中 Wrapper 目录中的 startPSFTAPP.sh 脚本。
```
$ startPSFTAPP.sh
```

监视启动。

可以使用来自 PeopleSoft 应用程序和进程调度器域的查询。

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

如果您没有如步骤 5 中所述的完全站点故障，请转到下一步。如果站点出现完全故障，则必须再次运行 disable_psft_rsync.sh 脚本，因为 startPSTAPP.sh 脚本将启用 rsync。
注意：

在主站点丢失或无法访问的实际失败事件中，您需要对范围和影响进行评估。请考虑以下几个项目：
- 数据库数据可能丢失
- 缺少文件系统对象（报告、日志、入站和出站文件等）
根据中断情况，您可能无法恢复在原始主数据库上提交的每笔交易。如果可能，请用户验证他们处理的最后一次事务处理。

当对原始主数据库的访问停止时，可能会丢失写入或传输的输出中的文件系统构件。使用数据库中的报告日志记录来确定在停机时间附近创建的文件系统对象，然后确定需要对缺少的文件或不完整的文件执行哪些操作（按大小写）。
启动 Web 服务。
- 站点：站点 2
- 节点：所有 PeopleSoft Internet 体系结构 (Internet Architecture，PIA) Web 服务器计算实例
- 用户：psadm2
如果配置了 Coherence*Web，则首先在托管 PIA Web 服务器的所有计算实例上启动高速缓存集群，然后启动 PIA Web 服务器。在此示例中，使用一个脚本以正确的顺序启动这两个脚本。
1. 登录到 PIA Web 服务器并成为 psadm2。
2. 使用 startPSFTAPP.sh 中的脚本，启动 Web 服务器。
```
$ startPSFTWEB.sh
```
检查负载平衡器。
- 地点：地点 2 区域
- 节点： OCI 控制台
- 用户：租户管理员
1. 登录到 OCI 控制台并将区域更改为新的主数据库。
2. 从主菜单中选择网络，然后选择负载平衡器。
3. 选择适当的区间。
4. 单击后端集，然后单击后端。
  每个后端都应显示 OK 。每个 PIA Web 服务器启动后可能需要几分钟时间。

将失败的主数据库恢复为新的备用数据库

您需要使用备用数据库来保护您的新生产环境。理想情况下，通过恢复数据库和文件系统，可以将失败的主数据库恢复为新的备用数据库。

将旧主数据库恢复为备用数据库

Oracle Data Guard 将阻止旧主数据库在主站点发生故障后再次可用时打开。启动数据库的任何尝试通常都会失败，并且将消息写入其预警日志，指示需要恢复。如果在失败之前在此数据库上启用了闪回数据库，则可以将旧主数据库恢复为新备用数据库。

执行以下操作以将旧主数据库恢复为当前生产的备用数据库：

登录到托管旧主数据库的 domUs 之一并启动数据库：
```
$ srvctl start database -db CDBHCM_phx5s
```

登录到新的主区域中的 Data Guard 中介命令行界面并显示配置。

请注意以下以粗体显示的 ORA-16661 错误。

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

恢复备用数据库。
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
注意：
恢复失败的数据库并启动有效的备用数据库的过程，可能需要一些时间才能完成。

使用 Data Guard 中介命令行界面检查环境的状态。

例如：

DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)

恢复的数据库现在用作备用数据库，可保护主数据库，并可用于切换和故障转移。

如果在配置主数据库服务器和备用数据库服务器时配置了活动数据卫士支持，则可以将 PeopleSoft (PSQUERY) 的活动数据卫士服务从主数据库重新定位到备用数据库。

将旧的主要中间层恢复为备用

根据故障转移事件恢复旧的主中间层。

如果在发生数据库故障转移事件时旧的主中间层服务器仍然可用，则您应该在发生故障时完成从发生故障的主站点到备用站点的最终强制 rsync，然后以与执行切换时相同的方式反转 rsync 进程的方向。

应用程序和 Web 层可能仍正常工作，但应用程序和进程调度程序进程在尝试连接到失败的数据库时将开始失败。这将导致 rsync 脚本停止执行 rsync。
1. 如果主中间层（包括共享文件系统）仍然完好无损，则手动执行从失败的主站点到 DR 站点的“强制”rsync。
  如果禁用了 rsync 脚本，则 -f 参数将提示继续强制执行 rsync。强制 rsync 不会查询数据库以确定站点的角色，然后将执行请求的 rsync。
  
  注意：
  只有在站点故障转移期间强制执行最终刷新时才应执行此操作。将记录使用 FORCE 选项。
  
  可以在脚本目录 rsync_psft.sh 中以用户 psadm2 的身份使用示例脚本：
```
$ rsync_psft.sh path to file system/parameter file -f
```
  例如：
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. 监视 rsync 进程日志以验证进程是否成功完成。
如果即使对于 rsync，旧的主站点也完全无法访问，则执行以下操作：
1. 使用 disable_psft_rsync.sh 对要复制的所有文件系统禁用新主站点上的 rsync 脚本。
2. 如果以后可以恢复原始中间层上的活动，则重新启用 rsync 脚本并让他们赶上。
如果您需要重建中间层，请按照前面介绍的过程进行操作。