企业官网建设流程全解析

简介：ODAC 11.2.0.3.20 32位驱动包是专为.NET开发者准备的Oracle 11.2.0.3数据库连接组件，解决在32位应用程序中访问Oracle时常见的驱动缺失、版本错配以及无法正常建立数据库会话等问题。压缩包约51.43MB，主要包含ODAC安装部件与环境配置脚本，用户按说明完成基础部署后，将相关程序集注册到全局程序集缓存，即可让全部.NET项目直接引用，省去手工拷贝和注册的麻烦。资源已在CSDN平台获得1138人次浏览或学习，适合从事企业级系统开发、维护旧版Oracle连接环境或学习ODP.NET部署流程的中级工程师。拿到压缩包后，除获得可用的32位驱动外，还可结合安装脚本理解GAC注册机制与Oracle客户端环境变量配置，后续部署过程中遇到依赖库缺失、权限不足或架构不匹配引发的运行时报错时，也能更快定位问题，提升开发和运维效率。

1. ODAC 1120320Xcopy部署：不装Oracle客户端，让32位应用直连数据库

ODAC 1120320Xcopy_32bit.zip 这个压缩包，第一眼看上去像普通补丁，其实是 Oracle Data Access Components（ODAC）11.2.0.3.20 的 Xcopy 模式 32 位部署包，专为“不在目标机器上安装 Oracle 客户端”的场景准备。核心价值一句话能说清：把 ODAC 当成绿色软件用，解压、配置、复制即用，应用连 Oracle 不再依赖安装向导写进注册表的一堆痕迹。

它解决的问题很具体。内网服务器不允许装额外软件、同一台机器要共存多个 Oracle 客户端版本、或者你正在写无人值守部署脚本——常规安装向导在这些场景下会变成麻烦制造者，而 Xcopy 模式把整个运行环境压缩到一个目录，路径、网络别名和驱动引用全部由你自己控制。适合的读者是手里攥着这个 zip、却不知道从哪步开始的开发、运维或实施人员；读完能照着把连接跑通，也能提前避开那些让部署反复翻车的坑。

2. 先看明白ODAC 11.2.0.3.20的构成：版本、组件与32bit选型

2.1 ODAC包里到底有什么：从ODP.NET到Instant Client

ODAC 不是单个 DLL，而是一组数据访问组件的集合。文件名里的 1120320 可读成 11.2.0.3.20，也就是面向 Oracle Database 11g Release 2 的配套组件。一个典型的 Xcopy 包，文件会按目录组织，常见的有 ODP.NET（Oracle.DataAccess.dll 和 Oracle.ManagedDataAccess.dll）、Oracle Providers for ASP.NET、Oracle Instant Client 的运行库（比如 sqlplus.exe、oci.dll、tnsnames.ora 样例），部分版本还会带 Visual Studio 开发安装文件。Xcopy 部署的两个关键词是“解压”和“路径自包含”，它不像安装包那样把文件散落到 Program Files、System32 和注册表，而是全部集中在解压目录里。

版本上有个容易被忽略的点：ODAC 的版本要和数据库服务器版本“就近”选择，不用追求完全一致。我一般按服务器版本就近原则选，服务器是 11.2 就用 11.2 的 Xcopy 包；服务器是 19c 就选 19c 对应的驱动包。通用 OCI 接口让高版本数据库兼容低版本客户端通常没问题，但反过来，当数据库端用了新的认证或特性时，老客户端可能连握手都完成不了。与其在现场排查这类玄学问题，不如一开始就收紧版本范围。

这个包里的 ODP.NET 有两条路线。非托管驱动 Oracle.DataAccess.dll 要依赖本机 Oracle Client 运行库（oci.dll）才能工作；托管驱动 Oracle.ManagedDataAccess.dll 则完全不依赖本机 Oracle 组件，是纯 .NET 实现。11.2.0.3 时期的 ODAC 以非托管驱动为主流，Xcopy 包解压后可以先看一眼根目录下有没有 bin 目录、里面是哪个 dll，确认包的成分再动手。存量系统至今还有一批结构用 Oracle.DataAccess.dll，就是因为生产环境跑着 11.2 的库，驱动不敢随便换。

2.2 Xcopy部署和安装向导：一个绕开注册表的路径

