Oracle EBS系统管理员手册：用户、职责、配置文件与并发请求运维实战

简介：Oracle EBS系统管理员培训手册是一份面向Oracle EBS系统管理员的基础培训资料，以Oracle应用产品11i中文版为操作背景，系统讲解应用系统日常运维中的核心模块。内容覆盖安全管理、并发程序及请求管理、预置文件管理、弹性域与值集设置、单据序列管理、安全性控制及打印机设置等关键操作，帮助管理员从零掌握责任定义、用户维护、登录监控、请求生命周期跟踪、请求集与请求组配置等实用技能。资源为单个doc格式文档，大小约1.44MB，便于直接阅读和按章节检索。手册结构清晰，按单元划分培训目标并配有练习，内容预览中可见应用系统安全管理、并发程序和请求管理、顾客预置文献管理、关键性描述性弹性域及值集、单据序列号管理等完整模块。每个模块都结合实践示例展开，如定义责任与用户、监控登录顾客、提交和查看请求、修改请求阶段和状态、设置系统预置文件、定义值集等，能够为日常运维和问题处理提供直接参考。整体定位适合希望系统提升Oracle EBS运维能力的学习者，目前已有58人学习。

1. 系统管理员培训手册没直说的事：EBS运维的核心是对象关系而非菜单操作

刚接手 OracleEBS 系统管理员岗位的人，大多经历过同一个场景：拿到一本《OracleEBS系统管理员培训手册.doc》，照着文档把用户建了、职责给了、配置文件查了，看起来该做的都做了，可业务人员那边照样登录报错、并发请求卡住、菜单缺项。问题往往不出在操作步骤，而出在手册默认你已经理解了对象之间的关系。这份培训手册真正要教的东西，是 EBS 系统管理员需要管好的四类核心对象——用户、职责、配置文件、并发请求——以及围绕它们展开的授权、排错和日常运维。它适合刚接手 EBS 运维的 DBA 和 IT 支持人员，也适合从功能顾问转岗、需要补系统侧知识的从业者。下文按这套管理体系的落地顺序展开：先建立对象模型，再做权限配置，然后落到巡检、补丁、备份这些日常操作，最后把高频故障的排查路径讲清楚。

2. 先建立对象模型：用户、职责、配置文件与并发请求的四种关系

2.1 用户与职责：EBS 授权为什么不直接绑账号

很多从传统 ERP 转过来的管理员，第一反应是「给账号授权」，但 EBS 的设计不是这样。EBS 里用户（FND_USER）只是一张身份凭证，它本身不携带任何功能权限；真正决定你能看到什么菜单、能提交什么请求的，是职责（FND_RESPONSIBILITY）。这套设计的好处是：一个用户可以挂多个职责，一个职责可以分配给多个用户，权限单元可以独立维护。比如财务部十个人都要用「应付会计」职责，管理员只需要维护这一个职责，再把十个人分别关联进去，而不是给十个人各配一套菜单和请求权限。

职责本身也不是一张空壳。定义一个职责时，至少要绑定三样东西：菜单（决定登录后能看到哪些功能）、请求组（决定能提交哪些并发程序）、数据组（决定访问哪些应用数据）。这三者只要缺一个，用户分配了职责也会出现「菜单空白」或「请求报错」的现象。培训手册里通常会把这些拆成独立章节讲，但实操时它们是同时生效的——这也是新管理员最容易顾此失彼的地方。

2.2 配置文件：影响全局行为却又最难排查的参数体系

配置文件（Profile Option）是 EBS 里最容易被低估的一类对象。它本质上是一组全局参数，控制着登录语言、日期格式、币种、打印输出、并发请求的输出文件格式等系统行为。你不需要写代码、动表结构，只需要在「系统配置文件」界面里给某个参数赋一个值，系统行为就会跟着变。听起来很简单，但真正排查问题时，配置文件往往是那个「黑匣子」：你在用户层级改了参数，用户反馈没生效；你在站点层级改了参数，结果全公司都收到了影响。

难排查的原因在于，每个配置文件的值可以同时存在多个层级。系统启动或会话建立时，会按「站点级 → 应用级 → 职责级 → 用户级」的顺序取值，用户级优先。也就是说，你在用户级给某个参数设了一个值，它就会覆盖职责级、应用级、站点级的设置，哪怕职责级已经「看起来配置好了」。培训手册里会给出配置界面的路径，但很少强调这个优先级关系，结果就是新手排查半天，最后发现某个低层级的旧值一直在生效。

