简介：Windows Server 2019 环境下 Oracle 数据库的部署常让不少运维新手头疼，这份图文文档正好补上了从零到可用的关键环节。与常见仅讲解 Linux 平台的教程不同，它完整走通了 Windows Server 2019 系统安装、磁盘分区、管理员初始化等前置环节，再逐步展开 Oracle 11.2.0.4 服务端安装与 pacs 数据库创建流程，同时覆盖 Oracle 19c 及 19c Client 的对接配置，并专门列出 NIC 网络聚合配置说明，解决多网卡场景下的网络瓶颈。文档还深入讲解了 Oracle 19c Client 数据源连接原理，针对客户端无法连接数据库的常见场景给出排查思路，对 Windows 平台上部署数据库的 DBA、运维人员很有实操价值。资源为 1 个 PDF 文件，压缩包大小 5.13MB，目前已有 1853 人学习下载。
1. Windows Server 2019 下 Oracle 11g、19c 安装部署：从系统到客户端的一次完整落地
医院 PACS 系统上线那天，我拿到一台预装 Windows Server 2019 的物理机，要在上面同时完成 Oracle 11g、19c 的安装部署。这套组合在医疗影像行业太常见了：业务库用 11g（11.2.0.4）跑稳定，工作站端用 19c Client 解决新协议下部分客户端连不上老库的问题。整套 Windows Server 2019 下 Oracle 11g、19c 安装部署走下来，最耗时间的不是点下一步，而是系统版本选择、磁盘规划、客户端兼容性这几个没人明说的环节。这篇图文笔记把当时的步骤和踩过的坑原样整理出来，适合做医疗、政务、制造行业系统集成的工程师，也适合需要在 Server 2019 上建 Oracle 单实例库的运维照着复现。
2. 系统底座：Windows Server 2019 安装、磁盘划分与初始化
系统底座直接决定 Oracle 装得顺不顺。Server 2019 跟老系统不一样，默认行为里藏着好几个会坑到后边数据库安装的点。这一章把系统层面的三件事讲透：装哪个版本、磁盘怎么分、装完先做什么。
2.1 选对安装版本：桌面体验与 Core 的取舍
装 Windows Server 2019 时，第一个决定性选择是版本。我选的是 Standard（桌面体验），不是 Server Core。原因很实在：Oracle 11g 的图形安装器 OUI、DBCA 建库工具、PLSQL Developer 全是 GUI 程序，在 Server Core 上虽然也能通过远程 PowerShell 或从别的机器调图形界面跑，但步骤绕、报错不好定位，现场根本耗不起这个时间。做系统集成的机器，宁可多占 10G 磁盘，也要桌面体验版。
安装过程中注意几个入口。启动安装后直接点「我没有产品密钥」，不要卡在密钥输入上，操作系统的激活等进系统再说。版本选择界面选 Windows Server 2019 Standard（桌面体验）。之后安装类型选「自定义：仅安装 Windows（高级）」，不要选升级，干净安装比什么都强。我见过不少人在密钥界面纠结半天，其实评估期 180 天足够完成部署和验收。
这里有个容易被忽略的坑：安装过程中系统会自动重启、自动进入「准备系统」阶段，这个过程不要人为干预，也不要断电。等它走到「为 administrator 设置密码」的界面，输入符合复杂度要求的密码（至少要大写+小写+数字，长度 8 位以上），密码强度不过关进不了下一步。
2.2 磁盘管理：C 盘与业务盘的分区规划
系统安装界面的分区阶段，我只对 C 盘做分区，其余磁盘全部等进入系统以后再用磁盘管理去分配。为什么不在安装界面一次性分完？因为安装界面的分区工具功能简陋，误选磁盘可能导致整块盘数据被清空；系统装完以后在磁盘管理里操作，界面直观、可调整，也方便按业务需求随时改。
Oracle 部署场景下，我给的分区建议是下面这张表。数字不绝对，重点逻辑是数据文件、归档日志、备份不要跟系统挤在同一个分区。
| 分区 | 大小 | 用途 | 说明 |
|---|---|---|---|
| C 盘 | 120G 起 | 系统 + Oracle 软件 + 客户端工具 | 至少留 40G 空闲给 Oracle 软件和日志 |
| D 盘 | 按业务量 | 11g 数据文件、控制文件、redo 日志 | 影像数据增长快，按两年增量估算 |
| E 盘 | 按备份策略 | RMAN 备份、归档日志、安装包 | 备份与数据物理隔离 |
| F 盘 | 可选 | 业务交换区、临时文件 | 留给后续扩容，不用就空着 |
磁盘管理进法：右键「此电脑」→「管理」→「磁盘管理」。对未分配空间右键，选「新建简单卷」，一路下一步：指定卷大小、分配驱动器号、文件系统选 NTFS、卷标按用途写清楚。格式化时我习惯对数据盘做一次完整格式化，不做快速格式化，这样坏道能提前暴露出来，省得数据写进去了才发现盘有问题。
2.3 系统初始化三件事：主机名、静态 IP、防火墙放行
进系统之后先别急着拷 Oracle 安装包，把这三件事做完再动手。第一是改主机名，第二是配静态 IP，第三是放行 Oracle 监听端口。主机名和 IP 必须提前规划好，因为后面 Oracle 监听器默认用主机名做绑定，主机名解析出错会直接导致客户端连不上。
用 PowerShell 做这三件事最省事，命令如下：
# 设置主机名（改成规划好的服务器名，别用默认随机名，重启生效） Rename-Computer -NewName "PACS-DB-01" -Restart # 配置静态 IP，以网卡名"以太网"为例，PrefixLength 24 对应 255.255.255.0 New-NetIPAddress -InterfaceAlias "以太网" -IPAddress 192.168.10.20 -PrefixLength 24 -DefaultGateway 192.168.10.1 # 放行 Oracle 监听端口，不建议直接关防火墙 New-NetFirewallRule -DisplayName "Oracle1521" -Direction Inbound -Protocol TCP -LocalPort 1521 -Action Allow三条命令的用途说明：第一条把随机主机名改成规划名，Oracle 监听器和 tnsnames 都依赖这个名称；第二条配静态 IP，PrefixLength 24 就是传统掩码 255.255.255.0，现场根据实际网段改；第三条只放行 1521 端口，比整网关闭防火墙安全得多，数据库服务器在内网也不要裸奔，装完以后如果要用 PLSQL 远程连接，这个规则必须存在。
还有一个容易忽略的点：把服务器时间同步到 NTP。数据库时间戳、证书有效性、告警日志排序全都依赖系统时间，时间偏差大后面排查问题会非常痛苦。在「控制面板 → 日期和时间 → Internet 时间」里选一个内网 NTP 源，同步后确认时区正确。
3. Oracle 11.2.0.4 服务端安装与建库：从 SETUP 到 pacs 库
系统底座就绪后，进入核心环节。Oracle 11g 选 11.2.0.4 这个版本是有讲究的：它是 11g 最后一个 PSU 版本，bug 修复最全，也是 Windows 上最稳的 11g 版本。这一章从安装包准备讲到 DBCA 建库，把每一步背后的原因说清楚。
3.1 安装前的环境检查与安装包准备
拷贝安装包到服务器前，先说三个前置条件。第一，安装包路径和目录不能含中文，纯英文路径能避免一堆编码问题，我一般直接建 D:\oracle_install 放安装包；第二，安装包对应的是 11.2.0.4 的两个 zip，解压后注意database目录下的setup.exe；第三，确认当前登录账号有管理员权限，OUI 要写注册表，权限不足会在安装中期报错回滚。
另外，Oracle 11g 的 OUI 会做环境检查，在 Server 2019 上经常会弹两个警告：一个是「物理内存不足」，一个是「操作系统版本未知」。这俩都是因为 11g 的 cvu 检查文件太老，不认识 Server 2019 导致的。处理方式是编辑解压目录下的database\stage\cvu\cvu_prereq.xml，在里面补上 Windows Server 2019 的操作系统条目，或者直接点「忽略」继续。我当时选择忽略并继续，后续安装没有任何问题。
3.2 安装界面上的四个关键选择
双击setup.exe进入图形界面，记住有四个关键选择点，每个都决定了后续流程走向。
第一，安全更新界面：不要勾选「我希望通过 My Oracle Support 接收安全更新」。没有 Oracle 账号或者在内网环境，勾了反而卡住，即使有账号也不建议在安装阶段连外网。不勾直接下一步，系统会弹确认框「确实不提供邮箱地址吗」，点是继续。
第二，选择「跳过软件更新」。11g 在 Server 2019 上检查更新非常慢，等待时间不可控，现场部署直接跳过。
第三，选择「仅安装数据库软件」。这是我最推荐的部署方式：数据库软件先装好，再单独用 DBCA 建库。比同时建库更可控，字符集、内存参数、密码策略都能单独定制，不需要在安装向导里仓促定案。
第四，选择「单实例数据库安装」。对应单机部署场景，不选 RAC。之后一路下一步，等待软件安装完成即可。安装完成后 Oracle 的sqlplus等基础工具就会出现在C:\app\Administrator\product\11.2.0\dbhome_1下。
3.3 DBCA 建库：内存、字符集与监听器参数
软件装完建库，命令行输入dbca会弹出图形向导。建库阶段我把 pacs 库作为示例，几个关键参数按下面这张表设定。项目里创建的 pacs 数据库，是给影像系统专用的库，这类库的特点是数据量增长快、并发事务中等、以存储和检索为主。
| 参数项 | 推荐值 | 说明 |
|---|---|---|
| Global Database Name | pacs | 与 SID 保持一致，方便后续维护 |
| SID | pacs | 连接字符串和运维脚本都基于它 |
| 字符集 | ZHS16GBK | 业务只存中文时选这个；要存多语言选 AL32UTF8 |
| SGA | 6144 MB | 16G 物理内存的典型值，OLTP 够用 |
| PGA | 2048 MB | 排序和 hash 操作空间，2G 起步 |
| 示例方案 | 不创建 | 省空间也省维护成本 |
| 连接模式 | 专用服务器模式 | 默认选项，避免共享服务器模式的连接排队 |
内存参数说明：11g 虽然支持 AMM（自动内存管理），但 Windows 平台上 AMM 的粒度问题偶尔会触发奇怪报错，我一般手动分配 SGA 和 PGA。物理内存 16G 的时候，SGA 给 6G、PGA 给 2G 是安全起点，留足系统和其他进程的内存余量，避免操作系统层的内存压力反过来拖垮 Oracle。
监听器在安装软件时已经生成了 Windows 服务OracleOraDb11g_home1TNSListener，DBCA 建库过程中会默认注册到监听，确认界面勾选即可。数据库创建完成后会显示生成了服务OracleServicePACS，这两个 Windows 服务就是后面最常打交道的东西。
3.4 验证安装：lsnrctl、tnsping 与 sqlplus
建库完成不要急着装客户端，先用三个命令把服务端验证一遍。这组命令我在每个 Oracle 环境都会跑，三分钟确认数据库可用：
# 查看监听器状态，确认 pacs 服务已注册 lsnrctl status # 测试客户端到监听器的连接，服务名写 pacs tnsping pacs # 用 sysdba 登录并查看数据库状态 sqlplus / as sysdba select name, open_mode from v$database;每条命令都有明确的验证目标。lsnrctl status的输出里应该能看到Services Summary段，pacs服务状态为 READY 才说明监听注册成功；tnsping pacs能通说明网络、主机名解析、监听地址都没问题；最后一条 SQL 如果返回READ WRITE，说明数据库处于正常的读写状态。如果open_mode显示MOUNTED或READ ONLY，说明数据库处于特殊阶段，需要检查是不是在恢复或者只读模式。
4. 客户端组合方案：11g Client、10g Client 与 PLSQL 的连接配置
数据库建好只是第一步，真正让业务跑起来的是客户端连得上。这一章讲客户端的组合方案：为什么机器上可能要同时装 11g Client 和 10g Client，以及 PLSQL Developer 怎么配才不报错。
4.1 11g Client 安装与 netca 配置
11g Client 的安装包独立于服务端，在客户端工具机上运行安装向导。安装类型有三档：管理员、运行时、自定义。我的选择标准很明确：工具机和管理员机器装「管理员」类型，它自带 Oracle ODBC/OLE DB 驱动和管理工具，PLSQL Developer 需要的部件全都有；应用服务器只装「运行时」类型，体积小、够用。
装完以后配连接串，用netca命令启动配置向导，走「本地 NET 服务名配置」：添加 → 输入服务名pacs→ 选 TCP/IP → 输入数据库服务器的 IP 或主机名 → 端口 1521 → 测试连接。测试通过说明客户端和服务端的通路已经建立。
这里有个关键细节：一台机器装了多个 Oracle 客户端（比如 11g Client 和 19c Client 共存），环境变量ORACLE_HOME和PATH的顺序决定 PLSQL 用哪个连接配置。我吃过亏：PLSQL 报找不到网络服务名，结果是因为ORACLE_HOME指向了 19c 的 home，读的是 19c 的 tnsnames。处理方式是打开「系统属性 → 环境变量」，把实际要用的ORACLE_HOME值改对，并把对应的bin目录挪到PATH最前面。
4.2 10g Client 的兼容性定位
项目里还涉及 Oracle 10g Client 的安装，乍看很奇怪，但这是现场常见需求。有些老 HIS/RIS 应用程序是用 OCI 10.2 版本编译的，11g Client 的 OCI 接口不认，驱动版本一升级程序就报错。这类场景只能给那台机器单独装 10g Client，保留老接口。
在 Server 2019 上装 10g Client 有两个注意点。第一，右键setup.exe选「属性 → 兼容性 → 以兼容模式运行：Windows 7」，不然安装向导可能无响应；第二，安装路径选独立目录，不要和 11g 的 home 混在一起，比如C:\oracle\product\10.2.0\client_1。两个版本的 client 是可以共存的，但 tnsnames.ora 一定不要改错位置，否则后面排查会让你怀疑人生。
4.3 PLSQL Developer 连接配置与常见报错
PLSQL Developer 的连接窗口有四个关键输入：用户名、密码、数据库下拉框（选择网络服务名）、连接身份（Normal 或 Sysdba）。下拉框里的网络服务名来自tnsnames.ora，所以配置顺序一定是：先配好网络服务名，再打开 PLSQL 连接。
tnsnames.ora的位置在客户端 home 目录下的network\admin，11g 的典型路径是C:\oracle\product\11.2.0\client_1\network\admin\tnsnames.ora。文件内容里常用的字段就几个：HOST填服务器 IP 或主机名，PORT填 1521，SERVICE_NAME填pacs。
| PLSQL 常见报错 | 典型原因 | 排查方向 |
|---|---|---|
| ORA-12154：TNS 无法解析指定连接标识符 | 网络服务名没写对，或 tnsnames 文件没被读进去 | 检查 ORACLE_HOME 指向、文件里名称是否一致 |
| ORA-12541：无监听程序 | 监听没启动，或客户端连错了 IP/端口 | 服务端执行 lsnrctl status 看监听状态 |
| ORA-12514：监听无法识别请求的服务 | 服务名与注册名不一致 | 服务端执行 lsnrctl services 查实际注册名 |
PLSQL 本身不参与网络协议转换，它完全依赖 Oracle Client 的驱动，也就是说客户端版本选错了，PLSQL 配置再正确也白搭。这也是为什么我建议先装好 Client、验证tnsping通了，再打开 PLSQL 排查图形界面问题。
5. 常见问题排查：19c Client 数据源、网络聚合与连接失败的坑
这一章解决两个高频需求：网络聚合配置、19c Client 数据源连接，同时把最容易翻车的几个问题按「现象→原因→解决」拆开写。这些都是项目资料里明确标注过的补充内容，也是现场最值钱的部分。
5.1 NIC 网络聚合：配置方法与模式选择
数据库服务器的网络可靠性直接决定业务连续性，单网卡故障恢复一次要几分钟，网络聚合后切换是秒级。Server 2019 自带的 NIC Teaming（服务器管理器 → 本地服务器 → NIC 组 → 新建团队）就能做，不需要额外装驱动。
创建聚合组之前先看模式，两种主流的选法：
| 模式 | 交换机要求 | 适用场景 |
|---|---|---|
| 交换机无关（Switch Independent） | 普通接入交换机即可 | 大多数机房场景，推荐 |
| 静态成组（Static Teaming） | 交换机需支持静态链路聚合 | 华为/华三核心交换机场景 |
| LACP 802.3ad | 交换机需开启 LACP | 高性能核心网络 |
负载均衡算法也要选对。通用场景选「地址哈希（Address Hash）」，它会按源/目的 MAC 和 IP 做负载分配；这台机器如果跑虚拟机或者容器，选「虚拟机端口（Hyper-V Port）」更合适。用 PowerShell 创建网络聚合组的命令如下：
# 查看当前物理网卡名称，确认哪两块网卡参与聚合 Get-NetAdapter # 创建名为 TEAM1 的聚合组，交换机无关模式 + 地址哈希 New-NetLbfoTeam -Name "TEAM1" -TeamMembers "以太网 2","以太网 3" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm AddressHash参数说明：TeamMembers必须写Get-NetAdapter查到的准确网卡名，写错会直接报错；TeamingMode选 SwitchIndependent 说明不需要交换机配合；LoadBalancingAlgorithm选 AddressHash 是通用性最好的方案。配置完成后，原来网卡上的 IP 会消失，需要在聚合组 TEAM1 上重新配置 IP。物理机上操作时先插好两根网线再创建，避免聚合组建成单腿状态。
5.2 19c Client 数据源连接详解
19c Client 在这套方案里的定位很特殊：解决部分情况下客户端不能连接数据库的问题。所谓「部分情况」，绝大多数是 11g 老库的密码协议不被新版客户端接受导致的。Oracle 11g 早期默认的密码版本是 10G 格式，19c Client 默认要求更严格的认证协议，两边对不上，连接就失败。
在 19c Client 的机器上，网络服务名配置方式和老客户端一样用netca，tnsnames.ora 格式不变。关键是 11g 服务端要放开认证协议限制，在服务端的sqlnet.ora里追加两行：
提示：编辑
%ORACLE_HOME%\network\admin\sqlnet.ora，追加下面两行后执行lsnrctl reload生效。
SQLNET.ALLOW_LOGON_VERSION_CLIENT=8 SQLNET.ALLOW_LOGON_VERSION_SERVER=8参数说明：ALLOW_LOGON_VERSION_CLIENT控制客户端允许的最低登录版本，值设为 8 表示允许 Oracle 11g 及以上版本的客户端登录；如果设成 12，11g 客户端会被拒绝，所以老环境千万别手滑改成 12。改完后重启监听，再用 19c Client 的tnsping测试连通性，最后通过 ODBC 数据源管理器创建系统 DSN，驱动选 Oracle ODBC Driver，填入服务名pacs就能建好数据源。
5.3 四条典型踩坑记录
下面四条是项目执行中最常遇到的坑，每条都是真实现场，按现象、原因、解决三段拆开。
坑一：19c Client 连 11g 报 ORA-28040
现象：客户端用 19c 驱动连接 11g 数据库，登录时报ORA-28040: No matching authentication protocol，应用日志里也是同样的错误。
原因：11g 数据库使用的密码版本（默认 10G 格式）在 19c 客户端看来是旧协议，认证不通过。本质是服务端的密码版本落后于客户端的默认要求。
解决：在 11g 服务端sqlnet.ora追加 5.2 节那两行参数，lsnrctl reload后重置一次该用户的密码（alter user 用户名 identified by 新密码;），再测试连接，立刻恢复。
坑二：监听服务无法启动
现象：Windows 服务里OracleOraDb11g_home1TNSListener点击启动后立即停止，事件查看器里记录监听启动失败，Oracle 服务端无法被客户端访问。
原因：监听器启动时绑定主机名失败或者端口被占用，常见于服务器改了主机名但 hosts 文件没同步，或者 1521 端口被其他进程占住。
解决：打开C:\Windows\System32\drivers\etc\hosts，确认新主机名和 IP 的映射存在；再执行netstat -ano | findstr 1521看端口占用情况，有进程占用就杀掉或换端口。修完执行lsnrctl start，看到The command completed successfully才算恢复。
坑三：ORA-12514 服务名不识别
现象：客户端tnsping能通，但 PLSQL 连接时报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。
原因：监听器起来了，但请求的服务名没有注册上去。这跟数据库实例没起来、动态注册失败、或者 tnsnames 里的 SERVICE_NAME 拼写不对都有关。
解决：服务端执行lsnrctl services，看实际注册的 SERVICE_NAME 是什么，把客户端 tnsnames 里的 SERVICE_NAME 改成一致的；如果实例没注册，确认数据库实例是否已启动（sqlplus / as sysdba查open_mode），再执行alter system register;手动触发注册。
坑四：10g Client 在 Server 2019 上安装无响应
现象：双击 10g Client 的 setup.exe，界面弹不出来或卡在初始化，等了十分钟还是没动静。
原因：10g 的安装程序太老，不认 Server 2019 的系统版本和 UAC 机制，被系统安全策略拦住了。
解决：右键 setup.exe → 属性 → 兼容性 → 勾选「以兼容模式运行这个程序」并选 Windows 7，同时右键选择「以管理员身份运行」。装的时候路径选独立目录，不要覆盖 11g 的 home。
6. 安装完之后的验证技巧：三分钟检查清单与日常巡检习惯
每次部署完 Oracle，我都会强制走一遍三分钟验证清单，确认无误才算交付。这套清单能覆盖 80% 的初始故障，比事后翻日志高效得多。
先跑服务端的三个基础检查。执行lsnrctl status，确认输出里Services Summary段下能看到 pacs 服务且状态为 READY；执行tnsping pacs，确认返回中耗时正常且有 OK 字样；然后sqlplus / as sysdba登录，查select name, open_mode from v$database;，正常应该返回READ WRITE。这三条连着过一遍，数据库本体就没问题了。
再检查 Windows 服务。services.msc里确认OracleServicePACS和OracleOraDb11g_home1TNSListener两个服务状态为「正在运行」，启动类型为「自动」。服务没设自动的话，服务器重启后数据库不会跟着起来，现场就会收到「数据库连不上」的告警，这属于交付前必须排掉的隐患。
最后看一眼数据库的告警日志开头部分，确认初始化阶段没有 ORA- 报错。路径在%ORACLE_BASE%\diag\rdbms\pacs\pacs\trace\alert_pacs.log，直接看最后 30 行即可。交付时我会把这个清单和输出贴到验收报告里，让甲方知道哪些是验证过的。
巡检习惯方面，我每台库都会固定做两件事：每周看一次归档目录和告警日志，每月跑一次表空间使用率查询。归档目录写满会导致数据库直接挂起，恢复动作是先清归档再alter database open;，这种故障完全可以提前预防，没必要等它发生。有一年一台库跑着跑着归档满了，业务全停，那次之后我每次部署都把归档路径和告警日志当作正式交付项检查，连客户端工具机的 tnsnames 解析也要当场tnsping一遍再签字。希望帮到你。
本文还有配套的精品资源，点击获取
