Windows下RoseHA双机热备Oracle 11g部署与切换实战

简介：面向Windows平台运维与数据库管理员，这是一份围绕RoseHA高可用方案部署Oracle 11g的完整操作文档，目标是为关键业务提供连续运行保障，避免硬件故障或系统异常导致数据库服务中断。文档从RoseHA双节点集群的拓扑结构入手，系统说明操作系统补丁、心跳网络、多网卡配置、静态IP分配、RAID磁盘阵列等前期准备，并涵盖Oracle 11g的安装选项、网格基础设施、版本与存储规划，以及RoseHA GUI创建集群、配置Oracle服务的具体步骤，能有效指导读者搭建冗余数据库环境。资源包内包含1个docx文件，整体大小1.84MB，目录结构清晰，按部署前规划、Oracle安装、RoseHA配置分段组织，适合作为企业Oracle高可用建设的实操手册。目前已有241人学习下载，值得运维与DBA人员参考。

1. RoseHA for Windows 部署 Oracle 11g：分钟级接管带来的可用性选择

RoseHA for Windows 上部署 Oracle 11g，这个标题背后是一个非常具体的运维场景：一台 Windows Server 跑着一个 Oracle 11g 库，老板说这台机器不能挂，挂了业务就停。最务实的做法就是上双机热备——两台同样的 Windows 主机，共享一套存储，RoseHA 负责监控和接管，Oracle 11g 作为被保护的应用。这套方案上手门槛低，没有 RAC 那么复杂，但细节决定成败，部署时盘符、脚本、网络任何一环错了，切换那一刻就翻车。适合正在做 Windows 平台 Oracle 高可用方案的 DBA、运维工程师，也适合想低成本保证数据库不长时间中断的团队，这篇笔记从规划到验证给你一条完整的落地路径。

2. 部署前的规划：磁盘布局、心跳网段和 Oracle 安装位置怎么定

2.1 先想明白 RoseHA 的接管时序

RoseHA 的工作模式是主备双机热备。两台机器各自装 Windows Server 和 Oracle 11g 软件，通过存储网络共享同一套数据库文件。正常运行时，主节点拥有共享盘和虚拟 IP，Oracle 实例在主节点上对外提供服务；备机处于待命状态，只有心跳在工作。

接管发生时，备机通过仲裁机制确认自己拿到了接管权，然后按固定顺序动作：先联机共享盘，再绑定虚拟 IP，接着执行资源组里注册的应用启动脚本，最后做健康检查确认数据库真的能对外服务。这个顺序里任何一步慢了，切换时间就会被拉长；任何一步失败，数据库就起不来或起了一半。所以后面配置脚本资源时，核心不是“把服务 start 起来”，而是“确认实例真的 OPEN”。

2.2 共享存储上的磁盘布局怎么分

共享盘是这套方案的命根子。两台机器都要能看到同一块 LUN，但同一时刻只有主节点能读写它，备机在磁盘管理里把它保持为“脱机”状态，RoseHA 接管时再联机。磁盘布局建议按表格这样规划：

仲裁盘是容易忽略的一块。它的作用类似投票站：当主备之间心跳全部断开时，哪台机器还能正常读写仲裁盘，哪台就有资格接管。没有仲裁盘，心跳一断就可能脑裂，两台机器同时抢共享盘和虚拟 IP，这个后果比单机宕机更严重。仲裁盘分区不要太小气，1G 足够，但一定要保证两端都能访问，I/O 路径必须稳定。

2.3 网络划分：业务网、心跳和管理网分开

网络规划直接影响心跳的可靠性。常见做法是至少三个网段：业务网用于客户端连接数据库，心跳网用于主备互相探测，管理网用于登录维护。三张网不要混用，尤其心跳网千万不要和业务网走同一块网卡。

心跳网段用直连线或交换机单独划 VLAN，不跑其他流量。Windows 防火墙不要图省事整个关掉，精确放行 RoseHA 通信端口和心跳端口即可。很多人为了省事全部关防火墙，结果 Windows 更新后防火墙又自动开启，心跳断了半天没人发现，这个坑后面避坑章还会详细说。

2.4 Oracle 软件放本地还是共享盘：多数方案选本地

Oracle 11g 的软件安装位置有两种做法，我的建议是软件装本地盘、数据文件放共享盘。原因有三点：第一，Windows 上 Oracle 服务绑定的是本机 ORACLE_HOME 路径，软件放共享盘切换时容易遇到文件句柄冲突；第二，备机也装一套同样的软件，切换后直接用本地路径启动实例，路径解析简单；第三，软件独立于存储，存储故障时至少两端还能做诊断。

