企业官网建设流程全解析

简介：面向需要在Windows Server 2019平台上部署Oracle 11g与19c的DBA、系统管理员和运维人员，这份图文指南将环境搭建、数据库安装与常见连接问题整合为一份可直接参考的操作手册。内容涵盖Windows Server 2019操作系统安装与磁盘分区、Oracle 11g/19c服务端安装部署、NIC网络聚合配置说明，以及Oracle 19c Client数据源连接详解；针对部分场景下客户端无法连接数据库的故障，整理了配置要点与排查逻辑。文档以截图配文的方式记录了从系统分区创建、数据库安装选项勾选到单实例库建立、PLSQL连接验证的完整步骤，能显著减少实施中的盲目摸索。资源以单个PDF文件形式提供，大小仅5.13MB，适合作为现场对照手册或内部分享资料。目前已有1855人学习下载，正在搭建或维护Oracle环境的技术人员可按步骤复现、查漏补缺。

1. Windows Server 2019 还是 Oracle 19c：这套图文解决的是部署全链路

拿到这份《Windows Server 2019下Oracle 11g,19c安装部署-图文》，别以为它只是教你把两个 Oracle 版本装进系统。实际跟一遍就会发现，这份资料解决的是完整链路：从 Windows Server 2019 的系统安装、磁盘分配、网络聚合（NIC Teaming），到 11g 服务端部署并创建影像归档业务库，再到 19c 服务端和 19c Client 的安装，最后收在数据源连接排错上。对经常在 Windows 服务器上部署数据库的运维和集成实施人员来说，这套流程可以少走不少弯路。特别是摘要里那句“解决部分情况下客户端不能连接数据库问题”，基本就是 11g 和 19c 混用时的血泪经验总结。下文我按实际部署顺序拆开讲清楚每一步的决策点、参数和踩坑位置。

2. 部署前的环境准备：NIC 网络聚合、磁盘规划与激活策略

2.1 网卡 Teaming 的先决条件与 Windows Server 2019 配置参数

在装 Oracle 之前先做网络聚合，这个顺序很多人会跳过，但生产环境里数据库服务靠的就是 1521 端口的稳定性，物理链路一旦单点故障，后面客户端全部连不上。摘要里专门提到“NIC 网络聚合配置说明”，对应的就是 Windows Server 2019 自带的 NIC 组合功能。先决条件有两个：至少两块物理网卡，且两块网卡都能被系统正常识别；交换机侧可以不配链路聚合，因为这里用的是“交换机独立”模式，这也是最常见的做法。

在 Server Manager 的“本地服务器”面板里找到“NIC 组合”状态，默认是“禁用”。点击进去新建团队，勾选参与聚合的物理网卡，比如 Ethernet0 和 Ethernet1。团队模式选“交换机独立”，负载平衡算法选“动态”，备用适配器默认“无”。创建完成后，需要给这个团队重新配置 IP 地址，因为网卡原有的 IP 配置不会自动迁移过来。

# 用 PowerShell 创建 NIC 团队 New-NetLbfoTeam -Name "Team1" -TeamNicName "TeamNIC1" ` -TeamingMode SwitchIndependent ` -LoadBalancingAlgorithm Dynamic ` -TeamMembers "Ethernet0","Ethernet1"

这段命令的核心参数是SwitchIndependent，它意味着交换机不需要做链路聚合配置，两块网卡之间由系统自行协商负载；Dynamic则同时兼顾了出站和入站流量，适合数据库这种既有大量查询又有备份流量的场景。配置完成后用Get-NetLbfoTeam可以确认团队状态是否为 Up。有一点容易忽略：NIC 组合不要和 Hyper-V 虚拟交换机混用，如果这台机器后面要开虚拟机，先把虚拟交换机建在团队网卡之上，顺序反了会导致虚拟网络频繁断连。

2.2 磁盘规划的常见做法：系统盘与数据盘分离

系统安装过程中只分配 C 盘给操作系统，剩余磁盘空间全部留到系统装完以后，在磁盘管理里做二次分配。这一步不是嫌麻烦，而是为了让数据库的数据文件、归档日志和备份文件能独立放在单独的分区上，避免和系统日志、页面文件争抢磁盘 I/O。我在某集成商做实施时通常会把数据盘按逻辑划分成三个区：数据区、归档区、备份区，分区大小按业务量预估。

# PowerShell 快速为剩余空间创建分区 Get-Disk -Number 1 | Initialize-Disk -PartitionStyle MBR New-Partition -DiskNumber 1 -DriveLetter D -Size 200GB Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "DATA"