2.3 并发请求与并发管理器：吞吐瓶颈通常不在这张表

业务人员提交的报表、数据接口、批处理任务，在 EBS 里统称为并发请求（Concurrent Request）。请求提交后不会立刻执行，而是进入请求表排队，由并发管理器（Concurrent Manager）负责调度。这个机制把「提交」和「执行」解耦了——请求多的时候排队，管理器空闲了就取出来跑，用户随时可以查进度。

新管理员常犯的错是：请求卡住了，第一时间去看业务数据、去查请求的参数，却忘了先看并发管理器本身是不是还活着。并发管理器是一个独立的后台进程体系，包含标准管理器、内部管理器，以及按业务配置的各种专用管理器。如果管理器进程挂了，或者某个管理器的进程数被调成 0，那请求表里所有排队的请求都会永远停在「待运行」状态，看起来像数据问题，实际是调度层问题。这个对象模型必须在一开始就建立起来，否则排错方向会偏得很远。

2.4 权限链路的完整走向：从登录到跑通一个请求的六步

把前面三个对象串起来，一次完整的 EBS 操作是这样的：用户输入账号口令登录，系统验证 FND_USER 里的凭证；登录成功后，系统读取该用户的有效职责列表，让用户选择一个职责进入；进入职责后，系统加载该职责绑定的菜单，业务人员才能在界面上看到功能入口；当业务人员提交一个并发请求，系统校验该职责的请求组里是否包含这个并发程序；通过校验后，请求写入请求表进入排队；最后并发管理器取出请求并执行，输出结果文件供用户查看。

这六步里任何一步断了，表象都可能是「操作不了」，但断点完全不同。我在排查时习惯先把问题定位到这六步的哪一步：登录失败看用户状态和口令，菜单空看看职责和菜单绑定，提交不了请求看请求组，排队不跑看并发管理器。培训手册把这些拆成一个个功能界面讲，但真正干活时，脑子里得有这条完整链路，才能避免拿着菜单路径到处点。

3. 照着手册做权限配置：最小可运行步骤与三个必查参数

3.1 创建用户：菜单路径、必填项与容易被忽略的口令规则

创建用户是每个系统管理员上岗后做的第一件事。以系统管理员职责登录后，导航路径是「系统管理员 (System Administrator) → 安全 (Security) → 用户 (User) → 定义 (Define)」。打开表单后，必填项只有几个：用户名、口令、确认口令、有效日期范围。口令界面输入的是明文，系统存储时会自动做加密哈希，不需要管理员自己处理。有效日期默认是从今天开始、无结束日期，这个建议显式设置，避免日后账号「忘记关」。

这里有一个必查参数：口令生命周期和复杂度规则。EBS 本身提供了一些口令策略配置，比如是否允许重复使用历史口令、口令最长有效期、错误登录尝试次数锁定等，这些都分散在不同配置项里。新环境刚上线时口令策略通常是最宽松的，但等公司合规要求下来，审计会让你把这些策略收紧。我一般建议创建用户前先查一遍「签名口令生命周期」「口令不重复使用次数」这几个配置项的当前值，确认之后再批量建号，否则建完的用户可能第二天就弹出口令过期。

3.2 分配职责：赋权后还必须检查的三处联动设置

用户建好了，接下来是分配职责。导航路径是「安全 → 用户 → 定义」，查询刚创建的用户，在「职责」区域添加一条记录。这里要注意：你添加的职责必须处于有效期内，职责的开始日期不能晚于当天，结束日期不能早于当天，否则这条分配记录不会生效。分配完职责，很多新手以为结束了，但实际还差三处联动：

第一处和第二处是在创建职责时就该设好的，但如果你接手的是别人配了一半的环境，分配用户前务必回头检查这两项。第三处是时间维度的问题，现实中经常出现用户有效期到 12 月 31 日，职责有效期到 12 月 20 日，结果最后十天用户登录正常但进不了职责，查半天数据才发现是日期范围没对齐。

3.3 配置文件赋值：四个层级的覆盖顺序与验证方法

配置文件的赋值界面不在用户管理里，而是在「系统管理员 → 系统 (System) → 配置文件 (Profile)」下。打开后可以按名称查询，然后分别维护站点级、应用级、职责级、用户级四个层级的值。实操中最常用的是职责级和用户级：业务部门要求某个报表默认输出 PDF，就找到对应配置文件，在「职责级」里给这个职责赋值 PDF；某个人特殊要求 Excel，就在「用户级」单独给他覆盖。