常规 Oracle 客户端安装会做三件事：把文件复制到指定目录、在注册表写下 Oracle Home 信息、改写 PATH 和系统服务。安装完以后卸载还要走维护向导，卸载不干净是常事。Xcopy 模式把这三件事全部推回给你：文件由你解压，Oracle Home 由环境变量指定，网络别名靠 TNS_ADMIN 指向的 tnsnames.ora。代价是你得自己维护这些配置，但换来的收益是部署行为完全可脚本化、可版本化。这也是它在 CI/CD 和镜像构建流程里被选中的原因，Docker 里装 Oracle Instant Client 和 ODAC 的常用写法就是 COPY 加 ENV，跟这里 Xcopy 的本地操作是同一套逻辑。

三个最关键配置项：ORACLE_HOME 指向解压根目录，TNS_ADMIN 指向 tnsnames.ora 所在目录，PATH 要包含 %ORACLE_HOME%\bin，让系统能找到 oci.dll 和 sqlplus.exe。这三个值只要有一个没设对，后边的连接失败就是必然的，问题只是先报什么错。具体到注册表，Xcopy 模式原则上不写注册表；但非托管 ODP.NET 在个别版本中会在加载时去读 Oracle Home 标记，如果 sqlplus 一切正常、而 .NET 代码抛“requires Oracle client software”这类错误，再考虑补注册表项。我在默认情况下先不加，跑完第 4 章的验证再定。

2.3 为什么是32bit：架构对齐的三个判断标准

新买的机器几乎都是 64 位系统，但选 ODAC 的 32bit 还是 64bit，唯一标准是承载应用的进程架构，而不是操作系统位数。第一个判断依据：如果你的程序集编译成了 x86，那就必须用 32bit ODAC；如果是 AnyCPU 且在 Visual Studio 里勾了“Prefer 32-bit”，编译出的 exe 在 64 位系统上照样以 32 位进程运行，也得用 32bit。第二个判断依据：IIS 应用池如果被设成“启用 32 位应用程序 = True”，w3wp.exe 就是 32 位进程，ODAC 必须 32bit。第三个判断依据：目标机器上已有的 Oracle 客户端组件是 32 位且混在同一个 COM+/Windows 服务里，为了保证加载一致性，延续 32bit 更稳。

反过来也要说清楚边界：32bit ODAC 与 64 位 Oracle 数据库服务器之间完全可以正常通信。客户端位数只影响本机进程，跟远端数据库服务器的位数无关。有人误以为“服务器是 64 位就得装 64 位客户端”，由此造成的返工不在少数。只要进程是 32 位，哪怕跑在 64 位系统上，也老老实实用 32bit ODAC，架构错配的典型报错是 BadImageFormatException。

2.4 什么时候不该选11.2的ODAC：四个红灯

这个包也不是万能。第一，如果数据库已经升级到 21c 或 23ai，建议直接用对应新版的 ODAC，别拿 11.2 驱动硬顶，新特性支持跟不上。第二，如果项目是 .NET Core / .NET 5+，优先用 Oracle.ManagedDataAccess.Core，非托管驱动在 Core 上兼容性很差。第三，如果现场要求 Windows 集成认证、透明数据加密这类高级安全特性，Xcopy 包不一定带对应组件，装之前先检查包内清单。第四，如果同一台机器上跑着别的应用且强依赖某个特定 Oracle Client 版本，不要图省事直接把 ODAC 目录并进 PATH，宁可让各个应用通过独立 bin 目录引用驱动，也不要抢占全局路径。

3. Xcopy部署ODAC 32bit到目标机：解压、配置与注册步骤

3.1 解压与目录规划：Oracle Home路径的取舍

我一般把解压目录固定在 C:\oracle\odac32。不用 Program Files，不用中文路径。原因有两个：一是 Oracle 的不少组件对路径里的空格仍然敏感，虽然新版改善不少，但老版本踩过坑的都知道，一个带空格的家目录能把 PATH 拼接搞得很难看；二是这个目录就是事实上的 ORACLE_HOME，路径越短，后面设环境变量和写脚本时越不容易翻车。解压时注意保持 zip 内的目录结构，不要手动重新整理文件层级。

mkdir C:\oracle\odac32 cd C:\oracle\odac32 tar -xf ODAC1120320Xcopy_32bit.zip