Initialize-Disk用于初始化新磁盘，PartitionStyle选 MBR 还是 GPT 取决于服务器是否支持 UEFI，老机器 MBR 更稳妥；New-Partition的Size按业务需求填，如果是一整块大磁盘分多个区，就重复执行并调整盘符；Format-Volume的FileSystem固定选 NTFS，Oracle 在 Windows 平台上只支持 NTFS。装完记得把 Oracle 安装包也放到一个独立目录，路径中不要有中文和空格，否则后面安装程序会报找不到文件。

2.3 激活策略与 administrator 密码的边界

文档里明确写“我没有产品密钥”，这个选项不是跳过激活，而是先装系统，激活动作放到操作系统安装成功以后再做。在真实部署里，离线环境经常遇到无法联网激活的情况，所以这个顺序是合理的。不过要留意：不激活不影响装 Oracle，但如果系统长期不激活，桌面会持续出现水印，部分远程桌面功能也可能被限制，生产环境里尽量在切业务前完成激活。

administrator 密码的设置是系统安装完成后第一个交互动作，密码必须满足复杂度要求，即包含大写、小写、数字或符号中的三类。密码遗忘的处理成本很高，尤其是域外服务器的本地管理员密码，建议第一时间录入内部密码管理平台。还有一个容易忽略的点：在装 Oracle 前，确认系统防火墙对 1521 端口的入站规则处于可配置状态，很多客户端连不上的问题，根因不在数据库，而在防火墙默认拦截。

3. Oracle 11g 服务端安装：从 SETUP 到 PACS 数据库创建的完整流程

3.1 版本选型：为什么是 11.2.0.4 而不是 11.2.0.1

这套图文里选的是 11.2.0.4，这个版本是 11g 系列的最终补丁集版本，稳定性经过大量生产环境验证。很多老的影像归档业务系统、HIS 系统至今仍跑在 11g 上，选这个版本不是保守，而是业务兼容性决定的。Oracle 11g 的安装包部署方式很直接：把安装介质拷贝到服务器本地，双击 setup.exe 即可，安装包放网络共享路径有时会触发权限问题，本地执行最省事。

安装启动后会出现一个提示窗口，这里不要勾选“我希望通过 My Oracle Support 接收安全更新”，这一步只是省掉订阅邮箱配置。之后会弹出一个确认跳过的对话框，点“是”继续，再选择“跳过软件更新”——生产环境里软件更新不能随便打，尤其是有业务在跑的库，升级补丁应该放到独立的变更窗口处理。这三个步骤是图形化安装的固定动作，每次装都会遇到。

3.2 图形化安装的四个关键决策点

第一个决策点是“仅安装数据库软件”，这里不要选“创建并配置数据库”。我的做法是先把软件装好，再用 DBCA 单独建库，这样的好处是软件安装和建库解耦，软件出问题不用连带重建数据库。第二个决策点是“单实例数据库安装”，除非是 RAC 环境，否则单实例是唯一选项。第三个决策点是安装类型，通常选“企业版”，功能完整，字符集等高级选项后续都能用到。第四个决策点是 Oracle 基目录路径，默认在 C 盘，如果 C 盘空间紧张，可以改到 D 盘，但必须记住路径，后面环境变量和脚本都要用到。

这一步还会弹出“ORA-12560”相关的前置检查警告，属于正常现象，安装程序会自动处理。要注意的是安装过程中会检查物理内存和页面文件大小，如果页面文件设置过小，安装会中止。Windows Server 2019 默认的页面文件管理在内存充足时一般没问题，但 11g 安装器对虚拟内存的检测偏保守，建议提前把系统管理页面文件改为自定义，初始大小设为物理内存的 1.5 倍。

3.3 用 DBCA 创建 PACS 数据库与初始化参数

软件装完后会自动弹出 DBCA，也可以手动在命令提示符里执行 dbca 调出图形界面。这里创建的库就是摘要里提到的“pacs 数据库”。建库时注意三个关键设置：全局数据库名填 pacs，SID 填 pacs，字符集选 AL32UTF8。字符集选错是最大的翻车点，业务系统里有中文描述字段，如果选了 WE8MSWIN1252 这类旧字符集，后面导入中文数据大概率乱码。

# DBCA 静默建库示例 dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname pacs -sid pacs \ -characterSet AL32UTF8 \ -memoryPercentage 40 \ -emConfiguration NONE

