1. 为 Oracle WebLogic Server 配置混合 DR 解决方案
  2. 配置环境

配置环境

在 OCI 中设置辅助系统并将其配置为主内部部署系统的备用系统。

可以使用脚本自动执行某些步骤。这些脚本不会自动执行完整设置，因此您必须完成这些任务，并且可以在参考这些脚本时使用它们。

转到下载代码以获得链接，下载本文档中引用的脚本。

在主数据中心中准备 WebLogic 数据源

可以在灾难恢复拓扑中对 WebLogic 数据源的数据库连接字符串使用多种方法，例如双字符串、不同的连接字符串和 TNS 别名。有关更多详细信息以及不同方法之间的比较，请参阅 Oracle Fusion Middleware Disaster Recovery Guide。我们将使用 TNS 别名，因为它需要一次性设置。使用 TNS 别名意味着每次将 WebLogic 配置复制到辅助配置时不需要更改该配置。在启动 FMW 版本 12.2.1.3 时，支持在 GridLink 数据源中使用 TNS 别名。

TNS 别名在主和辅助中是相同的名称；因此，数据源使用相同的 db 连接字符串。它使用不复制到备用数据库的 tnsnames.ora 文件进行解析，因此每个站点中可以有不同的 tnsnames.ora 内容。您可以将其与 WebLogic 域配置单独放置在不在站点之间复制的文件系统中。或者，鉴于它是配置的一部分，您还可以将其存储在域配置下的文件夹中。在这种情况下，请确保在将域配置从主数据库复制到备用数据库时排除该文件夹。每个站点都将使用每个站点中的相应连接字符串解析 TNS 别名，仅指向本地数据库。例如： 

Connect string in data sources in primary site:
jdbc:oracle:thin:@mypdbservice

The tnsnames.ora file in primary contains:
MYPDBSERVICE =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in secondary: 
MYPDBSERVICE =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)

以下是使用 TNS 别名的优点：

  • 由于在 WebLogic 域 config 中使用相同的 db 连接字符串，因此在将 config 从主数据库复制到备用数据库之后，无需更改 WebLogic 配置。
  • 由于每个站点仅指向本地数据库，因此不存在从中间层到远程数据库的交叉连接风险。