备机安装 Oracle 软件时选择“仅安装数据库软件”，不要建库，后面由 RoseHA 在接管时通过共享盘上的数据文件拉起同一个实例。主备两端软件版本必须一致，补丁级别也尽量对齐，否则切换后行为可能不一致。

3. 在 Windows 上把 Oracle 11g 装成可接管状态：安装模式与服务自启设置

3.1 主备两台都要有 Oracle 软件：静默安装的响应文件怎么填

两端都要装 Oracle 11g 软件，主节点用于建库，备节点只装软件不建库。交互式安装的要点是选中“仅安装数据库软件”，把创建数据库的步骤留到后面手动做。如果机器多或者需要重复安装，用静默安装更可控，Oracle 11g 的静默安装命令和响应文件如下：

setup.exe -silent -responseFile C:\install\db_install.rsp -ignoreSysPrereqs -ignorePrereq -waitforcompletion

响应文件里几个关键参数这样填：

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v11_2_0 oracle.install.db.InstallEdition=EE oracle.install.db.ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 oracle.install.db.ORACLE_BASE=C:\app\oracle oracle.install.db.config.starterdb.type=GENERAL_PURPOSE oracle.install.db.config.starterdb.SID=ORCL oracle.install.db.config.starterdb.memoryLimit=2048 oracle.install.db.config.starterdb.password.ALL=ChangeMe123 oracle.install.db.config.starterdb.storageType=FILE_SYSTEM oracle.install.db.config.starterdb.dataLocation=F:\oradata

InstallEdition 决定装企业版还是标准版，生产环境一般选 EE；memoryLimit 设 0 表示交给 AMM 自动管理；password.ALL 会一次性设置 SYS、SYSTEM 等账号的密码。注意 dataLocation 指向共享盘 F:\oradata，如果当前这台机器还没联机共享盘，安装程序会直接报路径不可用，所以安装前确认共享盘状态是非常重要的一步。

3.2 把数据文件直接建在共享盘：建库与表空间脚本

数据库建好后，第一步就是把业务表空间落到共享盘。如果安装时已经在共享盘建了库，直接执行表空间脚本即可；如果当时建在本地盘，需要把数据文件迁移到共享盘。下面是新装库后最典型的建表空间和建用户步骤：

-- 数据文件一律指向共享盘 F:\ORADATA CREATE TABLESPACE TBS_MES DATAFILE 'F:\ORADATA\ORCL\TBS_MES01.DBF' SIZE 100M AUTOEXTEND ON NEXT 50M MAXSIZE 4G; CREATE TABLESPACE TBS_MES_IDX DATAFILE 'F:\ORADATA\ORCL\TBS_MES_IDX01.DBF' SIZE 50M AUTOEXTEND ON NEXT 20M MAXSIZE 2G; CREATE USER biz_app IDENTIFIED BY "BizApp123" DEFAULT TABLESPACE TBS_MES QUOTA UNLIMITED ON TBS_MES; GRANT CONNECT, RESOURCE, CREATE SESSION TO biz_app;

生产上建议把数据表空间和索引表空间分离，减少 I/O 竞争。AUTOEXTEND 的 MAXSIZE 要按磁盘容量规划，别让表空间无限增长把共享盘塞满，共享盘满了以后实例会挂起，双机热备也救不了。

3.3 Windows 服务控制：让 Oracle 的启动权交给 RoseHA

Oracle 安装完成后会自动注册 Windows 服务，默认启动类型是“自动”。这个默认值在双机环境下必须改掉，否则系统开机时服务先启动，共享盘还没联机，实例起不来还会留下一堆错误日志。建议把服务和监听都改成手动：

sc config OracleServiceORCL start= demand sc config OracleOraDb11g_home1TNSListener start= demand

注意 sc 命令的等号后面必须有一个空格，写成start=demand会直接报参数错误，这是个容易翻车的小细节。改为 demand 后，Oracle 服务不会随 Windows 启动，完全由 RoseHA 的脚本资源控制。

备机因为没有建库，需要手动注册一个与主库同名的 Windows 服务，这样 RoseHA 切换过去后才知道该启动哪个服务：

oradim -new -sid ORCL -startmode manual -shutdownmode immediate

oradim 是 Windows 平台上管理 Oracle 实例服务的工具，-sid ORCL必须与主库 SID 一致，-startmode manual保证服务不随系统自启。备机服务注册完成后，不需要启动它，共享盘联机后由脚本自动拉起。

4. RoseHA 资源组配置：脚本资源与虚拟 IP 接管的具体操作

4.1 心跳和仲裁盘先配好

