简介这是Windows Server 2019故障转移群集MSCS下部署Oracle 11g与19c高可用环境的图文指南面向负责数据库双机热备的运维工程师、DBA及系统实施人员。内容完整覆盖域控服务器与双节点Oracle服务器的环境准备、Oracle软件安装、监听器配置、共享磁盘规划、数据库创建以及MSCS资源组和故障转移规则的建立并针对11g与19c两个版本分别给出关键步骤和差异点。整份资源为单个PDF文件包体大小6.8MB以清晰的界面截图配合文字说明呈现从环境检查到群集验证的全流程可直接按步骤操作。当前已有1338人学习下载整理者将部署过程拆解为可跟做的动作并注明容易忽略的选项能有效帮助读者规避OracleMSCS组合下的常见配置陷阱缩短生产环境搭建时间。1. Windows Server 2019 MSCS 下部署 Oracle 11g/19c这套方案解决的是双机热备不是 RAC先说结论Windows Server 2019 自带故障转移群集MSCS配合 Oracle 11g/19c 单实例是很多中小企业做数据库高可用的首选。它的思路和 Oracle RAC 完全是两码事——RAC 是多节点同时在线提供服务的横向扩展MSCS 则是主备切换同一时间只有一台机器持有数据库服务另一台待命。对大多数业务系统来说这种主备模式足够扛住单点故障而且部署和维护成本比 RAC 低得多。真正上手后你会发现难点不在 Oracle 安装而在共享磁盘的归属、服务启动顺序、群集资源依赖这些细节上。这份项目文档把 Windows Server 2019 故障转移群集Oracle 11g/19c 的部署步骤写得很细从域环境要求、第一台数据库服务器安装 Oracle、netca 配监听、dbca 建库到群集资源组配置都有覆盖。适合两类人一是刚接手 Windows 平台数据库高可用的运维照着文档能完整复现二是已经被 RAC 折腾怕了、想评估主备方案是否够用的 DBA。2. Oracle 11g 安装与基础配置从解压到 dbca 建库的完整操作链2.1 安装前的环境基线与账号准备文档给了很明确的环境要求域控服务器至少一台Oracle 数据库服务器两台操作系统统一 Windows Server 2019 Standard x64群集环境用系统自带的故障转移群集。这个基线不是随便定的——MSCS 群集机制本身强依赖域环境来做节点身份验证和 Kerberos 票据支持Oracle 服务也要用域账号跑所以域控是必须先立的。两台数据库服务器建议配置一致包括 CPU、内存、磁盘控制器和网卡型号。这个一致性要求看起来像玄学实际是 MSCS 群集验证向导的标准检查项硬件差异过大会直接导致验证失败。Oracle 安装包要放在 D 盘如果安装包是分段压缩的像文档里说的两个压缩包需要同时选中右键解压到同一目录不能分开解压。注意服务器名不建议用中文建议不超过 15 个字符且不要带特殊符号。Windows Server 2019 对计算机名长度限制比较严格Oracle 安装程序对路径也很敏感。Oracle 服务账号用域账号例如CORP\oracle_service这个账号要提前加进两台服务器的本地管理员组并且要给予“作为服务登录”的权限。否则后面把 Oracle 服务注册进群集时会出现服务无法启动的问题。2.2 软件安装的四个关键选择跳过更新、仅装软件、单实例、企业版运行 setup 之后有一连串选项文档里几乎每步都给了明确答案不勾选“我希望通过 My Oracle Support 接收安全更新”选择“跳过软件更新”安装选项选“仅安装数据库软件”而不是“创建和配置数据库”安装类型选“单实例数据库安装”。这四个选择背后是有逻辑的。跳过更新是为了不在生产环境触发额外的网络请求仅安装数据库软件是因为建库这件事要放到后面用 dbca 单独做而且群集环境的数据文件必须建在共享磁盘上安装阶段就建库会把数据文件落到本地盘单实例数据库安装对应的是 MSCS 主备架构选“Oracle Real Application Clusters”就变成 RAC 了。企业版和标准版的差异主要在分区、OLAP、数据挖掘这些高级组件上生产环境一般直接企业版避免后续功能受限。安装路径建议直接默认的 D:\app\oracle\product\11.2.0\dbhome_1两个节点要保证 Oracle Home 的路径完全一致。路径不一致会导致故障切换后服务找不到程序文件。2.3 netca 配置监听协议、端口和节点一致性Oracle 11g 装完后第一件事是配监听文档是用 netca 图形工具做的运行窗口输入 netca选“监听程序配置”选“添加”协议保持默认 TCP端口用标准端口 1521。配置完成后继续选“否”不配置另一监听程序。监听这一步有两个容易忽略的细节。一是两台节点都要配监听而且配置结果要一致二是如果节点名带大写listener.ora 里的主机名要确保能通过 DNS 解析成节点自己的 IP。Oracle 的 PMON 进程注册数据库服务时用的是 hostname解析不对会导致切换后客户端连不上。实际生产里我更建议在 netca 之外手动加一份静态注册配置。因为动态注册有个特点实例起来后要过一段时间 PMON 才会把服务名注册给监听故障切换后如果立刻有连接进来很可能报 ORA-12514。静态注册可以让监听启动时就明确知道有哪些 SID 和服务名。2.4 dbca 建库参数解读pacs 实例、内存占比、进程数与字符集监听配好后在共享磁盘上创建 orcldata 目录然后运行 dbca 建库。文档给了一套可抄的参数全局数据库名 pacs数据库类型“一般用途或事务处理”数据库文件放公共位置 orcldata快速恢复区按需指定内存占比按物理内存实际情况调整并以 80 为例进程数改为 600数据库字符集选“美国英语”国家字符集选 UTF8默认语言英语美国默认地区英国。这套参数看似简单但对生产环境很有参考价值。内存占比填 80 指的是 Oracle 自动化内存管理能用的物理内存比例比如 32G 内存的机器Oracle 最多能向系统申请 25.6G。进程数 600 是 processes 参数这个值直接影响数据库最大连接数默认 150 对稍微有点并发业务的应用都不够改成 600 是合理的。字符集这块文档里说的“美国英语”并不是字面意义上的 US7ASCII而是建议不要选 ZHS16GBK 这类多字节中文编码直接用 AL32UTF8。语言选择英语美国、地区选择英国是为了避免 Windows 区域设置引发日期格式或排序规则的坑。两个节点的数据库名要一致包括 dbca 里的全局数据库名pacs和 ORACLE_SID这个值在后面注册群集资源时要一一对上。3. 故障转移群集搭建前的硬指标网络、存储与仲裁3.1 网络规划业务、心跳和 DNS 的分工搭建 MSCS 前网络规划比大多数人想象的重要。Windows Server 2019 故障转移群集至少需要两类网络业务网络供客户端连接使用心跳网络也称私有网络供群集节点间传递状态信息和握手信号。业务网络用生产环境 VLAN配置两个节点各一个静态 IP外加一个群集虚拟 IP这个虚拟 IP 就是客户端连接的入口。心跳网络用独立的两张网卡直连或走独立交换机配置 172.16.x.x 这类私有地址段不要配置网关也不要接业务交换机。心跳不通时群集会误判节点故障进而触发不必要的故障切换这就是文档环境要求里没有体现但实际部署绕不开的硬指标。在两台服务器的故障转移群集管理器里要把用于心跳的网卡勾选“仅用于内部群集通信”同时不要把 DNS 注册勾到这块网卡上。DNS 里需要提前创建好群集名称和群集 IP 的 A 记录不然群集创建时注册会报错。3.2 共享存储盘符、格式化和多路径MSCS 和 Oracle 的搭配核心就是共享磁盘上的数据文件。两台服务器同时挂载同一个 LUN但这个 LUN 同一时刻只允许持有群集资源的节点读写。常见的共享存储方案是光纤存储 SAN 或 iSCSI。第一件事是给两台服务器都装上 MPIO多路径 I/O功能并把存储阵列的多路径软件装好。Windows Server 2019 在“添加角色和功能”里勾选“多路径 I/O”即可。不装 MPIO 的话在某些 HBA 卡或 iSCSI 场景下会导致存储路径不稳定群集验证时 Storage 测试直接失败。共享磁盘在第一次挂载时建议只在第一台服务器上做初始化、分区和格式化。格式化用 NTFS盘符建议选一个不常用的字母如 R并给卷标加上便于识别的名称。第二台节点不要做任何初始化操作直接到磁盘管理里把磁盘联机确认能看到同样的卷和盘符。文档里创建 orcldata 目录就建在这个共享盘上后续 dbca 生成的数据库文件全部落到这里。注意共享磁盘不要启用 BitLocker 加密也不要用动态磁盘MSCS 对动态磁盘支持很差容易导致资源挂载失败。3.3 仲裁与见证决定脑裂后谁能活下来群集仲裁机制很少被第一次部署的人重视但它决定了节点之间通信中断时哪边能继续提供服务。故障转移群集会根据仲裁配置计算“投票权”默认情况下每个节点拥有一票决策时需要多数投票才能让群集继续运行。两台节点的群集如果只靠节点自己投票一旦心跳断裂两边各持一票就陷入僵局群集可能完全瘫痪。Windows Server 2019 的群集向导推荐配置“文件和文件共享见证”也就是利用域控或 NAS 上的一个共享文件夹作为第三票。这个见证文件夹不需要多大能放几个文件就行推荐至少 50MB 空间。文档没提仲裁配置但实际生产里这一步不做故障切换往往会在关键时刻翻车。创建见证时要注意见证路径建议不要建在群集内任意一个节点的本地磁盘上而要放在域控服务器或其他独立的存储上否则节点宕机时见证也跟着失效起不到作用。4. MSCS 资源组配置与 Oracle 服务注册让切换真正自动起来4.1 创建群集安装功能、验证、New-Cluster 三步走群集功能的安装在 Windows Server 2019 上非常快PowerShell 一行命令就能解决但后面的验证环节需要仔细看结果。先在两台服务器上执行Install-WindowsFeature Failover-Clustering -IncludeManagementTools这条命令安装故障转移群集角色和图形化管理工具。-IncludeManagementTools必须带上否则只能在命令行下操作群集不方便后面做角色配置和资源管理。安装完成后执行群集验证。验证这一步相当耗时它会检查节点清单、网络、存储、系统配置四类项目输出的报告会分级显示警告或错误严重错误必须修复警告最好也确认一下是不是能接受Test-Cluster -Node DB01,DB02 -Include Inventory, Network, Storage, System Configuration-Include参数可以指定要做哪些验证项目切割掉不需要的检测项能省不少时间。存储测试如果提示“该磁盘属于故障转移群集支持的存储类型”说明磁盘没问题如果提示“磁盘未通过验证”先检查两台服务器是否都安装了同样的 MPIO 功能。验证通过后创建群集建议用无存储创建模式New-Cluster -Name ORACLECLS -Node DB01,DB02 -NoStorage -StaticAddress 10.10.20.50-NoStorage让群集创建时不自动接管共享磁盘等后续手工添加避免本地磁盘被意外纳入群集。-StaticAddress指定群集虚拟 IP这个 IP 会随着群集资源在节点间漂移客户端连接数据库时就用这个地址。4.2 把 Oracle 服务注册成群集资源群集创建完成后的关键工作是把 Oracle 相关服务交给群集控制。首先要改两个服务的启动类型OracleServicePACS 和 OracleOraDb11g_home1TNSListener。在服务管理器里把启动类型改成“手动”确保节点开机时不会自己拉起 Oracle只有群集判定资源组应该在这个节点运行时才启动。然后打开故障转移群集管理器右键“角色”选择“配置角色”选择“通用服务”把 OracleServicePACS 添加进去。同样的方法再添加监听服务。也可以直接用 PowerShell 注册命令如下Add-ClusterGenericServiceRole -ServiceName OracleServicePACS -Name Oracle DB Role-ServiceName是 Oracle 服务在 Windows 服务管理器里显示的名称名称规则一般是 OracleService 全局数据库名所以这里是 OracleServicePACS要和 dbca 建库时指定的数据库名完全一致。-Name是给这个群集角色起的显示名后续资源组、依赖配置都围绕这个名称展开。4.3 依赖关系配置磁盘、IP、服务和启动顺序Oracle 数据库服务单独注册成角色还不够必须把共享磁盘和群集 IP 两个资源加进同一个资源组并配置依赖关系。正确顺序是共享磁盘先联机群集 IP 地址先联机Oracle 服务后启动。在故障转移群集管理器中找到 Oracle 服务资源右键属性切到“依赖”页签添加对磁盘资源和 IP 地址资源的依赖。PowerShell 里也可以这样确认Get-ClusterResource -Name Oracle DB Role | Get-ClusterParameter依赖关系配置不对的话最常见的症状是切换后资源组处于失败状态报错是“由于依赖的资源不存在或尚未联机无法启动该资源”。两个依赖资源要并列添加不要用 AND 连接故障切换时群集会按依赖顺序自动启动。监听服务也要放进同一个资源组并依赖群集 IP。如果不把监听托管给群集故障切换后数据库实例起来了、群集 IP 漂移到了新节点但监听还停留在老节点上客户端连接就会报 ORA-12514。这是整个部署里最容易被遗漏的一步。4.4 客户端连接路径与连接串配置群集部署完成后客户端连接必须使用群集虚拟 IP而不是任何一台物理服务器的 IP。tnsnames.ora 里的 HOST 改成群集虚拟 IP例如PACS (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 10.10.20.50)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME pacs) ) )这段配置里没有写错选项的余地HOST 是群集虚拟 IPSERVICE_NAME 是全局数据库名 pacs。故障切换发生时虚拟 IP 会在几十秒内漂移到备用节点Oracle 服务和监听资源也随之启动客户端已经建立的连接会断开但重连机制可以基于这个连接串自动恢复。5. 实战避坑故障切换场景里的五条常见问题记录5.1 现象切换后 Oracle 服务一直处于“启动中”资源组失败故障切换演练时把资源组移到备用节点后群集状态显示“失败”事件日志里能看到 OracleServicePACS 服务启动失败的记录。原因是服务没有完全归群集管控比如服务在备用节点上仍被设置为自动启动触发了两节点同时抢占数据库实例或者服务账号权限不够无法在备用节点上启动。解决方法是先把备用节点上的 Oracle 服务设置为手动启动确保群集是唯一启动源。账账号方面域账号要在两台服务器上都有“作为服务登录”权限并且是本地管理员组成员。调整后把资源组移动到备用节点再手动执行一次启动验证。5.2 现象ORA-12514 提示监听无法识别服务名故障切换完成后用 sqlplus 连接报 ORA-12514 TNS 监听器无法解析服务名。原因通常是监听服务没有加入群集资源组实例发起动态注册时注册请求还发到老节点的监听里而老节点上的数据库实例已经停止。解决方法把监听服务也添加为群集角色并配置依赖群集 IP。如果还想更保险在 listener.ora 中配置静态注册加上SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME pacs) (ORACLE_HOME D:\app\oracle\product\11.2.0\dbhome_1) (SID_NAME pacs) ) )静态注册的意义在于数据库还没完全启动、PMON 还没有向监听注册时客户端就能通过监听找到服务。特别是故障切换后的秒级重连静态注册能省掉动态注册的等待时间。5.3 现象群集验证 Storage 项目报错磁盘无法识别为群集存储Test-Cluster 报告里 Storage 标红检查发现系统能识别 LUN但磁盘管理里看不到盘符或者磁盘状态是“保留”。这是因为两台服务器的多路径配置不一致或者磁盘初始化只在其中一台上做过。解决方法是确认两台服务器都安装了同版本 MPIO 和存储多路径软件然后在有盘符的节点上重新扫描磁盘再到另一节点上执行磁盘联机。存储层面的改动要在群集创建前完成群集创建后再折腾存储容易引发仲裁重建问题。5.4 现象心跳网卡断开后整个群集停摆而不是自动切换节点之间心跳中断按理说辅助节点应该接管服务结果群集直接进入停止状态业务全部中断。原因是仲裁配置没有见证资源两个节点各持一票谁也说服不了谁群集状态进入“仲裁丢失”。解决方法就是前面章节提到的配置一个文件共享见证或磁盘见证。配置路径在故障转移群集管理器的“更多操作”里运行配置群集仲裁向导选择“选择仲裁见证”并指向域控上的共享文件夹。见证配置好后即使心跳断了存活节点和见证保持通讯就能拿到多数投票继续提供服务。5.5 现象群集服务正常但数据库数据文件被损坏最严重的情况是共享盘上的数据文件损坏ORA-01115 这类 I/O 错误出现在告警日志里。排查发现两个节点在启动时都自动挂载了共享磁盘并且都尝试启动 Oracle 服务发生并发写入文件系统层面已经出了问题。这个问题的直接原因就是服务启动类型没改成手动。Oracle 软件装在本地盘数据文件在共享盘如果节点开机时服务自动启动两个节点都会去挂载共享盘并启动实例而共享盘同一时刻只允许一个节点写入。解决方法是严格把 OracleService 和监听服务都改为手动启动并确认共享磁盘没有在磁盘管理里被设置为开机自动联机。群集资源联机时由群集服务负责挂载不要靠 Windows 系统本身去挂。6. 19c 部署差异与故障切换验证做完演练才算交付6.1 11g 到 19c 的安装差异对比19c 的整体部署逻辑和 11g 完全一致也是两台机器、共享磁盘、MSCS 主备但有几处细节需要注意。安装包解压方式一样运行 setup 时 19c 的安装界面更精简安装类型仍然选“仅安装数据库软件”企业版默认勾选。安装过程可能会在预检查阶段卡在“网络配置”或“操作系统要求”上Windows Server 2019 一般不会有大问题遇到个别检查不通过可以直接忽略。字符集和内存配置沿用 11g 的参数即可。19c 在默认安装时会推荐 AL32UTF8国家字符集 UTF8这和 11g 文档的做法一致。19c 的 Oracle Home 目录默认路径也可以放到 D:\app\oracle\product\19.0.0\dbhome_1两节点保持一致。dbca 建库的参数里processes 同样可以拉到 600内存占比按物理内存调整。6.2 19c 的静默安装响应文件最稳图形界面安装步骤繁琐而且 19c 的响应文件比 11g 更成熟生产环境我一般直接用静默安装。响应文件关键片段如下oracle.install.responseFileVersion/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0 oracle.install.optionINSTALL_DB_SOFTWARE_ONLY oracle.install.db.InstallEditionEE oracle.install.db.OSDBA_GROUPORA_DBA oracle.install.db.OSOPER_GROUPORA_OPER oracle.install.db.OSBACKUPDBA_GROUPORA_BACKUPDBA oracle.install.db.OSDGDBA_GROUPORA_DGDBA oracle.install.db.OSKMDBA_GROUPORA_KMDBAINSTALL_DB_SOFTWARE_ONLY对应图形界面里的“仅安装数据库软件”InstallEdition对应企业版后面几个参数是 19c 需要的操作系统用户组。Windows 平台执行时用D:\app\setup.exe -silent -responseFile D:\soft\db_install.rsp-silent表示静默安装-responseFile指向响应文件路径。安装完成后可以用 Oracle 的 OPatch 工具确认版本信息确认安装成功后再进行建库和群集配置。6.3 故障切换演练从 Administrator 的角度做一遍部署的最终验证不是“装好了”而是“切一次试试”。我用 PowerShell 做完整演练先把资源组移动到备用节点Move-ClusterGroup -Name Oracle DB Role -Node DB02群集角色名称要对齐第 4 章注册的名称。移动后等资源组联机再确认资源状态Get-ClusterGroup -Name Oracle DB Role返回状态如果是 Online继续验证数据库服务是否能正常响应。用 sqlplus 通过群集虚拟 IP 连接sqlplus system/你的口令10.10.20.50:1521/pacs连接成功后再查看监听服务的注册情况lsnrctl services确认列表里能看到 pacs 实例。这套验证跑通了主备切换才算真正完成。我一般还会在切换前后各跑一次查询确认数据库实例确实是在新节点上提供服务而不是靠旧节点的残留进程作弊。从那以后我每次给客户交付这类群集项目都会强制走一遍故障切换演练并把所有命令输出截图存档。群集这种系统平时没故障时像玄学真出问题靠的就是这些演练记录。希望帮到你。本文还有配套的精品资源点击获取