简介面向数据库管理员、系统运维人员及高可用架构师这份资源系统讲解在Windows Server 2019自带的故障转移群集环境下为Oracle 11g与19c搭建双机热备的完整实施流程。文档首先交代了域控服务器与两台数据库节点的环境要求以及将服务器纳入域、准备共享磁盘等前置条件随后按照实际操作顺序详细演示数据库软件的解压安装、企业版与单实例模式选择、监听程序配置、共享磁盘中数据库文件与快速恢复区的创建再到故障转移群集的验证、资源组配置和故障转移规则设定。针对Oracle 11g与19c两个版本在安装选项和界面上的差异文档单独给出了对比说明和实战建议能帮助读者避开共享存储权限不足、监听注册失败、群集验证不通过等常见陷阱。资源包含一个PDF文档压缩包大小6.8MB通篇图文配合关键步骤和参数都有截图标注适合在实施时参照操作。目前已有1338人学习下载是Windows平台下Oracle高可用部署的实用参考手册。1. 为什么说MSCS下的Oracle故障转移群集比RAC更“务实”当你的核心库跑在一个Windows服务器上凌晨两点突然宕机你接到电话客户问多久能恢复。单机情况下只能指望快速重启如果搭了基于Microsoft Cluster ServiceMSCS的Oracle故障转移群集另一个节点会在30秒内接管虚拟IP、磁盘和Oracle服务业务往往几分钟内恢复。这是Oracle 11g和19c在Windows Server 2019上最常见的低成本高可用方案常和Oracle RAC对比RAC两套实例并发跑花钱多管理复杂MSCS两套软件共享一份数据文件同一时刻只有一个节点提供服务但配置直观由Windows群集统一管理。这篇笔记按“先规划、后建群集、再装Oracle、最后验证”顺序把步骤和坑写清楚。适合预算有限、对横向扩展没需求、主要想解决“服务器宕机不能长时间停业务”的DBA或系统工程师。2. 动手前的规划网络、共享磁盘、DNS与群集角色2.1 先分清MSCS和RAC两种高可用两种花钱方式MSCS现在通常叫Windows Server Failover ClusteringWSFC由Windows自带管理一组服务器作为“节点”节点之间通过心跳网络监控状态共享一套存储。群集把虚拟IP、共享磁盘、数据库服务封装成一个“角色”当某个节点故障时角色连磁盘和IP一起漂移到健康节点。Oracle在这套机制下应用的是故障转移群集实例对客户端来说始终只有一个IP和一个数据库实例。Oracle RAC则是另一种形态需要额外购买Grid Infrastructure和ASM多个节点同时打开同一个数据库通过高速互联做Cache Fusion。RAC能提供负载均衡和故障转移但要求共享存储必须使用ASM还要考虑OCR、Voting Disk这些组件部署复杂度和License成本都高出一大截。如果业务还没到“吞吐量不够”的程度用MSCS把宕机恢复时间控制在几分钟内性价比远高于直接上RAC。团队里有人问“为什么不用RAC”时可以算这笔账MSCS只保护“节点故障”RAC还保护“性能瓶颈”两种目的不一样。标题里的Oracle 11g和19c在MSCS模式下用的都是同一套原理。2.2 计算节点与共享存储的选型iSCSI还是本地虚拟盘要实现MSCS下的Oracle故障转移第一前提是共享存储必须能被两个节点同时看到但同一时刻只有活跃节点能读写。生产环境最常用的是SAN或中高档NAS通过光纤或iSCSI给两台Windows Server 2019服务器各分配同一块LUN。测试环境如果你想用VMware或Hyper-V搭实验平台可以给两台虚拟机添加同一块虚拟SCSI盘并把该SCSI控制器设置为“共享模式”例如VMware里选择“SCSI控制器共享虚拟磁盘”。有一点要提醒共享虚拟盘不能放在虚拟机本身的虚拟磁盘上而要单独挂在专用控制器上否则会发现第二个节点无法同时打开。选型无非是考虑成本生产必须用企业级存储测试可以用共享虚拟盘但别把生产能跑多久押在低端NAS上。2.3 规划表IP、主机名、服务名、磁盘盘符这块很多人跳过直接开装最后一步错一步。我习惯先在纸上画一张表把以下信息固定下来角色节点1节点2主机名oradb01oradb02管理IP192.168.1.21192.168.1.22心跳IP192.168.100.1192.168.100.2群集虚拟IP192.168.1.200客户端访问同左共享数据盘盘符Q:两个节点上必须一致Q:两个节点上必须一致共享仲裁盘S:S:Oracle版本11g R2 或 19c同左数据库服务名ORCLORCL每个节点需要至少两块物理网卡一块跑业务和管理一块做心跳Heartbeat。心跳网络可以用独立VLAN、虚拟交换机也可以点对点直连。DNS中要提前注册好群集名称、两个节点主机名的A记录虚拟IP可以由群集自动创建但最好也静态登记避免客户端解析到旧IP。磁盘盘符特别容易踩坑Windows 2019在重启后可能给共享磁盘分配另一个盘符所以后面要通过群集磁盘的盘符参数固定。仲裁盘的作用是当两个节点通信中断时根据盘内状态确定哪一边获得群集所有权。两节点群集强烈建议配置仲裁盘只靠投票会让脑裂风险急剧上升。还需要准备一台域控制器因为Windows故障转移群集要求所有节点在同一个域内并且运行群集的账号要能对两个节点有管理员权限。这一步不要用工作组的模式除非你在实验室里敢用不安全的证书背书。3. 在Win Server 2019上把故障转移群集建起来3.1 准备环境加入域、安装群集功能、打开防火墙端口把两台Windows Server 2019物理机或虚拟机加入域后先统一改好主机名、设置固定IP和DNS。接着在两台节点上分别安装故障转移群集功能。最省事的做法是打开PowerShell以管理员身份执行Add-WindowsFeature Failover-Clustering -IncludeManagementTools安装完成后不需要重启。然后需要确保“远程服务器管理工具”里的Failover Cluster Manager可用。防火墙方面群集依赖的设备管理、SMB、RPC等端口Windows在启用功能时会自动创建规则但我们还是要确认“Windows防火墙”服务没有因项目组的安全策略被强关一般建议保持自动放行。此时可以用Get-Cluster来验证基本网络配置。3.2 用Test-Cluster验证群集前检查在没有创建群集前先用官方验证工具跑一遍它能提前发现存储访问、网络绑定不对、节点不统一等雷区。在节点1上执行Test-Cluster -Node oradb01,oradb02 -Include Storage,Network,System Configuration -ReportName C:\ClusterTest把重点放在Storage和Network两类。Storage检查会尝试对两个节点看到的共享盘做读写如果某个磁盘不是“共享磁盘”类型这里会直接警告。Network检查会列出每张网卡的绑定顺序和IP心跳网络必须使用独立的子网否则它无法区分业务流量和心跳流量。运行大概几分钟后会生成一份HTML报告把所有的Error和Warning逐条看过再动手不要无视警告。3.3 用New-Cluster创建群集并添加共享磁盘验证通过后在节点1上创建群集。最小命令New-Cluster -Name oracluster -Node oradb01,oradb02 -NoStorage -StaticAddress 192.168.1.200参数说明-Name是群集名称冲突时会在DNS自动注册-NoStorage先不添加磁盘防止还没准备完盘符时被误用-StaticAddress为客户端访问用的虚拟IP指定静态地址。随后把两个共享磁盘加入群集并设置盘符Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterDisk | Select Name,Size然后为磁盘分配盘符。这一步在Failover Cluster Manager的“磁盘”栏里右键共享磁盘从属性里设置“驱动器号”或通过资源依赖来固定。PowerShell里可以用Set-ClusterDiskResource -Name Cluster Disk 1 -DiskNum 1 -Path Q:注意Set-ClusterDiskResource的参数在不同版本里有差异你在图形界面里同样可以改盘符。关键是两个节点上看到的盘符必须完全一致并且不要在Windows的磁盘管理里随便改因为群集资源的依赖关系中保存了盘符。3.4 配置仲裁见证两节点群集需要一个额外的投票者来避免脑裂。可以用第三个节点或者更简单的“文件和共享见证”放在另一台非群集服务器上也可以用“云见证”。常见做法是在域内一台服务器上共享一个文件夹并给予群集计算机写入权限。设置命令Set-ClusterQuorum -NodeAndFileShareMajority \\dc01\ClusterWitness参数说明-NodeAndFileShareMajority表明由节点和文件共享共同投票文件共享本身在DC上。注意仲裁盘和文件共享见证不要选在其中一个可能丢失的路径上。配置完成后查看群集正常运行Get-ClusterNode | Format-Table Name, State, NodeWeight此刻你应该看到两个节点的状态都是Up群集名称解析正常。在开始Oracle安装前重新启动任意一个节点验证群集会把该节点状态标成Down待节点回来后自动加入。如果这一步都没问题再向下走。4. 安装Oracle 11g/19c并与MSCS结合4.1 两个节点上的Oracle软件安装参数本地盘安装、启用群集支持Oracle在这一步更看重“一致性”两个节点上的Oracle Home路径必须一模一样否则切换后服务找不到文件。我一般把Oracle Base设置在C:\Oracle\BaseOracle Home在C:\Oracle\Home\dbhome_1。这样避开Program Files目录里的空格因为Windows群集在启动服务时偶尔会对路径引号的解析出幺蛾子。在节点1上运行Oracle安装程序选择“仅安装数据库软件”在“安装模式”里务必选择“Oracle Failover Cluster安装”或检测到Windows群集时选择“Microsoft Cluster Server支持”。在11g中会有“启用Microsoft Cluster Server”选项19c中称为“Oracle Failover Cluster support”。这个组件的本质是安装Oracle Services for MSCS用来让群集管理器能接管Oracle相关服务。安装完成后不要急着建库把同样的安装步骤在节点2上重做一遍。节点2不需要建库只需要把Oracle软件装进相同的Home路径并且确保两个节点的ORACLE_HOME\database目录结构一致。此时先不要启动任何Oracle实例服务因为还没建库。4.2 在共享盘上用SQL脚本建库控制每个文件的路径共享数据盘已经挂载为Q盘下一步是在Q盘上创建数据库目录结构。使用DBCA固然方便但DBCA默认会在每个节点本地放部分文件很容易破坏群集的“单一文件集”。我习惯手动建库先创建Q:\oradata\ORCL目录然后在节点1上把实例启动到nomount执行如下SQLCREATE DATABASE ORCL MAXINSTANCES 1 MAXLOGFILES 32 MAXDATAFILES 100 CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 LOGFILE GROUP 1 (Q:\ORADATA\ORCL\REDO01.LOG) SIZE 200M, GROUP 2 (Q:\ORADATA\ORCL\REDO02.LOG) SIZE 200M DATAFILE Q:\ORADATA\ORCL\SYSTEM01.DBF SIZE 500M AUTOEXTEND ON NEXT 200M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\SYSAUX01.DBF SIZE 400M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\UNDOTBS01.DBF SIZE 400M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\USERS01.DBF SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED CONTROLFILE REUSE SET STANDBY NONE;这段SQL指定了所有数据文件、控制文件和联机日志都在Q盘。MAXINSTANCES设为1因为故障转移群集同一时刻只有一个实例打开数据库。执行完记得在ORACLE_HOME\database下创建PFILE或SPFILE并让SPFILE指向Q盘位置。SPFILE内容要设置*.db_nameORCL、*.db_create_file_destQ:\ORADATA以及监听相关参数。然后创建口令文件orapwd FILEC:\Oracle\Home\dbhome_1\database\PWDORCL.ORA ENTRIESUSER,SYS PASSWORD口令 FORCEY建库完成后关闭实例绝对不要在节点1启动着库时就向群集注册服务避免双节点同时挂载共享盘。4.3 把Oracle服务和监听器注册成群集资源数据库文件一旦落地共享盘两个节点上的Oracle服务比如OracleServiceORCL和OracleOraDb11g_home1TNSListener或19c的监听器都需要在系统中存在但群集资源管理器负责按角色启动哪一侧服务。最省事的做法是把这两个Windows服务作为“通用服务”资源加入同一个角色依赖关系设为共享磁盘和虚拟IP。打开Failover Cluster Manager在角色上右键“新建角色”选“通用服务”分别选中这两个Oracle服务然后设置依赖为“Cluster Disk 1”和“Cluster IP”。如果没有图形界面可以在PowerShell里用Add-ClusterGenericServiceRole在这里给出一个近似可用的样例Add-ClusterGenericServiceRole -Name OracleDBRole -ServiceName OracleServiceORCL -StaticAddress 192.168.1.200 Add-ClusterGenericServiceRole -Name OracleListRole -ServiceName OracleOraDb11g_home1TNSListener -StaticAddress 192.168.1.200注意上面命令中监听器服务名要换成你安装版本的实际服务名。两个角色都要指定相同静态IP并让监听器依赖数据库服务。用Set-ClusterGenericServiceRoleDependency设置依赖关系例如Set-ClusterGenericServiceRoleDependency -Role OracleListRole -Dependency OracleDBRole, Cluster Disk 1这里Cluster Disk 1是共享数据盘资源名。注册完成以后可以把角色名改成OracleDB然后将节点1的Oracle服务手动停止让群集把角色移到节点2验证监听和数据文件路径的可用性。要注意数据库里记录的监听器不能绑定本机IP而要绑定虚拟IP否则客户端切换后照样连不上。4.4 配置Oracle服务的启动属性不用自动、交给群集两个节点上各设置Oracle服务为“手动”启动而不是“自动”因为Windows启动时如果自动拉起Oracle但此时群集还没把磁盘所有权交给该节点会导致数据库以错误顺序挂载。更糟的是如果两个节点同时启动Oracle尝试打开同一数据文件会产生文件锁冲突。在Oracle服务属性中把“启动类型”改为“手动”并在故障那台机器上不要通过services.msc手工启停一切切换都通过群集管理器来触发。这个细节是很多初次部署的人翻车的地方——往往只做了群集却没卸掉本地服务自动启动结果切换时多了一堆僵尸进程。5. 故障转移群集部署避坑五条实操血泪5.1 共享磁盘盘符漂移导致Oracle启动失败现象一键切换后数据库实例起不来告警日志显示ORA-00205: error in identifying control file或找不到数据文件。原因Windows重新启动后把共享盘的盘符从Q改成了R而群集资源注册的依赖还是旧盘符Oracle的参数文件写的是Q:\ORADATA\...。解决在群集磁盘资源属性中固定盘符或使用NTFS挂在目录Mount Point来替代盘符同时调整两个节点磁盘管理界面让它们看到的共享盘符一致。我习惯在磁盘资源属性里把“路径”锁定为Q:再把Oracle的SPFILE和所有参数路径全部用Q:之后就再也没出现漂移。5.2 群集网络名/虚拟IP被DNS缓存卡住现象客户端报ORA-12545提示位置错误但通过ping虚拟IP可以通。原因虚拟IP变化后DNS缓存还持有旧地址或者群集的网络名称注册NetBIOS没及时更新。解决在群集网络资源属性中启用“DNS注册”把“传输网络名称”设为静态IP并在客户端执行ipconfig /flushdns。如果应用有持久连接池还需要在应用侧设定重连等待时间或采用连接串的autoReconnect。更稳妥的做法是在监听器listener.ora中把HOST设置为虚拟IP的变量例如LISTENER (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.200)(PORT 1521)) ) )不要用主机名否则群集切换时监听器无法自动绑上当前节点的虚拟IP。5.3 监听器没加入群集资源现象切换后数据库实例能起但应用连不上数据库检查监听是停止状态。原因很多人只把OracleServiceORCL加入角色而TNSListener仍是本地服务没有跟随虚拟IP一起漂移。解决把监听器服务也加入同一个故障转移角色并设置它依赖数据库服务和磁盘资源。在依赖关系里把监听器放在数据库服务之后启动否则节点刚接管磁盘时数据库还没mount监听器启动虽然成功但后续任何连接都会报ORA-01033。用群集管理器配置依赖列表把监听器角色的依赖设为数据库服务加磁盘即可。5.4 时间同步问题导致群集仲裁误判现象节点1和节点2都活着但群集频繁把其中一个节点踢出事件日志出现“节点已删除来自故障域”的警告。原因Windows群集对节点间时间差很敏感默认超过5分钟偏差就会被判定为“无心跳”。如果不同节点分别用不同NTP源或未配置NTP很快就能跑到秒级偏差。解决让所有节点统一用域控制器的NTP源并在节点上检查w32tm /query /status。如果时间差较大立即执行w32tm /config /syncfromflags:domhier /update Restart-Service w32time身份验证也依赖Kerberos时间偏移过大会引发一系列偶发的连接失败。我在部署每个Windows群集项目后都会加一条计划任务每天凌晨检查一次时间差并报警。5.5 19c安装时Oracle基目录路径带空格现象Oracle 19c安装完成但建库时执行dbca报错Failed to get current updatable root或Path contains space之类。原因Oracle 19c默认推荐安装路径是C:\Program Files\Oracle\其中包含空格而Windows群集的资源监听服务在启动时无法正确解析带空格的命令字符串。解决安装时手动把ORACLE_BASE设置为C:\Oracle\BaseORACLE_HOME设为C:\Oracle\Home\dbhome_1并确保两个节点路径完全一致。另外注意不要把群集名称或虚拟IP也取成带空格Windows群集资源名不允许有空格否则故障转移时服务路径解析错乱。6. 验证故障转移的三种手段和日常运维习惯6.1 用Failover Cluster Manager手动切换并观察日志建好群集、注册好Oracle角色后不要立刻宣布成功至少要跑一次手动切换。步骤是打开“故障转移群集管理器”选中角色OracleDB右键“移动”到节点2。转移过程中虚拟IP从节点1消失仲裁盘和共享盘也卸载然后节点2挂载并启动Oracle服务。切换结束后检查Get-ClusterResource -Name OracleDBRole | Get-ClusterResourceLog -Level Verbose | Out-String查看资源是否处于Online状态以及节点2上Oracle告警日志里有没有报错。同时用tnsping oracluster确认虚拟IP下的1521端口可通。这个手动切换至少来回做三次确认两个节点都能作为主节点承载数据库。6.2 用轮询事务脚本验证数据一致性故障转移群集最怕的是“切换是假的数据库一打开就回滚大量事务”。我习惯在业务不忙的时候放一个定时脚本每秒往测试表插一条带时间戳的记录。切换后查看时间戳是否连续如果连续说明共享盘、重做日志都可靠。下面是一段简单的PowerShell轮询脚本配合SQL*Plus执行while ($true) { $ts Get-Date -Format yyyy-MM-dd HH:mm:ss.fff $sql INSERT INTO QA.TEST_TABLE(COL_TS) VALUES (TO_TIMESTAMP($ts,YYYY-MM-DD HH24:MI:SS.FF3)); COMMIT; sqlplus -s user/passoracluster:1521/ORCL $sql | Out-Null Start-Sleep -Milliseconds 1000 }脚本里user/passoracluster:1521/ORCL中的oracluster是群集名称解析到虚拟IP。切换前后如果时间戳出现大于1秒的间隙表明服务中断时间超过预期如果完全没有缺口且表一直能插入说明实例确实接管的是同一份数据文件。也可以用一条SQL把总金额汇总查询作为健康检查但写入型探针比只读查询更能暴露文件锁和回滚问题。6.3 把群集日志纳入统一告警形成运维习惯故障转移群集不是一次性的部署日常监控要有重点。我会把Windows事件日志里的Microsoft-Windows-FailoverClustering/Operational和Oracle的alert_SID.log都纳入监控系统。至少每天查看一遍节点状态、资源状态并用计划任务把状态写入CSV。同时留意共享盘剩余空间因为数据文件都在Q盘如果Q盘爆掉切换后的实例同样会宕机。这里分享一个我自己的血泪教训第一次部署完这套方案时我认为只要数据库能起来就万事大吉却忘了把监听器服务加入角色。第二次演练时切换后应用连不上被领导当场指着屏幕问“为什么你画的架构图里没有监听器”。从那以后我每次都会在部署文档里附一张“资源依赖草图”把虚拟IP、磁盘、数据库服务、监听器四者画成一条链并标注它们的前后启动顺序。依赖决策其实很简单虚拟IP和磁盘最底层数据库服务次之监听器在最上层。理顺这条链故障转移群集这件事才算真正完工。希望这篇笔记能帮你在Windows Server 2019上把Oracle 11g或19c的故障转移群集搭起来少走几个月弯路。本文还有配套的精品资源点击获取 MSCS下Oracle故障转移群集在Windows Server上的部署与避坑
简介面向数据库管理员、系统运维人员及高可用架构师这份资源系统讲解在Windows Server 2019自带的故障转移群集环境下为Oracle 11g与19c搭建双机热备的完整实施流程。文档首先交代了域控服务器与两台数据库节点的环境要求以及将服务器纳入域、准备共享磁盘等前置条件随后按照实际操作顺序详细演示数据库软件的解压安装、企业版与单实例模式选择、监听程序配置、共享磁盘中数据库文件与快速恢复区的创建再到故障转移群集的验证、资源组配置和故障转移规则设定。针对Oracle 11g与19c两个版本在安装选项和界面上的差异文档单独给出了对比说明和实战建议能帮助读者避开共享存储权限不足、监听注册失败、群集验证不通过等常见陷阱。资源包含一个PDF文档压缩包大小6.8MB通篇图文配合关键步骤和参数都有截图标注适合在实施时参照操作。目前已有1338人学习下载是Windows平台下Oracle高可用部署的实用参考手册。1. 为什么说MSCS下的Oracle故障转移群集比RAC更“务实”当你的核心库跑在一个Windows服务器上凌晨两点突然宕机你接到电话客户问多久能恢复。单机情况下只能指望快速重启如果搭了基于Microsoft Cluster ServiceMSCS的Oracle故障转移群集另一个节点会在30秒内接管虚拟IP、磁盘和Oracle服务业务往往几分钟内恢复。这是Oracle 11g和19c在Windows Server 2019上最常见的低成本高可用方案常和Oracle RAC对比RAC两套实例并发跑花钱多管理复杂MSCS两套软件共享一份数据文件同一时刻只有一个节点提供服务但配置直观由Windows群集统一管理。这篇笔记按“先规划、后建群集、再装Oracle、最后验证”顺序把步骤和坑写清楚。适合预算有限、对横向扩展没需求、主要想解决“服务器宕机不能长时间停业务”的DBA或系统工程师。2. 动手前的规划网络、共享磁盘、DNS与群集角色2.1 先分清MSCS和RAC两种高可用两种花钱方式MSCS现在通常叫Windows Server Failover ClusteringWSFC由Windows自带管理一组服务器作为“节点”节点之间通过心跳网络监控状态共享一套存储。群集把虚拟IP、共享磁盘、数据库服务封装成一个“角色”当某个节点故障时角色连磁盘和IP一起漂移到健康节点。Oracle在这套机制下应用的是故障转移群集实例对客户端来说始终只有一个IP和一个数据库实例。Oracle RAC则是另一种形态需要额外购买Grid Infrastructure和ASM多个节点同时打开同一个数据库通过高速互联做Cache Fusion。RAC能提供负载均衡和故障转移但要求共享存储必须使用ASM还要考虑OCR、Voting Disk这些组件部署复杂度和License成本都高出一大截。如果业务还没到“吞吐量不够”的程度用MSCS把宕机恢复时间控制在几分钟内性价比远高于直接上RAC。团队里有人问“为什么不用RAC”时可以算这笔账MSCS只保护“节点故障”RAC还保护“性能瓶颈”两种目的不一样。标题里的Oracle 11g和19c在MSCS模式下用的都是同一套原理。2.2 计算节点与共享存储的选型iSCSI还是本地虚拟盘要实现MSCS下的Oracle故障转移第一前提是共享存储必须能被两个节点同时看到但同一时刻只有活跃节点能读写。生产环境最常用的是SAN或中高档NAS通过光纤或iSCSI给两台Windows Server 2019服务器各分配同一块LUN。测试环境如果你想用VMware或Hyper-V搭实验平台可以给两台虚拟机添加同一块虚拟SCSI盘并把该SCSI控制器设置为“共享模式”例如VMware里选择“SCSI控制器共享虚拟磁盘”。有一点要提醒共享虚拟盘不能放在虚拟机本身的虚拟磁盘上而要单独挂在专用控制器上否则会发现第二个节点无法同时打开。选型无非是考虑成本生产必须用企业级存储测试可以用共享虚拟盘但别把生产能跑多久押在低端NAS上。2.3 规划表IP、主机名、服务名、磁盘盘符这块很多人跳过直接开装最后一步错一步。我习惯先在纸上画一张表把以下信息固定下来角色节点1节点2主机名oradb01oradb02管理IP192.168.1.21192.168.1.22心跳IP192.168.100.1192.168.100.2群集虚拟IP192.168.1.200客户端访问同左共享数据盘盘符Q:两个节点上必须一致Q:两个节点上必须一致共享仲裁盘S:S:Oracle版本11g R2 或 19c同左数据库服务名ORCLORCL每个节点需要至少两块物理网卡一块跑业务和管理一块做心跳Heartbeat。心跳网络可以用独立VLAN、虚拟交换机也可以点对点直连。DNS中要提前注册好群集名称、两个节点主机名的A记录虚拟IP可以由群集自动创建但最好也静态登记避免客户端解析到旧IP。磁盘盘符特别容易踩坑Windows 2019在重启后可能给共享磁盘分配另一个盘符所以后面要通过群集磁盘的盘符参数固定。仲裁盘的作用是当两个节点通信中断时根据盘内状态确定哪一边获得群集所有权。两节点群集强烈建议配置仲裁盘只靠投票会让脑裂风险急剧上升。还需要准备一台域控制器因为Windows故障转移群集要求所有节点在同一个域内并且运行群集的账号要能对两个节点有管理员权限。这一步不要用工作组的模式除非你在实验室里敢用不安全的证书背书。3. 在Win Server 2019上把故障转移群集建起来3.1 准备环境加入域、安装群集功能、打开防火墙端口把两台Windows Server 2019物理机或虚拟机加入域后先统一改好主机名、设置固定IP和DNS。接着在两台节点上分别安装故障转移群集功能。最省事的做法是打开PowerShell以管理员身份执行Add-WindowsFeature Failover-Clustering -IncludeManagementTools安装完成后不需要重启。然后需要确保“远程服务器管理工具”里的Failover Cluster Manager可用。防火墙方面群集依赖的设备管理、SMB、RPC等端口Windows在启用功能时会自动创建规则但我们还是要确认“Windows防火墙”服务没有因项目组的安全策略被强关一般建议保持自动放行。此时可以用Get-Cluster来验证基本网络配置。3.2 用Test-Cluster验证群集前检查在没有创建群集前先用官方验证工具跑一遍它能提前发现存储访问、网络绑定不对、节点不统一等雷区。在节点1上执行Test-Cluster -Node oradb01,oradb02 -Include Storage,Network,System Configuration -ReportName C:\ClusterTest把重点放在Storage和Network两类。Storage检查会尝试对两个节点看到的共享盘做读写如果某个磁盘不是“共享磁盘”类型这里会直接警告。Network检查会列出每张网卡的绑定顺序和IP心跳网络必须使用独立的子网否则它无法区分业务流量和心跳流量。运行大概几分钟后会生成一份HTML报告把所有的Error和Warning逐条看过再动手不要无视警告。3.3 用New-Cluster创建群集并添加共享磁盘验证通过后在节点1上创建群集。最小命令New-Cluster -Name oracluster -Node oradb01,oradb02 -NoStorage -StaticAddress 192.168.1.200参数说明-Name是群集名称冲突时会在DNS自动注册-NoStorage先不添加磁盘防止还没准备完盘符时被误用-StaticAddress为客户端访问用的虚拟IP指定静态地址。随后把两个共享磁盘加入群集并设置盘符Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterDisk | Select Name,Size然后为磁盘分配盘符。这一步在Failover Cluster Manager的“磁盘”栏里右键共享磁盘从属性里设置“驱动器号”或通过资源依赖来固定。PowerShell里可以用Set-ClusterDiskResource -Name Cluster Disk 1 -DiskNum 1 -Path Q:注意Set-ClusterDiskResource的参数在不同版本里有差异你在图形界面里同样可以改盘符。关键是两个节点上看到的盘符必须完全一致并且不要在Windows的磁盘管理里随便改因为群集资源的依赖关系中保存了盘符。3.4 配置仲裁见证两节点群集需要一个额外的投票者来避免脑裂。可以用第三个节点或者更简单的“文件和共享见证”放在另一台非群集服务器上也可以用“云见证”。常见做法是在域内一台服务器上共享一个文件夹并给予群集计算机写入权限。设置命令Set-ClusterQuorum -NodeAndFileShareMajority \\dc01\ClusterWitness参数说明-NodeAndFileShareMajority表明由节点和文件共享共同投票文件共享本身在DC上。注意仲裁盘和文件共享见证不要选在其中一个可能丢失的路径上。配置完成后查看群集正常运行Get-ClusterNode | Format-Table Name, State, NodeWeight此刻你应该看到两个节点的状态都是Up群集名称解析正常。在开始Oracle安装前重新启动任意一个节点验证群集会把该节点状态标成Down待节点回来后自动加入。如果这一步都没问题再向下走。4. 安装Oracle 11g/19c并与MSCS结合4.1 两个节点上的Oracle软件安装参数本地盘安装、启用群集支持Oracle在这一步更看重“一致性”两个节点上的Oracle Home路径必须一模一样否则切换后服务找不到文件。我一般把Oracle Base设置在C:\Oracle\BaseOracle Home在C:\Oracle\Home\dbhome_1。这样避开Program Files目录里的空格因为Windows群集在启动服务时偶尔会对路径引号的解析出幺蛾子。在节点1上运行Oracle安装程序选择“仅安装数据库软件”在“安装模式”里务必选择“Oracle Failover Cluster安装”或检测到Windows群集时选择“Microsoft Cluster Server支持”。在11g中会有“启用Microsoft Cluster Server”选项19c中称为“Oracle Failover Cluster support”。这个组件的本质是安装Oracle Services for MSCS用来让群集管理器能接管Oracle相关服务。安装完成后不要急着建库把同样的安装步骤在节点2上重做一遍。节点2不需要建库只需要把Oracle软件装进相同的Home路径并且确保两个节点的ORACLE_HOME\database目录结构一致。此时先不要启动任何Oracle实例服务因为还没建库。4.2 在共享盘上用SQL脚本建库控制每个文件的路径共享数据盘已经挂载为Q盘下一步是在Q盘上创建数据库目录结构。使用DBCA固然方便但DBCA默认会在每个节点本地放部分文件很容易破坏群集的“单一文件集”。我习惯手动建库先创建Q:\oradata\ORCL目录然后在节点1上把实例启动到nomount执行如下SQLCREATE DATABASE ORCL MAXINSTANCES 1 MAXLOGFILES 32 MAXDATAFILES 100 CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 LOGFILE GROUP 1 (Q:\ORADATA\ORCL\REDO01.LOG) SIZE 200M, GROUP 2 (Q:\ORADATA\ORCL\REDO02.LOG) SIZE 200M DATAFILE Q:\ORADATA\ORCL\SYSTEM01.DBF SIZE 500M AUTOEXTEND ON NEXT 200M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\SYSAUX01.DBF SIZE 400M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\UNDOTBS01.DBF SIZE 400M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED, Q:\ORADATA\ORCL\USERS01.DBF SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED CONTROLFILE REUSE SET STANDBY NONE;这段SQL指定了所有数据文件、控制文件和联机日志都在Q盘。MAXINSTANCES设为1因为故障转移群集同一时刻只有一个实例打开数据库。执行完记得在ORACLE_HOME\database下创建PFILE或SPFILE并让SPFILE指向Q盘位置。SPFILE内容要设置*.db_nameORCL、*.db_create_file_destQ:\ORADATA以及监听相关参数。然后创建口令文件orapwd FILEC:\Oracle\Home\dbhome_1\database\PWDORCL.ORA ENTRIESUSER,SYS PASSWORD口令 FORCEY建库完成后关闭实例绝对不要在节点1启动着库时就向群集注册服务避免双节点同时挂载共享盘。4.3 把Oracle服务和监听器注册成群集资源数据库文件一旦落地共享盘两个节点上的Oracle服务比如OracleServiceORCL和OracleOraDb11g_home1TNSListener或19c的监听器都需要在系统中存在但群集资源管理器负责按角色启动哪一侧服务。最省事的做法是把这两个Windows服务作为“通用服务”资源加入同一个角色依赖关系设为共享磁盘和虚拟IP。打开Failover Cluster Manager在角色上右键“新建角色”选“通用服务”分别选中这两个Oracle服务然后设置依赖为“Cluster Disk 1”和“Cluster IP”。如果没有图形界面可以在PowerShell里用Add-ClusterGenericServiceRole在这里给出一个近似可用的样例Add-ClusterGenericServiceRole -Name OracleDBRole -ServiceName OracleServiceORCL -StaticAddress 192.168.1.200 Add-ClusterGenericServiceRole -Name OracleListRole -ServiceName OracleOraDb11g_home1TNSListener -StaticAddress 192.168.1.200注意上面命令中监听器服务名要换成你安装版本的实际服务名。两个角色都要指定相同静态IP并让监听器依赖数据库服务。用Set-ClusterGenericServiceRoleDependency设置依赖关系例如Set-ClusterGenericServiceRoleDependency -Role OracleListRole -Dependency OracleDBRole, Cluster Disk 1这里Cluster Disk 1是共享数据盘资源名。注册完成以后可以把角色名改成OracleDB然后将节点1的Oracle服务手动停止让群集把角色移到节点2验证监听和数据文件路径的可用性。要注意数据库里记录的监听器不能绑定本机IP而要绑定虚拟IP否则客户端切换后照样连不上。4.4 配置Oracle服务的启动属性不用自动、交给群集两个节点上各设置Oracle服务为“手动”启动而不是“自动”因为Windows启动时如果自动拉起Oracle但此时群集还没把磁盘所有权交给该节点会导致数据库以错误顺序挂载。更糟的是如果两个节点同时启动Oracle尝试打开同一数据文件会产生文件锁冲突。在Oracle服务属性中把“启动类型”改为“手动”并在故障那台机器上不要通过services.msc手工启停一切切换都通过群集管理器来触发。这个细节是很多初次部署的人翻车的地方——往往只做了群集却没卸掉本地服务自动启动结果切换时多了一堆僵尸进程。5. 故障转移群集部署避坑五条实操血泪5.1 共享磁盘盘符漂移导致Oracle启动失败现象一键切换后数据库实例起不来告警日志显示ORA-00205: error in identifying control file或找不到数据文件。原因Windows重新启动后把共享盘的盘符从Q改成了R而群集资源注册的依赖还是旧盘符Oracle的参数文件写的是Q:\ORADATA\...。解决在群集磁盘资源属性中固定盘符或使用NTFS挂在目录Mount Point来替代盘符同时调整两个节点磁盘管理界面让它们看到的共享盘符一致。我习惯在磁盘资源属性里把“路径”锁定为Q:再把Oracle的SPFILE和所有参数路径全部用Q:之后就再也没出现漂移。5.2 群集网络名/虚拟IP被DNS缓存卡住现象客户端报ORA-12545提示位置错误但通过ping虚拟IP可以通。原因虚拟IP变化后DNS缓存还持有旧地址或者群集的网络名称注册NetBIOS没及时更新。解决在群集网络资源属性中启用“DNS注册”把“传输网络名称”设为静态IP并在客户端执行ipconfig /flushdns。如果应用有持久连接池还需要在应用侧设定重连等待时间或采用连接串的autoReconnect。更稳妥的做法是在监听器listener.ora中把HOST设置为虚拟IP的变量例如LISTENER (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.200)(PORT 1521)) ) )不要用主机名否则群集切换时监听器无法自动绑上当前节点的虚拟IP。5.3 监听器没加入群集资源现象切换后数据库实例能起但应用连不上数据库检查监听是停止状态。原因很多人只把OracleServiceORCL加入角色而TNSListener仍是本地服务没有跟随虚拟IP一起漂移。解决把监听器服务也加入同一个故障转移角色并设置它依赖数据库服务和磁盘资源。在依赖关系里把监听器放在数据库服务之后启动否则节点刚接管磁盘时数据库还没mount监听器启动虽然成功但后续任何连接都会报ORA-01033。用群集管理器配置依赖列表把监听器角色的依赖设为数据库服务加磁盘即可。5.4 时间同步问题导致群集仲裁误判现象节点1和节点2都活着但群集频繁把其中一个节点踢出事件日志出现“节点已删除来自故障域”的警告。原因Windows群集对节点间时间差很敏感默认超过5分钟偏差就会被判定为“无心跳”。如果不同节点分别用不同NTP源或未配置NTP很快就能跑到秒级偏差。解决让所有节点统一用域控制器的NTP源并在节点上检查w32tm /query /status。如果时间差较大立即执行w32tm /config /syncfromflags:domhier /update Restart-Service w32time身份验证也依赖Kerberos时间偏移过大会引发一系列偶发的连接失败。我在部署每个Windows群集项目后都会加一条计划任务每天凌晨检查一次时间差并报警。5.5 19c安装时Oracle基目录路径带空格现象Oracle 19c安装完成但建库时执行dbca报错Failed to get current updatable root或Path contains space之类。原因Oracle 19c默认推荐安装路径是C:\Program Files\Oracle\其中包含空格而Windows群集的资源监听服务在启动时无法正确解析带空格的命令字符串。解决安装时手动把ORACLE_BASE设置为C:\Oracle\BaseORACLE_HOME设为C:\Oracle\Home\dbhome_1并确保两个节点路径完全一致。另外注意不要把群集名称或虚拟IP也取成带空格Windows群集资源名不允许有空格否则故障转移时服务路径解析错乱。6. 验证故障转移的三种手段和日常运维习惯6.1 用Failover Cluster Manager手动切换并观察日志建好群集、注册好Oracle角色后不要立刻宣布成功至少要跑一次手动切换。步骤是打开“故障转移群集管理器”选中角色OracleDB右键“移动”到节点2。转移过程中虚拟IP从节点1消失仲裁盘和共享盘也卸载然后节点2挂载并启动Oracle服务。切换结束后检查Get-ClusterResource -Name OracleDBRole | Get-ClusterResourceLog -Level Verbose | Out-String查看资源是否处于Online状态以及节点2上Oracle告警日志里有没有报错。同时用tnsping oracluster确认虚拟IP下的1521端口可通。这个手动切换至少来回做三次确认两个节点都能作为主节点承载数据库。6.2 用轮询事务脚本验证数据一致性故障转移群集最怕的是“切换是假的数据库一打开就回滚大量事务”。我习惯在业务不忙的时候放一个定时脚本每秒往测试表插一条带时间戳的记录。切换后查看时间戳是否连续如果连续说明共享盘、重做日志都可靠。下面是一段简单的PowerShell轮询脚本配合SQL*Plus执行while ($true) { $ts Get-Date -Format yyyy-MM-dd HH:mm:ss.fff $sql INSERT INTO QA.TEST_TABLE(COL_TS) VALUES (TO_TIMESTAMP($ts,YYYY-MM-DD HH24:MI:SS.FF3)); COMMIT; sqlplus -s user/passoracluster:1521/ORCL $sql | Out-Null Start-Sleep -Milliseconds 1000 }脚本里user/passoracluster:1521/ORCL中的oracluster是群集名称解析到虚拟IP。切换前后如果时间戳出现大于1秒的间隙表明服务中断时间超过预期如果完全没有缺口且表一直能插入说明实例确实接管的是同一份数据文件。也可以用一条SQL把总金额汇总查询作为健康检查但写入型探针比只读查询更能暴露文件锁和回滚问题。6.3 把群集日志纳入统一告警形成运维习惯故障转移群集不是一次性的部署日常监控要有重点。我会把Windows事件日志里的Microsoft-Windows-FailoverClustering/Operational和Oracle的alert_SID.log都纳入监控系统。至少每天查看一遍节点状态、资源状态并用计划任务把状态写入CSV。同时留意共享盘剩余空间因为数据文件都在Q盘如果Q盘爆掉切换后的实例同样会宕机。这里分享一个我自己的血泪教训第一次部署完这套方案时我认为只要数据库能起来就万事大吉却忘了把监听器服务加入角色。第二次演练时切换后应用连不上被领导当场指着屏幕问“为什么你画的架构图里没有监听器”。从那以后我每次都会在部署文档里附一张“资源依赖草图”把虚拟IP、磁盘、数据库服务、监听器四者画成一条链并标注它们的前后启动顺序。依赖决策其实很简单虚拟IP和磁盘最底层数据库服务次之监听器在最上层。理顺这条链故障转移群集这件事才算真正完工。希望这篇笔记能帮你在Windows Server 2019上把Oracle 11g或19c的故障转移群集搭起来少走几个月弯路。本文还有配套的精品资源点击获取