-memoryPercentage 40表示让 Oracle 自动管理内存时最多使用物理内存的 40%，这是保守值；如果机器内存只有 16G，建议先按这个比例建库，后续再根据监控数据调整。-emConfiguration NONE跳过 Enterprise Manager 配置，生产环境里 EM 用的人不多，还会额外吃内存端口资源，不配省心。建库完成后，用以下 SQL 检查关键初始化参数：

-- 检查 SGA 与字符集设置 SELECT name, value FROM v$parameter WHERE name IN ('sga_target','pga_aggregate_target','processes','db_block_size'); SELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET';

SGA_TARGET和PGA_AGGREGATE_TARGET决定数据库内存池容量，如果建库时用了自动内存管理，这两个参数会显示为 0，实际值由系统动态分配；PROCESSES默认 100，并发连接多的系统要提前调到 300 以上；db_block_size显示 8192 就是标准 8K 块，一般无需改动。注意如果在 DBCA 里忘记指定字符集，装完再改字符集非常痛苦，只能重建库，这一点务必在建库时就确认。

3.4 监听与服务自启验证

安装完成后，Windows 服务列表里会出现两个核心服务：OracleServicePACS和OracleOraDb11g_home1TNSListener。前者是数据库实例服务，后者是监听服务。两个服务都建议设为“自动”，否则服务器重启后监听不启动，客户端全部连不上，这类问题在项目上线后最容易被当成数据库故障，其实是服务没设自启。

# 查看监听状态 lsnrctl status # 用系统账号登录数据库验证 sqlplus / as sysdba select name, open_mode from v$database;

lsnrctl status输出里需要确认监听端口确实是 1521，并且能看到针对 pacs 实例的服务注册信息；如果不显示服务名，多半是监听配置里缺少静态注册，稍后在 19c Client 连接环节会遇到类似问题。v$database的open_mode显示READ WRITE才说明库正常打开，如果显示MOUNTED或READ ONLY，需要手动执行ALTER DATABASE OPEN;。

4. Oracle 19c 服务端安装：版本差异、静默安装与参数调整

4.1 11g 和 19c 在 Windows 上的部署差异

Oracle 19c 和 11g 在 Windows Server 2019 上的部署流程看起来相似，实际差异不小。首先是安装包形态：19c 的介质通常是两个 zip 压缩包，必须把两个包解压到同一个目录再执行 setup.exe，只解压一个会导致安装文件不全，报错信息往往是“文件缺失或损坏”。其次是安装时长明显变长，19c 的组件体积比 11g 大很多，在机械硬盘上安装可能需要 30 到 60 分钟，这是正常现象，不要中途取消。第三是内存占用：19c 对物理内存的最低要求比 11g 高，建议至少 8G 内存再跑 19c。

路径方面比 11g 更严格：Oracle 基目录和 Oracle 主目录的路径中绝不能有中文、空格或特殊字符。实践中踩过这个坑，把 19c 装在D:\数据库软件这种中文路径下，安装过程不报错，但启动监听时找不到listener.ora，排错查了半天才发现是路径编码问题。

4.2 19c 安装引导与关键参数

安装引导基本沿用 11g 的操作习惯：跳过安全更新、选择仅安装数据库软件、单实例安装。有一个界面细节值得留意：19c 安装过程中会询问“Windows 用户凭据”，这里要求提供一个有管理员权限的 Windows 用户，用于 Oracle 服务运行。很多人直接用了administrator，但严格的安全规范应该是单独建一个专用服务账号，避免 Oracle 服务以系统最高权限运行。

# 配置当前终端的环境变量 set ORACLE_HOME=D:\app\oracle\product\19.0.0\dbhome_1 set ORACLE_SID=pacs19 set PATH=%ORACLE_HOME%\bin;%PATH%

ORACLE_HOME必须指向 19c 自己的主目录，不能沿用 11g 的路径；ORACLE_SID设成准备创建的库名，与 11g 并存时建议区分命名，减少混淆。这里可以顺便把系统环境变量也更新一遍，否则每次打开新终端都要重新 set。注意如果之前装过 11g，PATH里可能同时存在两个 Oracle 的bin路径，优先级靠前的那个版本会被先找到，这也是很多客户端工具连错版本的原因之一。

4.3 19c 安装后的启动参数调整

19c 安装完以后，默认的memory_target是自动管理的，如果服务器内存不够大，自动内存管理会导致实例启动后系统出现内存抖动。我的习惯是关闭自动内存管理，改为手动指定 SGA 和 PGA 上限，数值根据物理内存的 40% 到 50% 来分配，配合监控再微调。

