Windows Server 2019 MSCS 下 Oracle 11g/19c 故障转移群集实战

简介本资源面向需要在 Windows Server 2019 环境下搭建 Oracle 高可用架构的数据库运维与实施人员围绕故障转移群集MSCS双机热备场景系统讲解 Oracle 11g 与 19c 的部署流程。内容涵盖域控与数据库服务器环境规划、共享磁盘与群集资源组配置、监听器与数据库创建、故障检测与转移策略设置等关键环节并配有大量操作截图便于对照实操。资源包为 1 个 PDF 文档约 6.8MB图文并茂地呈现从系统准备到群集验证的完整过程适合作为部署参考手册或排错依据。目前已有 1338 人学习下载对希望掌握 Windows 平台 Oracle 故障转移群集搭建、提升业务连续性的技术人员具有较高参考价值。1. Windows Server 2019 MSCS 下 Oracle 11g/19c 故障转移群集为什么值得做、难在哪生产库里跑着 Oracle最怕的不是性能瓶颈而是那台数据库服务器突然趴窝。单机 Oracle 再稳主板、电源、系统盘任意一个环节出问题业务就得停摆。Windows Server 2019 自带的 MSCSMicrosoft Cluster Service现在叫 Failover Clustering配合共享存储能把 Oracle 11g 和 19c 做成双节点故障转移群集——一台挂了另一台在几十秒到几分钟内接管 VIP、监听和实例应用端只感知到一次短暂断连。这套方案在中小规模 ERP、MES、医疗 HIS 场景里非常常见原因很直接不用额外买 Linux 集群软件Windows 管理员就能维护Oracle 官方也提供了 Windows 平台的群集配置工具。但真正动手时坑集中在共享磁盘仲裁、Oracle 服务与群集资源的绑定顺序、11g 和 19c 在群集代理上的差异这三块。这篇笔记按“先理解 MSCS 怎么管 Oracle再分版本落地最后排错”的顺序展开适合有 Windows Server 基础、准备上 Oracle 高可用但还没踩过群集坑的运维和 DBA。2. MSCS 管 Oracle 的底层逻辑资源依赖、仲裁与 VIP 漂移2.1 MSCS 把 Oracle 拆成哪几类群集资源MSCS 不直接“跑 Oracle”它管的是资源。一个典型的 Oracle 故障转移群集里至少包含这几类资源物理磁盘资源共享 LUN、IP 地址资源客户端访问 VIP、网络名称资源对应 VIP 的 NetBIOS 名、以及 Oracle 数据库服务资源。前三个是 Windows 原生资源第四个由 Oracle 提供的群集代理 DLL 来注册。资源之间有严格的依赖关系。网络名称依赖 IP 地址Oracle 数据库服务依赖网络名称和物理磁盘。这个依赖链决定了故障转移顺序磁盘先在线VIP 再上线最后 Oracle 服务启动。如果依赖配反了比如 Oracle 服务只依赖磁盘不依赖网络名称VIP 还没漂过去服务就起来了客户端连不上群集日志里会看到一堆 1069 和 1053 事件。Oracle 11g 和 19c 在资源类型注册上略有不同。11g 时代常用oracle.mts或oracle.mts.v11这类资源 DLL19c 更推荐用 Oracle Clusterware 之外的 Windows 原生方式或者用 Oracle Restart 配合 MSCS 的通用服务资源。实际落地时我一般先确认 Oracle 安装介质里%ORACLE_HOME%\bin下有没有oracleclusteragent.dll或类似代理文件没有的话就得走“通用服务”资源类型把 Oracle 服务当成普通 Windows 服务来管。2.2 共享磁盘的仲裁配置多数节点还是磁盘见证双节点群集最容易翻车的地方是仲裁。Windows Server 2019 默认推荐“多数节点”或“节点和磁盘多数”。如果只有两个节点、没有见证磁盘一旦节点间心跳断掉两个节点都认为自己该接管就会出现脑裂。Oracle 数据文件被两个实例同时挂载后果是数据文件头损坏只能从备份恢复。我的习惯是双节点 一块小的见证磁盘至少 512MB不存数据只放群集配置。仲裁配置成“节点和磁盘多数”这样任意一个节点挂掉另一个节点加见证磁盘仍然占多数可以正常接管。如果存储阵列不支持再分一个 LUN 做见证那就用“节点和文件共享多数”找一个稳定的 SMB 共享放见证文件。注意这个共享不能放在即将被群集管理的节点本身上否则节点挂了见证也丢了。配置命令用 PowerShell 最直接# 查看当前群集的仲裁配置 Get-ClusterQuorum -Cluster ORA-CLUSTER # 设置仲裁为节点和磁盘多数并指定见证磁盘 Set-ClusterQuorum -Cluster ORA-CLUSTER -NodeAndDiskMajority Cluster Disk 3-NodeAndDiskMajority后面的参数是群集里已经添加的磁盘资源名称不是盘符。执行完用Get-ClusterQuorum确认输出里QuorumResource指向正确的见证磁盘。如果后面要改仲裁模式先让群集角色离线改完再上线否则可能触发一次非计划转移。2.3 VIP 漂移与客户端 TNS 配置的配合VIP 漂移本身是 MSCS 自动完成的但客户端能不能快速重连取决于 TNS 里的FAILOVER和RETRY参数。很多新手只配了一个ADDRESSVIP 漂移后客户端还在往旧节点 IP 发连接请求等 TCP 超时才发现连不上业务侧感知的断连时间被拉长到几分钟。正确的做法是在tnsnames.ora里配两个 ADDRESS一个指向当前 VIP一个指向备用节点的物理 IP 或另一个 VIP并开启FAILOVERON。下面是一个 19c 客户端连 11g/19c 群集的示例ORA_CLUSTER (DESCRIPTION (ADDRESS_LIST (ADDRESS (PROTOCOL TCP)(HOST 10.10.10.50)(PORT 1521)) (ADDRESS (PROTOCOL TCP)(HOST 10.10.10.51)(PORT 1521)) ) (CONNECT_DATA (SERVICE_NAME orcl) (FAILOVER_MODE (TYPE SELECT) (METHOD BASIC) (RETRIES 180) (DELAY 5) ) ) )HOST填 VIP 和备用节点 IPRETRIES180配合DELAY5意味着最多重试 15 分钟覆盖群集转移和数据库启动的时间。TYPESELECT适合查询为主的业务如果是长事务写入改成SESSION更稳妥但会占用更多客户端资源。这个配置在 11g 和 19c 客户端上通用区别只在 19c 客户端默认走SERVICE_NAME而不是SID写 TNS 时注意别混用。3. Oracle 11g 在 MSCS 上的部署从安装到群集资源注册3.1 安装前的共享存储与节点准备Oracle 11g 对 Windows 群集的支持依赖共享磁盘的盘符一致性。两个节点上看到的共享 LUN 盘符必须完全一样比如数据文件在 E 盘两个节点都得是 E 盘。如果一边是 E 一边是 F群集转移后 Oracle 找不到数据文件实例起不来。准备步骤按顺序来在存储端划好 LUN至少三个一个放 Oracle 二进制本地盘也行但群集角色里通常放共享盘方便统一管理、一个放数据文件、一个放快速恢复区。如果预算紧数据和 FRA 可以共用一个 LUN但归档日志和联机日志最好分开。在两个节点上分别用diskmgmt.msc确认共享磁盘可见并分配相同盘符。注意不要在两个节点同时把共享磁盘置为“联机”并初始化否则后操作的节点会提示磁盘被占用。正确做法是节点 A 先联机、初始化、格式化、分配盘符然后节点 B 再联机此时 B 应该直接看到已格式化的卷不需要再初始化。关闭两个节点的 Windows 防火墙对 Oracle 端口和群集通信的拦截或者按端口放行。群集通信走 UDP 3343Oracle 监听默认 1521这些在域环境里通常由组策略统一放行但独立环境要手动加规则。安装 Oracle 11g 软件时两个节点都要装但只在一个节点上建库。建库时数据文件路径指向共享盘比如E:\ORADATA\ORCL。建完库后把实例停掉再用 Oracle 提供的oracleclusteragent或者 Windows 通用服务方式把服务注册到群集。3.2 用 Oracle 群集代理注册数据库服务Oracle 11g 安装介质里通常带一个oracleclusteragent.dll位于%ORACLE_HOME%\bin。注册资源类型和资源的命令如下:: 在群集的一个节点上执行注册 Oracle 资源类型 cluster res Oracle Database /create /type:Oracle Database /dll:D:\app\oracle\product\11.2.0\dbhome_1\bin\oracleclusteragent.dll :: 创建 Oracle 数据库服务资源依赖网络名称和共享磁盘 cluster res Oracle ORCL /create /group:ORA-CLUSTER-GROUP /type:Oracle Database cluster res Oracle ORCL /priv DatabaseNameORCL cluster res Oracle ORCL /priv OracleHomeD:\app\oracle\product\11.2.0\dbhome_1 cluster res Oracle ORCL /priv ServiceNameOracleServiceORCL cluster res Oracle ORCL /adddep:Cluster Disk 1 cluster res Oracle ORCL /adddep:Cluster Name/priv后面的参数是 Oracle 代理 DLL 读取的私有属性DatabaseName对应实例名OracleHome是二进制路径ServiceName是 Windows 服务名。/adddep把资源挂到依赖链上顺序不能反先加磁盘依赖再加网络名称依赖。注册完用cluster res Oracle ORCL /online上线观察群集管理器里资源状态是否变成“联机”。如果oracleclusteragent.dll不存在说明安装时没选群集组件需要重新运行安装程序补装。补装前先把现有实例停掉避免 DLL 被占用导致安装失败。3.3 验证 11g 故障转移是否真的生效验证不能只看群集管理器里资源状态变绿。真正的验证要模拟节点宕机观察 VIP 漂移和数据库恢复时间。我一般按这个流程走在客户端用 TNS 连接跑一个长查询或者持续select sysdate from dual的脚本记录开始时间。在持有 Oracle 资源的节点上直接强制断电或者用Stop-ClusterNode -Name 节点A -Force模拟故障。观察客户端脚本是否在预期时间内恢复输出同时看群集管理器里资源是否在节点 B 上变成“联机”。登录节点 B检查 Oracle 告警日志alert_ORCL.log确认实例启动过程中没有 ORA-01157 或 ORA-01207 这类数据文件访问错误。11g 在群集转移后实例恢复时间取决于联机日志大小和检查点频率。如果联机日志给得小、检查点频繁恢复可能只要十几秒如果日志大、检查点间隔长恢复可能超过一分钟。生产环境建议把fast_start_mttr_target设成 300 以内让 Oracle 自动控制检查点缩短崩溃恢复时间。4. Oracle 19c 在 MSCS 上的部署和 11g 的差异与适配4.1 19c 安装选项与群集组件的取舍Oracle 19c 在 Windows 上的群集支持和 11g 有本质区别。19c 更倾向于用 Oracle Restart 或者 Grid Infrastructure 来管高可用但在纯 Windows MSCS 场景下很多团队还是走“通用服务资源”路线把OracleServiceORCL当成普通 Windows 服务注册到群集而不是依赖 Oracle 自己的群集代理 DLL。这样做的好处是简单不需要额外装 Grid Infrastructure也不用折腾 ASM。坏处是群集代理不知道 Oracle 实例的真实健康状态只能看 Windows 服务是否在运行。如果实例挂了但服务进程还在MSCS 不会触发转移。为了弥补这一点我一般会加一个自定义的健康检查脚本用sqlplus定时查v$instance查不到就主动让资源失败触发群集转移。19c 安装时注意选择“仅安装数据库软件”还是“创建并配置数据库”。群集场景下两个节点都只装软件建库只在第一个节点做数据文件放共享盘。建库时如果用了DBCA在“数据库选项”里把“创建为群集数据库”勾上但 Windows 平台这个选项有时是灰的那就手动建库再手动注册服务。4.2 用通用服务资源注册 19c 数据库通用服务资源的注册命令和 Oracle 专用资源不同不需要 DLL直接指定服务名和启动参数# 创建通用服务资源指向 OracleServiceORCL Add-ClusterGenericServiceRole -ServiceName OracleServiceORCL -Name Oracle 19c ORCL -Storage Cluster Disk 1 -StaticAddress 10.10.10.50 -NetworkName ORA-VIP # 查看资源依赖关系确认磁盘和网络名称已自动加入 Get-ClusterResource Oracle 19c ORCL | Get-ClusterResourceDependency-Storage指定共享磁盘资源名-StaticAddress是 VIP-NetworkName是群集网络名称。PowerShell 会自动建立依赖关系比命令行cluster res更省事。注册完检查依赖报告确保 Oracle 服务资源依赖磁盘和网络名称而不是反过来。19c 的服务启动比 11g 慢尤其是实例恢复阶段。群集资源的“挂起超时”默认是 3 分钟如果数据库大、恢复慢可能超时导致群集认为资源失败反复重启。这时候要调大超时# 把资源挂起超时改成 600 秒 (Get-ClusterResource Oracle 19c ORCL).SuspendTimeout 600改完用Get-ClusterResource确认属性生效。这个参数在 11g 上同样适用但 11g 恢复通常更快默认值一般够用。4.3 19c 的 TNS 与监听在群集里的特殊处理19c 的监听器默认走listener.ora里的SID_LIST_LISTENER但在群集里监听器最好也做成群集资源跟着 VIP 一起漂移。如果监听器只在本地节点跑VIP 漂过去后客户端连 VIP 的 1521 端口会拒绝连接。做法是在两个节点上都配listener.ora监听地址写 VIP然后建一个通用服务资源指向TNSLSNR服务。注意TNSLSNR服务在 Windows 上默认不是自动启动注册群集资源前先把它设成手动启动由群集来控制启停。LISTENER (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 10.10.10.50)(PORT 1521)) ) )HOST写 VIP不要写节点物理 IP。两个节点的listener.ora内容完全一致这样任意节点接管后监听器都能在 VIP 上启动。19c 的监听器日志在%ORACLE_HOME%\diag\tnslsnr\下转移后如果监听起不来先看这个日志里的 TNS-12560 或 TNS-00530 错误通常是 VIP 还没上线监听就抢先启动了调整资源依赖顺序即可。5. 避坑与排查MSCS 管 Oracle 最常见的 5 个翻车点5.1 共享磁盘盘符不一致导致实例启动失败现象群集转移后Oracle 资源显示“联机”但客户端连不上告警日志里报 ORA-01157 或 ORA-27041提示找不到数据文件。原因两个节点上共享 LUN 的盘符不同。比如节点 A 是 E 盘节点 B 是 F 盘控制文件里记录的是 E 盘路径节点 B 接管后按 E 盘找找不到。解决停掉群集角色在两个节点上分别用diskpart确认共享磁盘的卷 GUID确保盘符分配一致。如果已经不一致在节点 B 上把盘符改成和节点 A 一样然后重新上线资源。改盘符前先把 Oracle 服务停掉避免文件句柄占用导致改盘失败。5.2 仲裁配置不当引发脑裂现象两个节点都认为自己是持有者同时挂载共享磁盘数据文件头损坏群集日志里出现 1135 事件群集节点被移除。原因双节点群集用了“多数节点”仲裁没有见证磁盘。节点间心跳一断两个节点各自算一票都觉得自己是多数。解决加一块见证磁盘仲裁改成“节点和磁盘多数”。如果存储不支持用“节点和文件共享多数”共享路径放在第三方文件服务器上。已经脑裂的群集不要直接强制上线先用Get-ClusterLog导出日志确认哪个节点先失去心跳再决定从哪个节点恢复数据。5.3 Oracle 服务资源依赖顺序配反现象群集转移后Oracle 服务先于 VIP 启动客户端连接 VIP 超时等 VIP 上线后服务已经处于“联机”状态但监听没起来。原因资源依赖里 Oracle 服务只依赖了磁盘没依赖网络名称。MSCS 并行启动资源时服务抢在 VIP 前面。解决用Get-ClusterResourceDependency检查依赖链确保 Oracle 服务资源依赖网络名称网络名称依赖 IP 地址IP 地址依赖磁盘。缺哪条补哪条Add-ClusterResourceDependency -Resource Oracle 19c ORCL -Provider ORA-VIP补完依赖后把资源离线再上线让依赖关系重新生效。5.4 19c 实例恢复超时导致群集反复重启资源现象群集转移后Oracle 资源状态在“联机”和“失败”之间反复跳事件日志里报“资源挂起超时”。原因19c 实例恢复时间超过了群集默认的挂起超时3 分钟群集认为资源启动失败强制重启重启后恢复还没完成又超时形成循环。解决把资源挂起超时调大同时优化实例恢复速度。调超时用SuspendTimeout属性优化恢复可以调小fast_start_mttr_target或者增加检查点频率。如果数据库实在太大考虑用 Data Guard 而不是 MSCS 做容灾MSCS 更适合中小规模库。5.5 监听器没做成群集资源导致 VIP 漂移后连接拒绝现象数据库资源转移成功VIP 也能 ping 通但客户端连 1521 端口报 TNS-12541提示无监听程序。原因监听器只在原节点上跑VIP 漂到新节点后新节点上没有监听器在 VIP 上监听。解决把TNSLSNR服务注册成通用服务资源依赖网络名称和 Oracle 数据库资源放在同一个群集组里。注册命令参考 4.2 节的Add-ClusterGenericServiceRole把-ServiceName改成TNSLSNR。注册后确认监听器日志里绑定的是 VIP 而不是0.0.0.0或节点物理 IP。6. 进阶用健康检查脚本让 MSCS 真正感知 Oracle 死活通用服务资源只能看 Windows 服务进程在不在实例内部挂了它不知道。我一般会加一个自定义脚本挂在群集资源的“脱机”或“联机”操作里或者用 Windows 任务计划定时跑发现异常就主动让资源失败。脚本思路很简单用sqlplus以sysdba身份连本地实例查v$instance的status如果不是OPEN就返回非零退出码。群集资源可以配置一个“健康检查”脚本退出码非零时触发资源重启或转移。# check_oracle_health.ps1 $env:ORACLE_HOME D:\app\oracle\product\19.0.0\dbhome_1 $env:PATH $env:ORACLE_HOME\bin;$env:PATH $result sqlplus -S / as sysdba set heading off; select status from v\$instance; exit; if ($result -match OPEN) { exit 0 } else { Write-EventLog -LogName Application -Source OracleHealthCheck -EventId 1001 -EntryType Error -Message Oracle instance not OPEN: $result exit 1 }这个脚本在 11g 和 19c 上都能用区别只在ORACLE_HOME路径。把脚本放到两个节点的相同路径下比如C:\ClusterScripts\然后在群集资源里配置“联机后运行”或“定期运行”。注意脚本执行账户要有sysdba权限通常用 Oracle 安装账户或者把它加入ORA_DBA组。验证脚本是否生效可以手动shutdown abort实例看群集是否在几十秒内触发资源失败和转移。如果没触发检查群集资源的“健康检查”间隔是不是设得太长默认可能是 60 秒调成 15 秒更灵敏。但别调太短sqlplus连接本身有开销太频繁会加重实例负担。这套方案我前后在十几个生产环境里落过最深的教训是别信群集管理器里那个绿色的“联机”图标它只代表 Windows 服务在跑不代表 Oracle 能干活。每次上线前我都会手动kill一次节点用客户端真实连一遍看恢复时间能不能接受。如果恢复时间超过业务容忍度要么调参数要么换方案。希望帮到你。本文还有配套的精品资源点击获取