如果您尚未在主 WebLogic Server 系统中使用此方法，请执行以下步骤在数据源中使用 TNS 别名。

  1. 在主中间层主机中创建 tns 文件夹：

    此文件夹必须可由 Oracle 用户读取并置于不在站点之间复制的文件系统中。

    假定 tns 文件夹是配置的一部分，您还可以在所有服务器共享的配置文件夹下创建该文件夹。但在这种情况下，请确保在将域配置从主数据库复制到备用数据库时排除 tns 文件夹，或者在故障转移或切换后在备用系统中更新 tnsnames.ora 以指向辅助数据库。 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. 使用将在数据源中使用的 TNS 别名在目录中创建一个 tnsnames.ora 文件，如示例中所示。
    Oracle 建议在单行中输入字符串。
    MYPDBSERVICE = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= mypdbservice.example.com))
)
  3. 指定指向 tnsnames.ora 文件的目录位置的 oracle.net.tns_admin 属性。使用以下方法之一：

    • 选项 1：将属性设置为数据源连接属性。Oracle 建议使用此方法。

      1. 在数据源配置中指定 oracle.net.tns_admin=tns_directory 属性。

        要在 WebLogic 管理控制台中指定此属性，请转至服务，单击数据源，从列表中选择数据源，单击连接池，然后将其添加到“属性”文本框中。对每个数据源重复此步骤。

        例如：oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. 在 OPSS 安全中指定此属性可将文件 jps-config-jse.xml 和 jps-config.xm 存储在 $ASERVER_HOME/config/fmwconfig 文件夹中。

        要修改这些 jps 文件，请编辑它们并在 jdbc.url 属性后添加 oracle.net.tns_admin 属性。例如， 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        注意：

        此属性适用于指定它的特定文件（数据源，jps 文件）。

    • 选项 2：将属性设置为 java 系统属性。

      1. 指定 -Doracle.net.tns_admin=tns_directory 系统属性，其中 tns_directory 是 tnsnames.ora 文件的目录位置。

        要将其设置为服务器的 java 属性，请编辑以下文件：
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh（此文件不共享。因此，应在所有 SOA 中间层主机中编辑该文件。)

      2. 将以下内容添加到这些文件： 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        注意：

        此属性适用于 Oracle WebLogic Server 中的所有数据源和 jps 文件。在运行某些 WLST 命令和配置向导之前，此方法要求您在环境中设置属性。
        • 在运行 WLST 之前，请在 WLST_PROPERTIES 环境变量中设置属性。
        • 在运行配置向导之前，请将该属性添加到 config_internal.sh 脚本的 JVM_ARGS 环境变量中。
      3. 选项 3：在 jdbc URL 中设置属性。

        在数据源和 jps 文件中指定作为连接字符串的一部分的 tnsnames.ora 文件的位置： 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      注意：

      此属性适用于指定它的特定文件（数据源，jps 文件）。

      可以将此方法用于 JDBC 驱动程序 18.3 及更高版本。这适用于 Fusion Middleware 12.2.1.4（使用 JDBC 驱动程序 19.3）及更高版本。

  4. 通过将连接字符串替换为别名，在数据源定义 URL 中使用别名。
    jdbc:oracle:thin:@mypdbservice
    修改下列文件：
    • 在数据源文件中，位于 $ASERVER_HOME/config/jdbc/
    • 在 jps-config.xml 和 jps-config-jse.xml 文件中，位于 $ASERVER_HOME/config/fmwconfig/ 中
    您可以使用 Oracle WebLogic Server 管理控制台修改数据源，但必须手动编辑 jps-config xml 文件。可以使用 update_dbconnect.sh 脚本在提及的所有文件中执行替换。

    转到下载代码以获得下载脚本的链接。

  5. 重新启动域中的每个 Oracle WebLogic Server 。
    1. 停止主域中的所有 WebLogic 服务器（管理服务器和托管服务器）。
    2. 在主域中启动管理服务器。
    3. 在管理服务器运行时，启动托管服务器。
    4. 验证是否已正确与数据库建立连接。
  6. 其他最佳实践：使用 Oracle Database 12c 或更高版本时，GridLink 数据源中不需要 Oracle Notification Service (ONS) 主机和端口配置值。
    客户端驱动程序会自动从数据库中获取 Oracle 通知服务列表。Oracle 建议使用此功能，而不是在每个数据源的 ONS 配置中提供扫描地址或 Oracle RAC 节点列表。确保已启用 FAN，并且每个数据源中的 ONS nodes 属性为空。
    1. 打开 Oracle WebLogic Server 管理控制台。
    2. 依次转至服务和数据源。选择数据源名称、配置和 ONS 。
    3. 验证 ONS 节点列表是否为空。

配置网络