-- 切换到手动内存管理模式 ALTER SYSTEM SET MEMORY_TARGET=0 SCOPE=SPFILE; ALTER SYSTEM SET SGA_TARGET=4G SCOPE=SPFILE; ALTER SYSTEM SET PGA_AGGREGATE_TARGET=1G SCOPE=SPFILE; SHUTDOWN IMMEDIATE; STARTUP;

MEMORY_TARGET=0是关闭自动内存管理的关键，不关的话 SGA 和 PGA 的设定值会被忽略；SGA_TARGET=4G表示总 SGA 上限 4G，这个值要根据服务器物理内存折算，比如 16G 内存给到 6G SGA 也合理，关键是别超过物理内存的 70%；SCOPE=SPFILE确保参数写入服务器端参数文件，重启后仍然生效。执行后SHUTDOWN IMMEDIATE和STARTUP是让参数生效，不重启实例也可以在线调整部分参数，但 SGA 相关改完通常需要重启才能看到完整效果。

5. Oracle 19c Client 连接问题排查：数据源配置与四个高频坑

5.1 版本兼容矩阵：19c Client 连 11g 服务端是常态

客户端版本和服务端版本没有强制绑定关系。19c Client 连接 11g 服务端完全可行，这也是摘要里“解决部分情况下客户端不能连接数据库问题”的背景之一。但反过来，老版本客户端连新版本服务端往往不行，比如 11g Client 连 19c 经常会出协议不兼容的问题。从我接触过的环境看，最常见的部署组合是：服务端跑 11g 或 19c，客户端清一色装 19c Client，这样以后服务端升级到 19c 时客户端不用跟着动。

5.2 tnsnames.ora 与 ODBC 数据源的两种配置路径

客户端连接数据库有两种主流配置方式：一种是配置tnsnames.ora文件，供 SQL Developer 和 PLSQL Developer 这类工具使用；另一种是配置 ODBC 数据源，供业务系统通过 ODBC 驱动访问。两种方式底层用的都是 Oracle Net 服务，但配置入口不同。

# 客户端 tnsnames.ora 配置片段 PACS = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = pacs) ) )

SERVICE_NAME这一行是关键，很多排错问题都出在这里。注意 11g 建库时如果指定了服务名，默认就是全局数据库名，即pacs；如果建库时没单独设置服务名，服务名和 SID 相同，但两者在概念上不是一回事。ODBC 配置路径是：控制面板 → 管理工具 → ODBC 数据源管理器(64位) → 系统 DSN → 添加 Oracle 驱动 → 填入 tnsnames 里的服务别名、用户名和连接字符串。这里最容易犯的错是选了 32 位 ODBC 管理器，业务系统如果是 64 位的，两边不匹配会一直提示找不到驱动。

5.3 坑 1：ORA-12541 监听没起来

现象：客户端连接时报ORA-12541: TNS:no listener，PLSQL Developer 直接卡死或秒断。

原因：服务端 Windows 服务列表里OracleOraDb11g_home1TNSListener或 19c 对应监听服务没有启动。最常见是服务器重启后监听服务没跟着起来，或者因为端口被其他程序占用导致监听启动失败。

解决：在服务端执行lsnrctl start启动监听，然后执行lsnrctl status确认监听端口是 1521。如果监听起来了仍报错，用netstat -ano | findstr 1521检查端口是否真的在监听，同时确认客户端配置里的 HOST 地址能 ping 通服务端。

5.4 坑 2：ORA-12514 把 SERVICE_NAME 写成 SID

现象：连接串里填的SERVICE_NAME不对，报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。

原因：这是一个高频误操作。很多人以为服务名就是 SID，直接填了pacs，但服务端注册到监听器的是全局服务名。如果建库时默认服务名是pacs，那一致；如果服务名带上了域名后缀比如pacs.example.com，客户端填pacs就报 12514。部分 19c 环境默认创建的 PDB 服务名是pdbname，和实例名 SID 不同，更容易混。

解决：在服务端执行lsnrctl services，查看监听器实际注册出来的服务名是什么，把这个名字原样填到客户端的SERVICE_NAME字段。另一种省事做法是把连接描述符改成(CONNECT_DATA = (SID = pacs))走 SID 方式连接，但不推荐长期使用，服务名才是标准做法。

5.5 坑 3：防火墙拦了 1521 端口