逻辑说明：第一行创建目标目录，第二行进入该目录，第三行把 zip 解压出来。tar 命令在 Windows 10 1803 以后自带，其他系统也都有对应工具。如果你只有 PowerShell，也可以用 Expand-Archive -Path ODAC1120320Xcopy_32bit.zip -DestinationPath C:\oracle\odac32，效果一样，只是遇到同名文件时会多一步确认。解压完先确认根目录下存在 sqlplus.exe 或 bin 目录，zip 完整才有下一步。

3.2 用TNS_ADMIN配置tnsnames.ora：网络别名不生效的根源

Oracle 客户端默认在 %ORACLE_HOME%\network\admin 下找 tnsnames.ora。Xcopy 部署时 ORACLE_HOME 如果不是默认目录，或你想让多个程序共享同一套网络配置，设 TNS_ADMIN 指向更实用。先创建目录，再写文件：

ORCL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = orclpdb1)))

这段是标准的 Oracle 网络描述。ORCL 是应用里使用的连接别名，ADDRESS 段的 HOST 换成数据库服务器实际 IP，PORT 换成监听端口，SERVICE_NAME 是数据库实例的服务名而不是 SID。从 11g 开始 RAC 环境里 SID 无法唯一标识服务，所以统一用 SERVICE_NAME 更通用。写完后执行 setx TNS_ADMIN C:\oracle\odac32\network\admin。setx 只对之后新开的终端生效，当前窗口若要临时验证，可以先执行 set TNS_ADMIN=... 加载到当前会话。

3.3 环境变量与注册表项：Xcopy模式下哪些必须写

接着配置三个环境变量。顺序无所谓，值不要写错：

setx ORACLE_HOME "C:\oracle\odac32" setx TNS_ADMIN "C:\oracle\odac32\network\admin" setx PATH "C:\oracle\odac32\bin;%PATH%"

setx 写的是用户级环境变量，不会覆盖系统级已有配置。ORACLE_HOME 让 Oracle 组件知道运行库根目录，TNS_ADMIN 告诉驱动去哪找 tnsnames.ora，PATH 把 bin 目录放到最前，避免系统里其他 Oracle 残留的 dll 抢先加载。要注意的是，%PATH% 会把你当前终端已加载的路径一并写入，所以执行完环境变量里可能出现路径重复，通常无害，不必特意清理。

注册表这一节，Xcopy 模式原则上不用写。但非托管 ODP.NET 的某些版本在加载时会检查注册表里 Oracle Home 标记，缺少时抛异常。现场遇到这个问题，常见做法是打开 regedit，在 HKLM\SOFTWARE\ORACLE 下建一个键，写入与 ORACLE_HOME 对应的路径；具体键名不同版本有差异，出现报错后看异常消息里的“OracleHome”字样再补。我本人不提前写注册表，先用 sqlplus 验证，确有问题再补，否则容易给自己留一个日后难排查的冗余配置。

3.4 把Oracle.DataAccess.dll注册进GAC或应用bin目录

ODP.NET 驱动是强命名的 .NET 程序集，有两种消费方式。GAC 适合多应用共享，但现场环境往往没有 gacutil.exe，所以更常见、也更符合 Xcopy 思路的方式是直接把驱动复制到应用的 bin 目录，让它随应用走：

copy C:\oracle\odac32\odp.net\bin\2.0\Oracle.DataAccess.dll C:\app\bin\ copy C:\oracle\odac32\odp.net\bin\2.0\Oracle.DataAccess.dll.config C:\app\bin\

第一条复制驱动本体，第二条复制它的配置文件。ODP.NET 加载时会找同目录下的 dll.config，漏拷在大部分环境不会报错，但复制完整更保险。bin\2.0 表示驱动面向 .NET Framework 2.0 编译，在 .NET Framework 4.x 项目里引用它也能正常加载，CLR 会做版本兼容。

如果你的项目不是直接 new OracleConnection，而是用 DbProviderFactories 创建连接，还要在 app.config 或 web.config 里配置工厂节点：

<system.data> <DbProviderFactories> <add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=2.0.0.0, Culture=neutral, PublicKeyToken=89b483f429c47342" /> </DbProviderFactories> </system.data>

这段让 DbProviderFactories 能找到 Oracle.DataAccess.Client 对应的工厂类。直接 new OracleConnection 的代码可以不写，但依赖工厂的历史项目缺了它会在创建连接时抛“Failed to find provider”。PublicKeyToken 89b483f429c47342 是 Oracle 程序集固定的强名称公钥令牌，别改。