主要内部部署网络和辅助 Oracle Cloud Infrastructure (OCI) 网络之间需要连接。Oracle 建议使用 Oracle Cloud Infrastructure FastConnect ，这允许您通过专用高带宽连接直接连接到 OCI 虚拟云网络。您可以根据数据量选择适当的端口速度。您也可以使用站点到站点 VPN，但其带宽更小，延迟、抖动和成本也更低。
  1. 在 OCI 区间中创建 VCN 和子网，如 Determine the Resources Needed on OCI 中所述。配置 Oracle Cloud Infrastructure FastConnect （或站点到站点 VPN）以允许内部部署网络与 VCN 之间进行通信。有关信息，请参见 FastConnect 和 Site-to-Site VPN 。
  2. 在 OCI 和内部部署防火墙中创建所需的网络规则，并配置源、目标、协议和端口，如下表所示。

    假定在每个子网内启用了所有通信。

    有关网络安全规则的信息，请参阅 OCI 文档。

    源 目标 协议和端口 用途
    内部部署网络 OCI 中间层子网 SSH（端口 22） 设置和生命周期
    内部部署网络 OCI Web 层子网 SSH（端口 22） 设置和生命周期（在 OCI 中使用 Oracle HTTP Server 时）
    内部部署网络 OCI 数据库层子网 SSH（端口 22） 设置和生命周期
    内部部署数据库主机 OCI 数据库层子网 SQLNET（端口 1521） 对于 Oracle Data Guard redo transport
    内部部署网络 OCI Web 层子网 HTTPS/HTTP (443, 80, 7001) 访问 Web 应用程序和管理控制台
    内部部署网络 OCI 中间层子网 HTTP (7001,8001,9001) 用于直接检查 Oracle WebLogic Server
    OCI Web 层子网 OCI 中间层子网 HTTP (7001,8001,9001) 用于从 Web 层组件（OCI 负载平衡器，Oracle HTTP Server ）连接到 WebLogic 服务器
    OCI 中间层子网 OCI 数据库层子网 SQLNET (1521)，开启 (6200) 用于从 WebLogic Server 到数据库的连接
    OCI 中间层子网 OCI fss-tier 子网 有关特定信息，请参阅为文件存储配置 VCN 安全规则。 使用 NFS 挂载 OCI 文件存储文件系统导出。
    OCI 中间层子网 内部部署中间层主机 SSH（端口 22） 对于 rsync
    OCI 数据库层子网 内部部署数据库主机 SQLNET (1521) 对于 Oracle Data Guard redo transport
    OCI 中间层子网 OCI Web 层子网 HTTPS (443) 用于从应用程序回调到前端

    注：

    您可以在下载代码中找到用于创建 VCN、子网和安全规则的 terraform 代码。

配置 Oracle Data Guard

在 Oracle Cloud Infrastructure (OCI) 中的主内部部署数据库和备用数据库之间配置 Oracle Data Guard 。
  1. 在 OCI 中的主本地数据库和备用数据库之间配置 Oracle Data Guard，如 Hybrid Data Guard to Oracle Cloud Infrastructure 中所述。
    为了帮助配置 Oracle Data Guard ，脚本在 GitHub 中可用，并在下载代码中引用。
  2. 使用 Oracle Data Guard 命令行界面 (DGMGRL) 验证 Oracle Data Guard 设置是否正确。
    DGMGRL> show configuration verbose
  3. 完成 Oracle Data Guard 配置（步骤 2）后，在 OCI 数据库系统中创建与在主内部部署系统中使用的数据库服务相同的数据库服务。使用 PRIMARY 角色和 SNAPSHOT_STANDBY 角色配置服务。
    通过配置具有这两个角色的服务，可以在数据库转换为快照备用数据库时由 DG 中介自动启动服务，在您希望验证辅助系统而不执行完全切换时需要这样做。
    例如，如果主数据库使用数据库服务 mypdbservice.example.com 访问 PDB，则在辅助 OCI 数据库系统中创建相同服务。 
    srvctl add service -db $ORACLE_UNQNAME -service mypdbservice.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service mypdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service mypdbservice.example.com
  4. 如果主数据库中的服务是仅使用角色 PRIMARY 创建的（这是默认设置），则可以修改该服务以添加快照备用角色。
    srvctl modify service -db $ORACLE_UNQNAME -s mypdbservice.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. 查看主数据库中的 Oracle Recovery Manager (RMAN) 策略，以防止在将归档日志应用于备用数据库之前将其删除。
    确保主数据库和备用数据库中的 archivelog 删除策略 RMAN 中包含子句 applied on all standby。

关于数据库版本和补丁程序级别

内部部署数据库中的 Oracle 主目录和 OCI 上的备用数据库必须具有相同的版本和相同的补丁程序级别。您可以使用以下方法来实现这一点：

  • 在 OCI 中的数据库系统预配期间选择数据库软件映像时，选择显示所有版本，然后选择与内部部署数据库相同的数据库版本和补丁程序集级别。
  • 如果源数据库的 Oracle 主目录版本在 OCI 中不再可用于预配，则必须将源环境打补丁到与云环境中的数据库主目录相同的数据库补丁程序级别。