现象：客户端 ping 服务端网络通，telnet 1521 端口不通，连接超时或者报ORA-12535。

原因：Windows Server 2019 防火墙默认拦截入站 1521 端口。数据库监听本身没问题，但数据包进不来。这个坑容易让人误判成监听故障，反复重启监听器都无效。

解决：在服务端放行入站规则，用管理员权限执行：

# Windows 防火墙放行 1521 端口 netsh advfirewall firewall add rule name="Oracle1521" dir=in action=allow protocol=TCP localport=1521

dir=in是入站方向，action=allow是允许，protocol=TCP localport=1521指定端口。加完后用telnet 192.168.1.10 1521验证，能通就说明数据链路正常。注意如果存在多个防火墙配置文件，比如域配置文件、专用配置文件，需要在对应生效的配置文件中都添加规则；执行后可以用netsh advfirewall firewall show rule name=Oracle1521确认规则已存在。

5.6 坑 4：ORACLE_HOME 指向 11g 导致的版本错乱

现象：同一台服务器上装了 11g 和 19c 两套环境，客户端工具打开后显示的版本是 11g，连接 19c 库时行为异常，甚至报ORA-12560。

原因：Windows 环境变量PATH中 11g 的bin目录排在 19c 之前，命令行工具sqlplus或tnsping实际加载的是 11g 的客户端库，版本错位导致连接行为不可控。

解决：在命令提示符里先执行where sqlplus看解析出来的实际路径；再用开头提到的方式，把当前终端的ORACLE_HOME指向 19c 目录：

# 确认当前生效的客户端版本 sqlplus -V # 临时切换到 19c 环境（当前终端生效） set ORACLE_HOME=D:\app\oracle\product\19.0.0\dbhome_1 set PATH=%ORACLE_HOME%\bin;%PATH% sqlplus -V

sqlplus -V输出里包含版本号，可以一眼看出当前生效的是哪个版本。如果切换后仍有问题，检查系统环境变量PATH里是否多个 Oracle 路径并存，调整顺序让 19c 靠前；更彻底的做法是删掉多余版本的bin路径，只保留正在使用的那套。

6. 验证部署结果：用 PLSQL 压测与 NIC 聚合的最终确认

部署全部完成后，建议按下面的顺序做一次完整验证，别急着切业务。先用 PLSQL Developer 连一次主库，跑一段简单的读写测试：

-- 建临时表测试读写 CREATE TABLE DEPT_TEST AS SELECT * FROM DEPT; INSERT INTO DEPT_TEST VALUES (50, 'TEST', 'BEIJING'); COMMIT; SELECT COUNT(*) FROM DEPT_TEST; DROP TABLE DEPT_TEST PURGE;

CREATE TABLE AS SELECT能同时验证建表权限和查询能力；INSERT和COMMIT验证写事务；COUNT(*)验证读一致性；DROP TABLE ... PURGE清理测试对象，避免留垃圾对象影响后续统计信息。整个流程走通，说明数据库的基本连接、读写、事务都没问题。

接着验证服务端网络层：在新开一个终端里执行lsnrctl services，对比输出的服务名和客户端tnsnames.ora里配置的SERVICE_NAME是否完全一致。再执行tnsping pacs，确认客户端到服务端的 Oracle Net 链路是通的，这个工具给出的延迟值和错误信息比裸 telnet 更贴近数据库层的判断。

最后是 NIC 聚合的最终验证，这一步最容易跳过，但恰恰最能检验前期网络聚合配置是否真正生效。找一根连接在聚合团队上的网线，在业务空闲时段直接拔掉，观察 PLSQL Developer 的当前会话是否断开。正常情况下，由于负载均衡和故障转移的存在，已建立的 TCP 会话会短暂中断重连，但新会话应该立即恢复；如果拔线后所有连接长时间无法恢复，说明聚合配置只是“看起来激活”，实际没有生效。常见的原因是对端交换机开启了 STP 导致收敛时间过长，解决办法是在交换机端口上设置spanning-tree portfast edge。

做完这套验证，我自己的习惯是把关键命令和输出截图留档，包括lsnrctl status、sqlplus -V、Get-NetLbfoTeam三份结果。从那以后我每次部署 Oracle 到 Windows Server 2019，都强制走一遍“网络聚合 → 磁盘规划 → 装服务端 → 装客户端 → 连接排错 → 拔线验证”这个顺序，不再跳步。希望这份拆解帮到你，照着操作能少踩几个坑。

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