4. 验证ODAC部署：先跑通sqlplus，再写第一个ODP.NET连接

4.1 用sqlplus与tnsping确认网络层畅通

配置完成后先别急着写代码。打开一个新的 cmd 窗口，因为 setx 不刷新当前窗口，然后依次执行：

tnsping ORCL sqlplus system/密码@ORCL

tnsping 只测试客户端能否通过 tnsnames.ora 解析到服务并通过网络连到监听器，输出里能看到目标服务的完整描述和往返耗时。能显示 OK 结尾，就说明网络层和别名解析都没问题。sqlplus 能进到 SQL> 提示符，说明远端数据库的认证也通过了。这两步都过，再往下排查 .NET 驱动才有意义。

有一点值得提：sqlplus 随 Xcopy 包一起交付，相当于白拿一个排错工具。如果 sqlplus 都连不上，就不该先怀疑 ODAC 的 .NET 程序集，而是先解决网络层和认证层。tnsping 常见的两类报错里，ORA-12545 或 ORA-12170 多半出在从客户端到服务器的网络链路或防火墙，ORA-12514 则是 tnsnames.ora 里的 SERVICE_NAME 和监听配置对不上。先分清是哪一类，再决定动网络还是动 tnsnames。

4.2 一个最小C#连接测试：托管驱动与非托管驱动的差异

网络层通了之后，用 .NET 代码验证驱动加载。我习惯写一个十行左右的控制台程序，既验证连接串，也验证程序集能否被正确解析：

using System; using Oracle.DataAccess.Client; class OdacSmokeTest { static void Main() { string cs = "Data Source=ORCL;User Id=scott;Password=tiger;"; using (OracleConnection conn = new OracleConnection(cs)) { conn.Open(); using (OracleCommand cmd = conn.CreateCommand()) { cmd.CommandText = "select 1 from dual"; Console.WriteLine(cmd.ExecuteScalar()); } } } }

这段代码里 Data Source=ORCL 走的是 tnsnames.ora 里配的连接别名，User Id 和 Password 是数据库账号。Open 失败时异常消息里会带 Oracle 错误码，ORA-01017 表示用户名密码错误，ORA-12154 表示驱动解析不了别名。select 1 from dual 能执行成功，说明连接建立和 SQL 执行链路都正常。编译时用 csc 并引用 Oracle.DataAccess.dll，参考命令：csc OdacSmokeTest.cs /r:Oracle.DataAccess.dll。如果命令行找不到 csc，打开 Visual Studio Developer Command Prompt 或直接把代码放到常规 .NET 项目里构建。

这里要区分托管驱动和非托管驱动。上面的代码用的是非托管驱动 Oracle.DataAccess.Client；如果你把 using 换成 Oracle.ManagedDataAccess.Client，连接串和代码结构基本不变，但部署时只需要 Oracle.ManagedDataAccess.dll 一个文件，不依赖本机 Oracle 运行库。两种驱动不要混在同一个进程里，它们都叫 ODP.NET，但命名空间和 DLL 不同，混用时容易在连接池和错误排查上互相干扰。

4.3 连接失败时先看哪三个日志位置

驱动加载异常先看 Windows 事件查看器。“应用程序”日志下的 .NET Runtime 分类会记录程序集绑定失败信息，能直接看到失败原因是架构不匹配还是文件找不到，比在代码里盲猜高效得多。监听拒绝连接看数据库端的 listener.log，默认在数据库服务器的 $ORACLE_HOME\network\log\listener.log，里面有客户端 IP、请求的服务名和错误码。内网权限不够时让 DBA 帮忙拉一条记录即可。

还有一个容易被忽略的位置：tnsnames.ora 所在的目录里，如果之前做过调试，可能残留 sqlnet.log 或 trace 文件。这个文件会记录别名解析和连接重试的过程，报 ORA-12154 时特别有用。我遇到别名问题，会先在 tnsnames.ora 里加一个短别名做对照测试，用最小差异法快速定位是拼写错误还是监听器不认识服务。

4.4 不写tnsnames.ora也行：EZCONNECT连接串与场景

如果只是临时验证驱动，或者不想在机器上留下任何网络配置文件，可以用 EZCONNECT 方式直接在连接串里写完整网络描述。它绕过 TNS_ADMIN，连接串形如：