以下情景是供参考的真实示例。内部部署 DB 主目录为 19.6，OCI DB 主目录为 19.11。

  1. 运行命令 $ORACLE_HOME/OPatch/opatch lspatches 以标识在源环境和目标环境中安装的修补程序。
    $ORACLE_HOME/OPatch/opatch lspatches

    下面是此示例中的输出：

    本地部署的 DB Oracle 主目录补丁程序 OCI 上的数据库 Oracle 主目录补丁程序

    30676209；LNX64-20.1-RAC ASM 命中 ORA-07445 出现核心转储异常 [KSXPOSDIFQRY()+556]

    30613937；IPCOR TOPO 服务修复 IP 选择中的 IP 类型错误

    30484981；OJVM 发行版更新：19.6.0.0.200114 (30484981)

    30489227；OCW 发行版更新 19.6.0.0.0 (30489227)

    30557433；数据库发行版更新：19.6.0.0.200114 (30557433)

    29780459；增加 _LM_RES_HASH_BUCKET 并从错误 29416368 修复中取消更改

    30310195；DBSAT 报告的用于分片的已禁用约束条件 STS_CHUNKS，位于 GSMADMIN_INTERNAL.SHARD_TS

    32327201；RDBMS-DSTV36 更新 -TZDATA2020E

    31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A

    30432118；在错误 28852325 29997937 的 19.0.0.0.0 顶部合并请求

    31732095；将 19C 数据库中的 PERL 更新为 ORACLE HOME，更新为 V5.32

    32490416；JDK 捆绑包修补程序 19.0.0.0.210420

    32399816；OJVM 发行版更新：19.11.0.0.210420 (32399816)

    32579761；OCW 发行版更新 19.11.0.0.0 (32579761)

    32545013；数据库发行版更新：19.11.0.0.210420 (32545013)
  2. 分析现有修补程序：确定哪些修补程序是一次性修补程序，检查它们是否已在新 RU 修补程序中修复，或者是否需要新的重叠修补程序，确定必须卸载哪些修补程序，找到 RU 的相应修补程序文件，依此类推。
  3. 根据分析，在安装 RU 更新之前，卸载已在新 RU 中修复的一次性修补程序（否则，它们将导致冲突）。在本示例中，关闭的修补程序在 19.11 中修复，因此必须在安装 19.11 RU 之前回滚这些修补程序。
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. 找到、下载和安装 RU 修补程序。在本示例中，19.11 RU 修补程序位于组合修补程序 32578973:COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 中，这些修补程序如下所示：
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. 找到、下载并安装 OCI 数据库主目录在 RU 上具有的叠加、一次性修补程序和其他修补程序。例如： 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. 对 GI 修补程序执行类似的分析。

注：

此示例仅包含 RDBMS Oracle 主目录。严格来说，不需要将内部部署 GI 安装打补丁到与辅助部署相同的级别：
  • 从 Oracle Data Guard 的角度来看，在主数据库和备用数据库中使用相同的 GI 版本并不是绝对必要的：Oracle Data Guard 完全独立于数据库中的任何内容，因此您可以跨不同站点运行不同版本的操作系统、Oracle Clusterware、硬件或存储软件，而不会对版本或时间有任何限制。（文档 ID 1265700.1 ）
  • 无论 Oracle Data Guard 是什么，在 RAC 数据库的 GI 和 RDBMS 版本中不需要具有相同版本：从 18c 开始，Oracle Grid Infrastructure (GI) /集群件 (CRS) 版本必须始终等于或最高版本，直至可能的组合中的第一个数字。例如：网格基础结构可以位于 18.1.0.0，数据库可以位于 18.3.0.0。（文档 ID 337737.1 ）

最好在与数据库主目录相同的级别为 GI 打补丁。一旦您需要将数据库主目录打补丁到更新的发行版更新 (RU)，许多补丁程序对于 DB 和 GI 是通用的，您可以同时对两个主目录使用 OPatchAuto。