RoseHA 管理端安装好后，先把两台节点加进集群，再把心跳网卡指定为专用网段。心跳网段地址不要跟业务网段在同一广播域，最好是 30 位掩码的互联地址，比如主节点 192.168.100.1、备节点 192.168.100.2。两端防火墙要放行心跳端口，不然心跳数据过不去，集群永远处于不健康状态。

仲裁盘在 RoseHA 里指定为共享存储上的 E 盘。配置仲裁盘前确认两台机器都能在磁盘管理里看到同一个 E 盘，且处于联机状态。RoseHA 接管时自己会处理盘符的联机与脱机，不需要在 Windows 服务里额外干预。

4.2 建立资源组并规划资源顺序

资源组是 RoseHA 的核心概念，一个资源组包含共享磁盘资源、虚拟 IP 资源和应用脚本资源。正常工作时资源组落在主节点上，故障后整体漂移到备机。资源组里各资源的执行顺序可以归纳为一句话：先磁盘，再网络，最后应用。

切换时顺序是“联机共享盘 → 绑定虚拟 IP → 执行启动脚本 → 健康检查”；停止时顺序相反，“先关实例 → 再脱虚拟 IP → 最后脱磁盘”。RoseHA 图形界面里可以配置资源依赖关系，把脚本资源设为依赖磁盘资源和 IP 资源，避免脚本在磁盘还没就绪时就开始启动服务。

4.3 写 Oracle 的启动脚本和关闭脚本

脚本资源是应用接管的关键。启动脚本不能只是sc start OracleServiceORCL就完事，必须加上健康检查，确认实例真正 OPEN 后才返回成功。下面是我常用的启动脚本：

@echo off set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SID=ORCL set PATH=%ORACLE_HOME%\bin;%PATH% sc start OracleServiceORCL >nul 2>&1 for /l %%i in (1,1,30) do ( sc query OracleServiceORCL | find "RUNNING" >nul if not errorlevel 1 goto :check_instance timeout /t 2 /nobreak >nul ) :check_instance sqlplus -s "/ as sysdba" @C:\roseha\scripts\check_db.sql >nul 2>&1 exit /b %errorlevel%

配套的健康检查 SQL：

whenever sqlerror exit 1 conn / as sysdba select 1 from v$instance where status='OPEN'; exit;

启动脚本的逻辑分两段：先循环等待 Windows 服务到 RUNNING 状态，最多等 60 秒；服务起来后再执行 SQL 查询实例状态，只有 v$instance 返回 status='OPEN' 才算成功。这样能把“服务进程活着但实例还在恢复”的情况识别出来，避免 RoseHA 误判接管成功。

关闭脚本用 sqlplus 发 shutdown 而不是直接sc stop，这是很多人忽略的细节：

@echo off set ORACLE_HOME=C:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SID=ORCL set PATH=%ORACLE_HOME%\bin;%PATH% sqlplus -s "/ as sysdba" @C:\roseha\scripts\shutdown_db.sql >nul 2>&1 sc stop OracleServiceORCL >nul 2>&1 exit /b 0

对应的关闭 SQL：

shutdown immediate; exit;

shutdown immediate 会主动做检查点并关闭实例，下次启动不需要长时间崩溃恢复；而直接 sc stop 相当于杀进程，Windows 服务是停了，但数据库在备机起来时要重放大量 redo 日志，切换时间直接翻倍，这个坑踩过的都知道疼。

4.4 虚拟 IP 资源和客户端连接方式

虚拟 IP 是客户端访问数据库的唯一入口。在 RoseHA 资源组里添加虚拟 IP 资源，指定一个业务网段内未被占用的地址，比如 10.0.10.100。切换发生时，RoseHA 会在新主节点上执行地址绑定，客户端连接串不用改，继续连虚拟 IP 即可。

监听器建议配置静态注册，并且监听地址直接写虚拟 IP，避免动态注册带来的延迟。listener.ora 的关键配置如下：

LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.0.10.100)(PORT = 1521)) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORCL) (SID_NAME = ORCL) (ORACLE_HOME = C:\app\oracle\product\11.2.0\dbhome_1) ) )

HOST 写虚拟 IP 而不是主机名，是为了避免切换后解析到本机网卡导致监听地址错误。加了 SID_LIST 静态注册后，应用通过虚拟 IP:1521 就能直接定位到实例，不依赖 mts 服务发现，转换速度更快。

5. 避坑：Windows 双机接管 Oracle 的五个排查记录

5.1 盘符漂移导致数据文件找不到

现象：备机切换后 Oracle 实例起不来，alert 日志报 ORA-01157、ORA-01110，提示数据文件无法识别。

原因：共享盘在备机上被系统分配了不同盘符。主库数据文件在 F 盘，备机上同一块 LUN 被识别成了 G 盘，Oracle 按 F:\ORADATA 路径找文件当然找不到。

