简介面向 Windows Server 2019 环境下维护 Oracle 数据库的运维与 DBA 工程师聚焦使用系统自带故障转移群集MSCS为 Oracle 11g 和 19c 搭建双机热备高可用环境。压缩包共 1 个 PDF 文件大小 6.8MB内容以图文对照方式逐步演示部署全过程从域控与双节点服务器、共享磁盘准备开始覆盖 Oracle 软件解压安装、netca 监听配置、dbca 建库到 MSCS 群集服务安装、资源组创建及故障转移策略配置对 11g 和 19c 两套版本分别给出步骤同时标注关键选项注意事项与验证方法。资源已有 1338 人学习下载适合需要为生产或测试环境落地 Oracle 故障转移群集、减少单点故障风险的工程师按图索骥参考操作。1. 为什么要在 Win Server 2019 MSCS 下部署 Oracle 11g/19c 故障转移群集看到“Win Server 2019 MSCS 下 Oracle 11g/19c 故障转移群集部署”这个标题我第一反应是这个方案背后多半是一套跑在 Windows 上的业务系统Oracle 单实例已经扛不住“节点宕机就停业”的问责了。MSCS也就是微软故障转移群集能帮你把 Oracle 服务、监听器和共享数据盘打包成一个可漂移的角色——主节点挂了备节点自动接管应用层只感知到一次数据库闪断而不是几小时的停机等待。这套路适合两类团队一是只有两台 Windows 物理机或虚机、共享存储已就位、但又不想为 Oracle RAC 掏双倍许可费的项目二是已经有 11g 老库、想在不换架构的前提下先解决可用性的迁移场景。文章按 11g 和 19c 两条线走先讲清楚前置条件再给建群集的 PowerShell 命令最后落到 Oracle 服务注册、监听配置和最常见的故障排查。照着做半天内能跑通最小可用集群。2. 部署前先定三件事共享存储、网络拓扑与账号权限2.1 共享存储数据文件必须落在群集磁盘上MSCS 故障转移的底层逻辑其实就一句话谁成为群集磁盘的所有者谁就能访问 Oracle 的数据文件。所以整个部署的第一前提是两个节点必须能同时看到同一块共享 LUN但同一时刻只有一个节点能写它。这个“唯一写入权”由群集磁盘资源保证不需要你手动锁盘。Oracle 的二进制文件可以每个节点本地各装一份但数据文件、控制文件、联机重做日志、spfile 必须全部落在群集托管的共享盘上。常见做法是准备两块 LUN一块 1GB 左右做仲裁另一块放数据库数据容量按业务量预留。仲裁盘不要和数据盘混用否则群集仲裁和数据 I/O 互相干扰出问题的时候连排查都难分清是存储抖动还是仲裁丢失。两个节点看到的磁盘编号可能不一样但分区完成后必须把盘符固定成同一个比如数据盘统一 E:\仲裁盘统一 Q:\。盘符不一致是 Oracle 在故障转移后起不来的头号原因后面会专门讲。内容存放位置说明Oracle 软件各节点本地 D:\oracle两台机器各装一份路径尽量一致数据文件/控制文件/联机日志共享盘 E:\oradata群集磁盘资源spfile/pfile共享盘 E:\oradata必须两个节点都能读到监听配置各节点本地 ORACLE_HOME\network\admin两边同步同一份配置客户端连接串应用服务器HOST 指向群集网络名称或虚拟 IP共享盘建议用 NTFS别开 BitLocker别把盘做成动态磁盘。iSCSI 和光纤 SAN 都行关键是 LUN 要能被两个节点同时发现并且不要在两个节点的磁盘管理里分别格式化——只在其中一个节点格式化另一个节点认盘就行。2.2 网络与域心跳网、公共网和“群集网络名称”的分工Windows 故障转移群集至少需要两个逻辑网络。公共网络承载客户端访问、RDP、DNS 解析心跳网络负责节点间状态同步和资源心跳检测。心跳网络建议用独立物理网卡直属子网不配网关、不配 DNS也不要勾选 NetBIOS over TCP/IP。两节点的心跳网地址即使在不同子网也没问题但公共网必须在同一网段且能互通。这里有个容易被忽略的细节2019 的系统网络适配器顺序会影响群集行为最好把公共网适配器排在绑定顺序第一位心跳网排在最后。另外两个节点必须加入同一个 AD 域。群集创建时会在域里自动注册一个“群集网络名称”类似 OracleCluster.yourdomain.local并分配一个虚拟 IP。故障转移后这个名称和 IP 会漂移到新节点。Oracle 的客户端 TNS 地址、应用数据源连接串必须全部指向这个网络名称而不是节点 db01 或 db02——否则切换后应用连的还是原节点等于白做。2.3 账号与权限Oracle 服务账户和群集管理分开准备先创建一个域账号比如 svc_oracle专门用来跑 Oracle 数据库服务和监听服务。需要给它“作为服务登录”的权限并授予 Oracle 安装目录 D:\oracle 和共享数据盘 E:\oradata 的完全控制权。Oracle 安装时用本地管理员运行装完再把服务登录身份改成 svc_oracle。不要图省事用 SYSTEM 跑 Oracle19c 下 UAC 和 Windows 权限模型会把 expdp、备份等外部作业的执行权限压得很低出现的问题非常难排查。账号用途权限域管理员部署集群、安装 Oracle域级管理员svc_cluster群集服务默认可不用额外账号本地管理员组svc_oracle跑 OracleService 和 TNSListener作为服务登录D:\oracle 与 E:\oradata 完全控制群集服务本身在标准配置下用系统虚拟账户跑不需要单独建域账号。真正需要提前准备的是 svc_oracle密码千万不要设成永不过期但还是每年被安全策略强制改一次——群里最容易翻车的场景就是服务密码过期资源在故障转移当天联机失败业务全责落到 DBA 头上。3. 用 PowerShell 把两台 Win Server 2019 变成 MSCS 群集3.1 安装故障转移群集功能并跑配置验证故障转移群集在 Windows Server 2019 里是一个功能不是独立安装包。两台节点都得装装完重启后先跑验证不要直接建集群。# 在 db01 和 db02 上分别执行 Install-WindowsFeature Failover-Clustering -IncludeManagementTools逻辑说明-IncludeManagementTools 会把故障转移群集管理器和 PowerShell 模块一起装好后续 GUI 操作和命令行操作都不缺工具。装完不需要手动配置任何服务重启后功能即生效。接着在任意一台节点上跑完整验证Test-Cluster -Node db01,db02 -ReportName C:\ClusterValidation参数说明-Node 列出两个节点名-ReportName 指定 HTML 报告输出路径。如果不指定版本它会跑存储、网络、系统配置、群集配置四类检查时间大约几分钟。报告生成后重点看 Network 和 Storage 两类如果出现“共享磁盘无法访问”或“网络名称无法注册”这类失败必须解决后再继续不能用“能建就行”的心态跳过。3.2 创建群集与仲裁配置验证通过后创建群集最小命令如下New-Cluster -Name OracleCluster -Node db01,db02 -NoStorage -StaticAddress 192.168.1.20逻辑说明-Name 是群集网络名称会自动注册到 AD-NoStorage 表示先不托管任何磁盘避免未格式化的 LUN 被自动拉进来-StaticAddress 给群集网络名称指定一个固定的公共网段 IP。注意这个 IP 是“群集本身的访问地址”和后面 Oracle 角色的虚拟 IP 不是一个东西别混用。创建完成后执行 Get-ClusterNode确认两个节点状态都是 Up。接下来设置仲裁。双节点群集最稳妥的模式是“多数节点 文件共享见证”也就是 2 节点 1 个见证构成 3 票Set-ClusterQuorum -NodeAndFileShareMajority \\FS01\Quorum这个命令把仲裁模式从默认的“多数节点”切换为“多数节点文件共享见证”。\FS01\Quorum 这个共享目录不要放在群集节点自己的 C 盘上否则群集全挂时见证也没了放到第三台机器或存储阵列上的独立目录。2 节点 1 见证下任意一个节点宕机集群仍保持仲裁不会出现脑裂。3.3 让共享 LUN 变成群集磁盘资源创建完群集后两节点能看到共享 LUN但 Windows 可能把它标记为“脱机”。先确认磁盘状态再把它加入群集Get-Disk | Where-Object BusType -eq iSCSI | Format-Table Number,FriendlyName,Size,PartitionStyle Add-ClusterDisk -Cluster OracleCluster -Disk 1逻辑说明Get-Disk 先看磁盘编号和总线类型确认 LUN 已经被系统识别。Add-ClusterDisk -Disk 1 中的 1 是在当前节点上看到的磁盘编号。加入群集后资源名以“Cluster Disk 1”“Cluster Disk 2”为准不要再依赖 Windows 磁盘编号。加入群集后在任意一个节点上把数据盘联机、分区、格式化成 NTFS、固定盘符 E:\。仲裁盘固定为 Q:\。另一个节点上不要重新格式化只需要确认能看到 E:\ 和 Q:\ 并且可读。固定盘符时要注意如果磁盘管理里默认给了别的盘符右键改掉后再到群集管理器刷新盘符会作为资源属性保存。4. Oracle 11g/19c 安装与共享库路径两边都装、只建一次4.1 11g 与 19c 在 Windows Server 2019 上的支持差异先给 11g 泼盆冷水11.2.0.4 在 Windows Server 2019 上不在 Oracle 官方认证列表里。安装程序可能会弹操作系统版本警告某些补丁和组件在安装阶段需要手动绕过预检查。能用但生产环境要自己承担风险。如果非要上 11g建议至少用 11.2.0.4 并打齐最新 PSU安装时选择“忽略操作系统版本检查”装完再跑一遍 11g 的关键补丁。相比之下 Oracle 19c 原生支持 Windows Server 2019安装过程没有版本兼容性问题也是目前最值得投入的路线。新项目别犹豫直接 19c。两个版本在部署套路上是同一套逻辑节点 A 装软件、建库节点 B 只装软件、不建库。数据库文件只保留一份在共享盘上任何时刻只有一个实例能打开它。这个“两边都装、只建一次”的方式既保证故障转移后另一个节点有可用的 Oracle 二进制又避免两个实例同时挂载同一批数据文件导致的脑裂。4.2 安装套路与 Windows 服务名OracleService 和 TNSListener安装 Oracle 软件时两个节点都用“仅安装数据库软件”选项不建库。节点 A 装好后用 DBCA 建库存储位置全部指到 E:\oradata\ORCL。这里注意不只是数据文件控制文件、联机重做日志、spfile 都要放在共享盘。DBCA 默认的“快速恢复区”如果指向本地盘也要改掉否则故障转移后实例启动时找不到归档目录数据库直接提示无法打开。安装完成后的关键操作是确认 Windows 服务名。查看所有 Oracle 相关服务Get-Service -Name Oracle* | Format-Table Name,Status,StartType19c 的数据库实例服务一般是 OracleServiceORCL监听服务是 OracleOraDB19Home1TNSListener11g 的监听服务名可能是 OracleOraDb11g_home1TNSListener具体以 Get-Service 输出为准。后面注册群集通用服务时资源类型要求填“服务名”填错一个字群集都找不到服务。建库完成后把两个节点上所有 Oracle 服务的启动类型全部改为“手动”。这个动作很多人会漏掉如果服务保持“自动”节点重启后本地服务抢先拉起数据库群集资源管理器会认为资源的状态异常出现集群服务和本地服务抢启动权的混乱。改成手动后数据库只在群集决定让它在哪个节点运行时才被拉起。4.3 spfile、listener.ora 和两个节点路径统一建库时 DBCA 会生成一个默认 spfile默认路径可能在本地 ORACLE_HOME 的 database 目录下。这个位置在故障转移场景里是致命的——节点 B 根本读不到节点 A 本地盘上的 spfile。建库完成后手动指定CREATE PFILEE:\oradata\ORCL\pfileORCL.ora FROM SPFILE; CREATE SPFILEE:\oradata\ORCL\spfileORCL.ora FROM PFILE;逻辑说明把 spfile 重建到共享盘 E:\oradata\ORCL并在数据库注册表或启动参数里保证实例启动时读取的是这个共享盘上的 spfile。11g 和 19c 都用这一招。初始化参数里再确认控制文件路径SELECT name FROM v$controlfile;如果控制文件路径里出现 C:\ 或 D:\ 的本地盘路径故障转移后必然 ORA-00205。控制文件必须放在共享盘上最好三份镜像都放 E:\oradata 下不同子目录。两节点的 Oracle 软件路径尽量完全一致比如都是 D:\oracle\19c\dbhome_1。如果硬件磁盘布局不一致可以用目录符号链接兜底mklink /D D:\oracle E:\oracle_local这行命令在磁盘层面把 D:\oracle 映射到本地 E:\oracle_local保证两个节点上 ORACLE_HOME 对外路径一致。注意用符号链接之前先把原路径清空不然会叠加。路径问题解决后再处理监听配置文件。listener.ora 和 tnsnames.ora 在每台节点本地各有一份必须同步成同一份内容HOST 不写节点名写群集网络名称或虚拟 IP具体写法放到下一章。5. 把 Oracle 注册成群集通用服务依赖顺序与虚拟 IP 监听5.1 创建通用服务角色GUI 还是 Add-ClusterGenericServiceRoleMSCS 不直接认识 Oracle但可以通过“通用服务”资源类型托管任意 Windows 服务。这就是把 Oracle 纳入故障转移的标准做法。推荐先在故障转移群集管理器里走一遍图形界面理解资源结构再用 PowerShell 固化流程。GUI 路径故障转移群集管理器 → 角色 → 配置角色 → 通用服务 → 选择 OracleServiceORCL → 指定角色名称 OracleDB 和静态 IP 192.168.1.21。群集会自动创建网络名称和 IP 资源并把 Oracle 服务加进这个角色。等价于下面的 PowerShellAdd-ClusterGenericServiceRole -Service OracleServiceORCL -Name OracleDB -StaticAddress 192.168.1.21参数说明-Service 填 Oracle 的 Windows 服务名-Name 是群集角色名-StaticAddress 是客户端真正会连接的虚拟 IP。执行后用 Get-ClusterGroup -Name OracleDB 查看角色内资源应该能看到 OracleServiceORCL 服务资源、网络名称、IP 地址三项。5.2 监听服务加入同一角色依赖链按“磁盘→网络名→DB→监听”排数据库服务资源建好后监听不会自动跟随。把监听注册成同一个角色里的第二个通用服务Add-ClusterGenericServiceRole -Service OracleOraDB19Home1TNSListener -Name OracleDB_Listener -Group OracleDB这里的 -Group OracleDB 是关键指定把新建的监听服务资源放进已存在的 OracleDB 角色组而不是另起一个新角色。这样当角色漂移时数据库服务和监听服务作为一个整体移动。资源都加入后必须设置依赖顺序。打开故障转移管理器右键 OracleDB 角色 → 资源 → 依赖关系按下面顺序调整顺序资源依赖1Cluster Disk 2数据盘无2OracleDB 网络名称Cluster Disk 23OracleServiceORCLCluster Disk 2 OracleDB 网络名称4OracleOraDB19Home1TNSListenerOracleDB 网络名称 OracleServiceORCL用 PowerShell 也可以设Set-ClusterResourceDependency -Resource OracleOraDB19Home1TNSListener -Dependency [OracleDB 网络名称] AND [OracleServiceORCL] Set-ClusterResourceDependency -Resource OracleServiceORCL -Dependency [Cluster Disk 2] AND [OracleDB 网络名称]依赖链的逻辑是先让盘联机再注册网络名称然后数据库服务才能启动最后监听服务启动。如果监听不依赖数据库服务会出现监听先起来、实例还没 ready客户端连接收到 ORA-01033 的窗口期。依赖关系设置完在 GUI 里看依赖图应该是一条清晰的单向链。5.3 客户端连接串与 listener.ora 的 HOST 到底填什么这是整个部署里最容易翻车的部分。Oracle 监听器默认监听安装机器的 hostname在故障转移场景下必须改成监听群集角色的虚拟 IP。修改节点 A 的 listener.oraLISTENER (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.21)(PORT 1521)) )HOST 填 OracleDB 角色的静态 IP不要填 db01也不要填群集网络名称 OracleCluster 的 IP。192.168.1.21 是角色专用 IP故障转移时会跟着角色漂移群集网络名称的 IP 是群集自己的管理地址Oracle 监听绑它虽然也能通但职责上不干净。两个节点的 listener.ora 都要同步改成这份内容然后重启监听lsnrctl stop lsnrctl start lsnrctl serviceslsnrctl services 的输出里会列出监听地址确认显示的地址是 192.168.1.21 而不是某个节点名。客户端 tnsnames.ora 同样指向这个虚拟 IPORCL (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.21)(PORT 1521)) (CONNECT_DATA (SERVICE_NAME ORCL)) )常见误用是把 HOST 写成 db01 或 192.168.1.11故障转移到 db02 后客户端拿着旧地址找监听报 ORA-12541。配置完成后在客户端用 tnsping ORCL 验证再用 PL/SQL Developer 或 SQL*Plus 实际连一次。连得通说明网络名称、虚拟 IP、监听配置这个链条已经闭环。6. 故障转移部署避坑与验证3 条血泪经验6.1 磁盘被保留数据库在另一节点起不来故障现象把 OracleDB 角色手动移动到节点 B数据库起不来告警日志里全是 ORA-01157 和 ORA-01110。原因分析共享盘虽然已经加入群集“可用存储”但没有被加进 OracleDB 角色也没有被 Oracle 服务资源依赖。节点 B 的 Windows 能看到盘但群集把磁盘标记为“脱机保留”文件系统不可访问。解决在故障转移管理器里把数据盘添加进 OracleDB 角色并确认 OracleServiceORCL 依赖它。这是最常见的第一坑新建角色后必须手动把磁盘拖进角色。6.2 ORA-12541监听还绑在旧节点上故障现象角色切换后数据库实例正常但应用连接报 ORA-12541 TNS no listener。原因分析listener.ora 里的 HOST 还是 db01 的节点名或节点 IP切换到节点 B 后监听器没有监听虚拟 IP 192.168.1.21。解决把两个节点的 listener.ora 全部改成虚拟 IP重启监听再用 lsnrctl services 确认监听地址。这里提醒一句改 listener.ora 时如果服务资源已经注册进群集群集会不断尝试重启监听务必在把监听资源加入群集之前先改好配置否则会出现资源反复联机失败的假象。6.3 资源卡“正在联机”服务账户权限才是元凶故障现象手动移动角色时资源长时间停在“正在联机”最后超时失败。原因分析Oracle 服务使用的域账户 svc_oracle 缺少“作为服务登录”权限或者密码已经过期。群集启动服务时调用 Windows SCMSCM 返回错误群集资源类型会按既定策略重试但重试间隔很长看起来像卡死。解决先在 services.msc 里手动启动 OracleServiceORCL 看具体报错再打开本地安全策略 → 用户权限分配 → 作为服务登录把 svc_oracle 加进去并确认密码有效。6.4 故障转移演练的三条命令部署完成后至少做一次完整演练。三条命令足够判断集群是否健康Get-ClusterGroup -Name OracleDB Get-ClusterResource | Where-Object State -ne Online Move-ClusterGroup -Name OracleDB -Node db02第一条看角色当前在哪个节点第二条看是否有资源处于异常状态第三条把整个角色从当前节点移动到 db02。移动完成后再执行一次 Get-ClusterGroup确认角色在 db02 处于 Online然后在客户端重新连接数据库执行一条简单查询比如 select 1 from dual验证监听和应用链路。还有一条我自己的习惯每次故障转移演练前先做一个完整的数据文件冷备。虽然群集切换会在关闭数据库后移动磁盘文件理论上是一致的但演练过程中一旦出现角色恢复失败、群集资源卡死的局面冷备就是你的后悔药。演练不是走过场是检验依赖关系、服务账户、监听配置和存储切换这四件事是否真的准备好了。希望帮到你。本文还有配套的精品资源点击获取