覆盖顺序必须背下来：用户级 > 职责级 > 应用级 > 站点级。这意味着，如果你想给某个职责设置 PDF 输出，但某个用户已经在用户级配了 Excel，那这个用户在这个职责下仍是 Excel。排查「为什么我改了不生效」时，第一反应应该去查用户级是否有值，而不是怀疑系统没刷新。验证生效值的标准方法是：在配置文件查询界面，输入配置文件名后，界面会显示每个层级当前的值，对比一下就能看出谁覆盖了谁。

3.4 用请求日志倒查权限：一条 SQL 看穿配置是否生效

界面操作能覆盖 80% 的权限配置场景，但遇到批量验证或者排错时，直接查表效率更高。EBS 的并发请求都记录在fnd_concurrent_requests表里，我常用下面这条 SQL 来确认一个用户、一个职责下的请求是否真的提交过、跑到哪一步：

SELECT request_id, user_name, responsibility_name, concurrent_program_name, phase_code, status_code, request_date, actual_start_date, actual_completion_date FROM apps.fnd_concurrent_requests WHERE user_name = 'DEMO_USER' ORDER BY request_date DESC;

这条 SQL 的逻辑是把一个用户最近提交的请求全部拉出来，按时间倒序排列。phase_code是请求阶段：P表示待运行（Pending）、R表示运行中（Running）、C表示已完成（Complete）；status_code是具体状态，比如N表示正常结束、E表示错误结束、T表示终止。实际看数据时，phase_code为C且status_code为N才算真正跑成功。

参数说明：user_name是登录用户名，不区分大小写但建议用大写；request_date如果查询范围太大，可以加AND request_date > SYSDATE - 30只查最近一个月。如果查出来的结果里responsibility_name是空的，说明这个请求提交时职责信息没写全，往往是请求组配置有问题——这比在界面上一个个点开看快得多。

4. 日常运维要落地的四件事：巡检、补丁、备份与并发调优

4.1 每天五分钟巡检：五份日志与三张表的检查清单

EBS 系统管理员的日常，不是等业务报障才动，而是每天固定时间做一轮巡检。我一般把它压缩在五分钟左右，核心是「五份日志 + 三张表」。五份日志：应用层日志（$INST_TOP/logs/appl下按应用模块分目录）、并发管理器日志（$APPLCSF/log下按请求 ID 命名）、WebLogic 应用服务器日志、数据库告警日志（alert_log）、请求输出文件（$APPLCSF/out）。前面四份看有没有新增的严重错误，请求输出文件只在有报障时定向排查。

三张表是指三个核心查询：并发请求表（看有没有长时间卡在P或R状态的请求）、并发队列表（看各管理器进程是否正常）、节点表（看应用节点是否都被 EBS 识别）。巡检时我最常用下面这条 SQL，专门抓超过一个晚上还没跑完的请求：

SELECT request_id, user_name, concurrent_program_name, phase_code, status_code, request_date, actual_start_date FROM apps.fnd_concurrent_requests WHERE phase_code IN ('P', 'R') AND request_date < SYSDATE - 8 ORDER BY request_date;

这条 SQL 的业务逻辑是：正常请求一般在几小时内结束，如果某个请求提交超过 8 小时还停在排队或运行中，大概率出问题了。phase_code为P的长时间滞留，基本可以判定为并发管理器调度异常或请求组配置缺失；phase_code为R的长时间滞留，则需要进一步去并发管理器日志里看它是不是卡在某个 SQL 或输出文件写入上。参数SYSDATE - 8可以根据你们环境的峰值时长调整，我是按大部分批处理请求跑不过 4 小时来定的。

4.2 打补丁（adpatch）前必须完成的六步准备

EBS 打补丁用的是 Oracle 自带的adpatch工具，但真正决定成败的不是命令本身，而是补丁前的准备。我经历过太多次补丁打到一半失败、然后花两倍时间收拾现场的情况，所以现在严格执行六步准备。第一步：通读补丁的 README，确认补丁适用于当前版本、是否有前置补丁依赖。第二步：确认磁盘空间，补丁解压后的临时文件通常比补丁本身大 2 到 3 倍，临时目录和APPL_TOP所在文件系统都要留够余量。第三步：停掉并发管理器，在补丁期间并发管理器必须处于停止状态，否则会边改代码边跑业务，导致对象不一致。第四步：做一次数据库备份，至少保证归档日志连续；没有 DBA 权限的环境，这一步要提前约好 DBA 一起做。第五步：确认应用层所有节点已经同步，多节点环境下补丁只在一个节点执行，完成后还要在其他节点做同步操作。第六步：规划维护窗口，补丁时间短则十几分钟，长则数小时，要提前通知业务。