解决：把两端盘符固定成一致。磁盘管理里手动更改驱动器号为 F，或者用挂载点方式。固定后重新启动备机验证盘符不再变化。

5.2 心跳单点导致脑裂

现象：某次机房里一根网线松动，主备两台机器几乎同时报接管，共享盘两边都在读写，应用连接全面紊乱。

原因：心跳只有一根线，断开后主备彼此探测不到对方，又没有仲裁盘或仲裁盘配置不当，两边都认为自己有资格接管。

解决：心跳线至少做双根，接在不同交换机上；配置仲裁盘 E 盘；同时在 RoseHA 里把仲裁超时设得比存储 I/O 超时长，避免存储抖动触发误判。

5.3 监听没有指向虚拟 IP

现象：切换后虚拟 IP 能 ping 通，应用连不上 1521 端口。在备机上执行netstat -ano | findstr 1521，发现监听地址还是本机物理 IP。

原因：listener.ora 里 HOST 写的是主机名或者本机业务 IP，切换后物理 IP 没有跟随虚拟 IP 一起漂移，监听自然就断了。

解决：listener.ora 按 4.4 节改成静态注册，HOST 直接写虚拟 IP。改完重启监听，确认 netstat 输出里 1521 端口绑定的是虚拟 IP 地址。

5.4 数据库起来了应用还在报错

现象：切换后数据库实例 OPEN，虚拟 IP 也通了，但应用持续报连接失败或连接超时。

原因：应用连接池里还保留着旧连接，或者 JDBC 连接串写的是两台物理机地址，没有走虚拟 IP。主备切换后旧连接全部失效，连接池不会自动重建。

解决：JDBC 连接串加上故障重连参数，应用层设置合理的连接超时和重试次数。客户端一律使用虚拟 IP 连接，不要直连物理机地址。

5.5 Windows 自动更新把双机重启节奏打乱

现象：某次 Windows 更新后主备机先后重启，备机先起来直接接管，随后主机也起来又抢回资源，业务在两个小时内反复中断了三次。

原因：更新窗口没有做人工控制，两台机器在维护窗口内自动重启，RoseHA 在处理连续重启时的行为被误判。

解决：组策略或 WSUS 把自动更新改为手动，重启窗口交给维护流程控制。服务器电源选项里把“允许按 Wake Timers 唤醒”关掉，避免计划任务在深夜唤醒机器。每次维护窗口前手动做一次切换演练，确认双机状态正常再动系统。

6. 验证切换与压降停机窗口：一个探活脚本加一套演练习惯

6.1 手动切换测试清单

部署完成后不要直接上线，先按下面的清单做一轮切换测试：

每次测试都记录切换时间，积累数据后就能判断脚本配置是否健康。

6.2 用一个探活脚本量化切换时间

切换时间的量化不能靠感觉，我用下面这个 PowerShell 脚本持续探测虚拟 IP 的 1521 端口，自动记录中断时长：

$target = "10.0.10.100" $port = 1521 $down = $null while ($true) { $ok = Test-NetConnection -ComputerName $target -Port $port -WarningAction SilentlyContinue -InformationLevel Quiet if ($ok) { if ($down -ne $null) { $ts = (Get-Date) - $down Write-Output ("恢复时间: " + [math]::Round($ts.TotalSeconds, 1) + " 秒, 中断起始: " + $down) $down = $null } } else { if ($down -eq $null) { $down = Get-Date; Write-Output ("中断开始: " + $down) } } Start-Sleep -Seconds 2 }

这个脚本放在一台和数据库同网段的机器上，每两秒探测一次。切换开始时端口不可达，脚本记录时间点；数据库恢复后端口重新可达，脚本输出中断时长。注意-InformationLevel Quiet需要较新的 PowerShell 版本，老版本可以用TcpTestSucceeded属性判断。

6.3 定期演练是这套方案唯一的后悔药

双机热备最容易出的问题不是切换失败，而是没人敢切。我见过不少环境部署完一次没演练过，真出事时光靠文档救不了场。建议每季度做一次切换演练，先模拟正常切换再模拟断电，每次演练后回看两边的 Windows 事件日志和 Oracle alert 日志。

我第一次部署这套方案时，把仲裁盘随便划了个 200M 的分区，后来存储控制器抖动导致仲裁 I/O 超时误判，切换后实例恢复花了五分钟。后来我把仲裁配置调稳、listener 改静态注册到虚拟 IP、启动脚本加了 OPEN 状态检查，切换时间稳定在 30-60 秒。这套组合拳打下来，才算真正敢说“这台 Oracle 有高可用”。希望帮到你。

本文还有配套的精品资源，点击获取