Data Source=192.168.1.10:1521/orclpdb1;User Id=scott;Password=tiger;

写法是“主机:端口/服务名”，省去了维护 tnsnames.ora 的步骤。使用场景很明确：云数据库实例、临时排障、或者一批测试机不想各自维护别名文件。但它不适合生产环境，因为连接信息被硬编码在配置里，换库就要改代码或改配置，可维护性比别名差。这里提它，是因为第 4.2 节的 smoke test 如果连不上，先换 EZCONNECT 试一次就能快速区分“别名配置问题”和“驱动问题”，定位效率能高一截。

5. ODAC 32bit Xcopy部署避坑清单：五条血泪记录和一组复位动作

5.1 ORA-12514监听程序无法识别：TNS_ADMIN指向错了

现象：sqlplus 报 ORA-12514，英文大意是监听器当前不识别请求的服务。诡异的是 tnsping 却是通的，这已经把问题范围从网络层缩到了服务名解析层。

原因：别名能解析到监听地址，但监听器不认这个 SERVICE_NAME。要么 tnsnames.ora 里 SERVICE_NAME 和数据库实际服务名对不上，要么 TNS_ADMIN 环境变量指向了旧目录，根本没有包含正确别名的文件。

解决：先 echo %TNS_ADMIN% 确认指向，再看这个目录下的 tnsnames.ora 里是否有你要的别名。如果别名对了，登录数据库执行 show parameter service_names，把 tnsnames 里的 SERVICE_NAME 改成一致。还有一种少见情况，监听里配置的是 SID，这时把 CONNECT_DATA 改成 (SID=xxx) 也能连，但不要 SERVICE_NAME 和 SID 同时写，容易给连接解析制造歧义。

5.2 BadImageFormatException：进程架构和驱动架构对不上

现象：程序启动直接抛 BadImageFormatException，或者 “An attempt was made to load a program with an incorrect format”。桌面调试有时一切正常，部署到服务器就炸。

原因：32bit ODAC 的 dll 被 64 位进程加载了。最常见是 Visual Studio 里调试正常，发布到 IIS 后崩，因为 w3wp.exe 默认 64 位。

解决：两个方向，要么把应用池改成 32 位启用，要么换 64bit ODAC 包重新部署。我的习惯是把部署目录按位数分开命名，C:\oracle\odac32 和 C:\oracle\odac64 并存，避免现场为省事覆盖掉其中一个。另外要检查项目里是否引用了别的 32 位原生 dll，只要进程是 32 位，驱动就跟着 32 位，这是唯一可靠的对齐方式。

5.3 IIS里连不上但桌面程序正常：应用池的32位开关

现象：桌面 exe 连库正常，同一个 bin 目录挂到 IIS 下就报 ORA-12154 或 “Oracle.ManagedDataAccess cannot load”。

原因：IIS 应用池默认 64 位，32bit ODAC 加载失败只是表象；更隐蔽的是用户级环境变量问题。桌面进程继承了你登录账户的环境变量，而 w3wp.exe 运行在 IIS 对应的账户下，读不到你 setx 到用户变量的 TNS_ADMIN。

解决：两步都要做。第一步，IIS 管理器里选中应用池，右键高级设置，把“启用 32 位应用程序”改为 True，再回收应用池。第二步，把 TNS_ADMIN 改到系统环境变量，并重启 IIS 服务。只做第一步会出现依然是代码连不上的情况，因为别名配置根本没进到工作进程的环境里。排查时优先看 w3wp.exe 的位数，再看它继承的环境变量。

5.4 连接时好时坏：多个Oracle客户端残留的dll冲突

现象：连接成功率不稳定，错误码也不固定，今天 ORA-12170，明天 ORA-12541，重启服务后短暂正常，随后又反复。

原因：系统 PATH 里既有 ODAC 的 bin，又有之前装过的 Oracle Client 目录。两个版本的 oci.dll 在进程加载时被随机命中，进程加载哪个版本取决于搜索路径顺序和缓存，表现出典型的时好时坏。

解决：把 %ORACLE_HOME%\bin 放到 PATH 最前面，并清理旧客户端残留目录。清理不了时，在应用进程启动时指定 DLL 目录，比如 .NET 应用在 Application_Start 或 Main 的开头调用 SetDllDirectory 指向 ODAC 的 bin，强制跳过其他目录。这里没有别的玄学，就是 dll 搜索顺序问题。