adpatch执行时有一个容易忽略的选项：补丁会话默认会要求输入APPL_TOP路径和系统密码，如果脚本中途断了，重新执行时要明确是继续还是重来。我的习惯是第一次跑之前先看一遍adpatch的提示和默认值，确认日志输出路径足够清晰，再开始正式执行。补丁日志默认写在$INST_TOP/logs下，文件名通常带adpatch字样，出问题时先看日志文件尾部几百行，失败原因一般就在最后几屏里。

4.3 备份不是 DBA 的活：表空间、应用层与并发状态的联动备份

很多 EBS 系统管理员把备份理解成「DBA 管数据库备份就够了」，这是运维事故的常见根源。EBS 由数据库层和应用层组成，两层必须联动备份才算一份完整可恢复的快照。数据库层的备份由 DBA 负责，通常是表空间备份加归档日志；应用层的备份则必须由系统管理员来做，涉及APPL_TOP（应用代码、配置文件）、INST_TOP（实例配置）、以及并发管理器相关的日志和输出目录。

应用层备份的最佳时机是并发管理器停止期间。因为并发管理器运行时会产生请求输出文件、日志文件，这些文件与应用代码文件混在一起，如果不停管理器直接拷贝，备份出来的文件很可能是不一致的。我的顺序是：先停并发管理器 → 备份应用层目录（APPL_TOP、INST_TOP、日志目录按需） → 通知 DBA 做数据库备份 → 备份完成后再启动并发管理器。恢复时的顺序也同理：先恢复数据库，再恢复应用层目录，最后启动并发管理器，并且要确认两边的时间点一致，否则会出现应用代码是今天、数据库数据却是昨天的错位情况。

4.4 并发管理器参数怎么调：进程数、队列长度与内存上限

并发管理器的性能调优，是系统管理员手册里写得最少、但业务感知最强的一块。核心参数是各管理器的进程数：进程数越多，能并行跑的请求越多，但每个进程都要占内存和数据库连接，不是越大越好。我在环境里常用的做法是：先看请求峰值时段的同时并发量，再把这个数字除以单请求平均运行时间，得到一个粗略的并发需求，然后在这个基础上加 20% 到 30% 的余量。

最常见的反向操作是把进程数调得很大，比如 64 核机器上把标准管理器调到 40 个进程，结果请求没快多少，数据库的会话数和锁等待倒是上来了。调完参数要在次日巡检时看两个指标：请求平均排队时间是否下降、数据库活跃会话数是否在承受范围内。如果排队时间没变但数据库负载明显升高，说明瓶颈不在并发管理器，而在请求本身的 SQL 性能上，这时候调进程数属于治标不治本。

5. 系统管理员高频踩坑：五条翻车记录与排查路径

5.1 Windows 客户端报错 0xc0e90002：表单打不开先分清边界

现象：业务人员在 Windows 电脑上启动 EBS 表单客户端，弹出一个 Windows 系统错误，提示某个 DLL 文件没有被指定在 Windows 上运行，错误状态0xc0e90002，建议重新安装程序或联系系统管理员。这看起来像 EBS 的问题，但报错发生在客户端环境里，根源基本在 Windows 侧。原因：EBS 表单客户端依赖本地的 Java 运行时和 Forms 客户端组件，这些组件被安全软件清理、Windows 更新后文件损坏、或安装路径变化，都可能导致 DLL 加载失败，0xc0e90002这类状态码通常对应的就是 DLL 加载失败或文件版本不匹配。解决：先在 Windows 事件查看器里定位具体是哪个 DLL 加载失败，再决定是重装 Java 运行时、重装表单客户端组件，还是把 EBS 站点加入浏览器和杀毒软件的信任列表。这件事的关键不是马上重装 EBS 客户端，而是先确认边界——报错在客户端侧，就先从客户端的组件依赖查起，血泪经验是：直接重装客户端往往是无效的，必须定位到具体 DLL。

5.2 用户改了密码却登不上：配置文件层级覆盖的典型误伤

现象：某个用户修改口令后，再登录时报「用户名或口令无效」，其他用户都正常。原因：这个用户或该用户所属的职责上，存在一个与认证相关的配置文件设置，比如强行指定了外部认证方式或口令验证规则，而修改口令的操作可能没有同步更新到那个配置所对应的外部验证源，导致系统里有两套口令状态对不上。解决：先查这个用户关联的职责和用户级配置，看看有没有认证类配置项被设置过；把用户级的值清空，让它回落到职责级或站点级默认值，一般就能恢复。如果不行，再查该用户的fnd_user记录里的口令状态字段，确认是否为锁定或过期状态。这个坑的难点在于，问题表现和配置项名称完全不像——业务看到的是「密码不对」，实际上和密码本身没关系，方向错了能查一整天。

5.3 请求一直卡在「待运行」：先看并发管理器再查请求表

现象：业务提交了一批请求，状态长时间停在「待运行」或「已提交」，不往前走。原因：最常见的是并发管理器进程挂了，或者职责的请求组里根本没包含这个并发程序，请求提交时就直接进了无效队列；其次是请求的优先级很低，前面排了大量高优先级请求。解决：按先后顺序做三件事——先看并发管理器的状态，确认标准管理器进程是否在运行；再查这个请求所在的职责，确认它的请求组里是否包含了对应的并发程序；最后看请求表里的排队时间和同队列的其他请求，判断是不是真的被业务高峰堵住了。这三板斧能解决九成以上的卡请求问题。如果你已经确认并发管理器是正常的，再用前面 4.1 的那条 SQL 把长时间排队的请求拉出来，看看是不是集中在某个职责下，是的话就往请求组方向查。

5.4 补丁中途失败：adpatch 的恢复机制与日志定位

现象：打补丁执行到一半，脚本报错退出，补丁目录里留下半成品，系统里可能有部分对象已经更新、部分还没更新，处于中间状态。原因：最常见的是磁盘空间不足、前置补丁没打、或补丁执行期间并发管理器没有被完全停掉，导致脚本在更新某个表或编译某个视图时被锁或被中断。解决：先看补丁日志文件尾部，定位第一个报错的位置，判断是环境问题还是补丁本身问题；如果是空间或资源问题，清理后重新执行adpatch，脚本一般会识别上次的断点，从失败处继续。千万不能直接删掉补丁目录重新跑一遍，那样会把已经完成的对象变更再执行一次，可能产生重复或冲突。补丁失败后的第一原则是「保留现场、查日志、恢复环境」，而不是急着重试。

5.5 职责有了但菜单不显示：请求组与菜单挂载的问题

现象：用户已经分配了职责，登录后也能选到该职责，但进入后菜单空白，或者只能看到部分功能。原因：职责定义里的菜单项没有被正确挂载，或者挂载了菜单但菜单下的功能没有注册到对应的请求组，导致界面加载时找不到可显示的功能。解决：在「安全 → 职责 → 定义」里打开这个职责，检查「菜单」字段是否指向正确的菜单；再进入菜单维护界面，确认该菜单下挂载的功能是否处于有效状态；最后检查请求组，确认该职责需要提交的并发程序都已经包含在请求组里。还有一个容易被忽略的点：职责的有效日期范围，如果职责的开始日期被误改成未来日期，用户登录时职责可见但所有功能都不会加载，表现和菜单空白一样，但原因完全不同。遇到菜单异常，先看职责有效期，再看菜单挂载，再看请求组，按这个顺序查最快。

6. 把培训手册改造成自己的运维笔记：用一张变更表管住日常操作

培训手册最大的问题是静态的，而 EBS 环境是动态的。手册里写的界面路径可能因为补丁升级而变化，手册里讲的标准流程也可能因为你们环境的定制而被打破。我拿到任何一份 EBS 培训手册，做的第一件事不是通读，而是把它拆成章节，在每一章后面附一张自己的变更记录表。表格不用复杂，几列就够：日期、变更对象、变更前状态、变更后状态、影响范围、验证方式。每次做配置变更或排完一个坑，就填一行。

例如，你今天调整了某个职责的请求组，就记录「变更对象：应付会计职责请求组；变更前：缺少 XX 报表程序；变更后：已添加；影响范围：该职责下所有用户可提交该报表；验证方式：用测试账号提交一次请求并确认输出文件正常」。三个月后，这张表和手册原文加在一起，才是你真正的工作手册——手册给你标准路径，这张表给你环境里的实际状态和边界。我自己的习惯是每个月末翻一遍这张表，把那些已经失效的配置项理出来，顺手清掉历史遗留的无效职责和用户，这样系统管理员的工作才不会越积越重。把静态文档变成动态台账，这个习惯比记住任何一条命令都有用。希望帮到你。

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