5.5 换机器后直接复制整个目录：忘了环境变量等于没部署

现象：把 C:\oracle\odac32 整体拷到新机器，跑 sqlplus 报 “SP2-0671: Oracle SQL*Plus not properly installed”或其他找不到组件的错误。

原因：Xcopy 部署的本质是“文件 + 环境变量”。文件拷过去了，环境变量没配置，等于只做了一半。新机器上 ORACLE_HOME 和 PATH 都指向别的路径或不存在。

解决：新机器重新执行 3.3 里的三条 setx 命令，再继续验证。这也是为什么我坚持把环境变量配置写进部署脚本，而不是靠现场手工敲。把环境变量当成 Xcopy 部署的后悔药，机器一换或者账号一换，就得重来一遍，没有任何捷径。

5.6 连接一直不正常？按这三步复位再谈别的

现象：上面五条都排查过，仍有间歇性失败，或者改了配置后状态没变化。

原因：Xcopy 部署最隐蔽的问题是新配置生效不平等。IIS 应用池、Windows 服务、Visual Studio 调试进程都可能在退出时没释放 dll 句柄，导致你改的路径和配置没被重新加载。

解决：第一步，确保所有使用 Oracle 的进程退出，包括 w3wp.exe、sqlplus、调试进程。第二步，删除解压目录下可能生成的 sqlplus.log、sqlnet.log 等日志文件，避免旧 trace 干扰判断。第三步，直接重启机器，不行就重启相关服务，再跑一遍 4.1 的 tnsping。做完这三步复位，剩下的报错基本都是配置差异，可以回到对应条目继续查。

6. 把Xcopy部署沉淀成标准流程：一个setup脚本与交付清单

6.1 setup.bat：一条命令完成解压与配置

手动操作容易漏，尤其是新来的同事第一次现场部署。我一般把前面所有步骤收进一个 setup.bat，到新机器上先跑一遍，再人工核对输出：

@echo off set ODAC_HOME=C:\oracle\odac32 set ODAC_ZIP=ODAC1120320Xcopy_32bit.zip if not exist "%ODAC_HOME%\sqlplus.exe" ( powershell -Command "Expand-Archive -Force -Path '%ODAC_ZIP%' -DestinationPath '%ODAC_HOME%'" ) setx ORACLE_HOME "%ODAC_HOME%" setx TNS_ADMIN "%ODAC_HOME%\network\admin" setx PATH "%ODAC_HOME%\bin;%PATH%" tnsping ORCL

逻辑说明：if 判断避免重复解压，第一次跑会解压，第二次跑会跳过。setx 写环境变量，tnsping 做最后的自检。脚本不写注册表、不注册 GAC，保持 Xcopy 目录的可替换性，换版本时只需替换 zip 和名称。

参数说明：如果 tnsnames.ora 不是预先放在 network\admin 下，脚本里要先创建目录并写入文件。否则 TNS_ADMIN 指向空目录时，tnsping 会报 ORA-12154，而脚本却显示退出成功，这类失败最容易迷惑人。最好在脚本里加一步检查：如果 network\admin\tnsnames.ora 不存在，直接提示并退出。

6.2 交付时的三个验证项

给同事或实施人员交付时，不要只丢一个 zip 和一段文字。列出验证项，让现场人员自己确认，比事后排障便宜得多：

第一项验证配置解析，第二项验证网络和认证，第三项验证驱动与代码路径。三项全过，这份部署才算走完。第三项的命令可以用 csc 编译，也可以丢进现有测试工程直跑，关键是要验证到实际会被应用使用的驱动类型。

我自己到现场的习惯是每个环境留一份 DEPLOYMENT.md，记录 ODAC 版本、解压目录、TNS_ADMIN 指向、32bit 还是 64bit、连接串样例。Xcopy 部署灵活，但也因为灵活，三个月后没人记得当时路径是怎么配的，这份记录比再一次排错要便宜得多。另外我会在公共目录保留 32bit 和 64bit 两份 zip，到现场先看进程位数，再看数据库版本，再决定用哪个，架构先对齐部署就成功了一半。这个方向值得投入，因为一旦固化成脚本加文档，之后每台新机器上线基本能在十分钟内完成，省下的排障时间远超当初写脚本的成本。希望帮到你。

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