简介：Oracle EBS系统管理员培训手册.doc是一份面向Oracle EBS系统管理员的应用产品培训教材，围绕系统管理核心模块展开，涵盖安全管理、并发程序及请求管理、预置文档、弹性域与值集设置、单据序列、安全性控制及打印机配置等关键操作。资源以Oracle Application 11i中文版为示例，不仅讲解如何定义责任、管理用户与顾客、监控登录活动，还覆盖功能/菜单/报表的安全设置，以及并发请求的提交、查看、生命周期监控和状态修改；预置文档、弹性域、值集、单据序列与安全性控制等章节则帮助企业落实规范化管理。压缩包仅含1个doc文档，共1.44MB，无需其他配套文件即可直接查看。内容按模块循序渐进地编排，每个部分都配有操作练习和实用示例，便于管理员边学边练，从安全、数据到并发处理逐渐建立起完整的EBS运维思路。目前已有58人学习/下载，能帮助读者在实际工作中更快定位和解决系统设置及运维问题。
1. 为什么 Oracle EBS 管理员先啃系统管理员模块：用户、责任与并发是地基
做过 Oracle EBS 运维的人都知道，EBS 系统管理员不是“装个客户端、建几个用户”那么简单。尤其是 Oracle Application 11i 中文版这套环境，业务部门报“登录不了”“报表跑不动”“数据不对”时，最终排查方向几乎都会落到系统管理员模块——用户责任分配、并发管理器状态、弹性域值集配置，任何一环有问题，前端业务就跟着翻车。这份培训手册我从头到尾拆过一遍，它好就好在不是罗列菜单，而是把系统管理员们日常要干的活按“安全管理 → 并发请求 → 预置文件 → 弹性域 → 单据序列 → 安全性 → 打印机”串成了一条可落地的操作链。新手靠它能入门，老手靠它能复查自己有没有漏掉关键设置。本文就用这份手册的目录和实际运维场景，把每个模块怎么用、参数怎么设、坑在哪讲透。
2. 用户与责任体系：Oracle EBS 安全管理的核心不是用户，而是授权层
2.1 责任是什么：为什么一个用户不能直接拥有权限
Oracle EBS 的安全模型是“用户 + 责任”。很多人第一次接触时容易把责任理解成角色，但两者有本质区别。责任是 EBS 里的授权层，它决定了你能进哪个应用、操作哪些窗口、跑哪些报表、访问哪套数据。一个用户可以挂多个责任，但每个责任独立控制一套菜单、功能、报表和数据库帐户映射。
手册里明确讲了责任的四个构成部分：数据组（必选）、请求安全保护组（可选）、菜单（必选）、功能和菜单排除（可选）。实际配置时，数据组通常直接用系统缺省“标准”，但如果你有多个数据库用户，比如财务和库存分别使用不同的 Oracle 帐户，就必须在这个环节指定清楚。菜单决定了“定位”窗口里能看到哪些表单，功能排除则是在菜单基础上再做减法——同一个窗口，A 责任能看到“过账”按钮，B 责任看不到，就是靠功能和菜单排除实现的。
提示：定义责任前，最好先把功能、菜单、请求组都定义好，否则责任界面里根本没得选。
2.2 定义用户与分配责任：口令策略、有效日期与注销
定义用户的操作路径是“安全性 → 用户 → 定义”。这里最容易忽略的不是用户名、口令这种基本字段，而是“口令过期”和“有效日期”两个地方。
口令过期选项有三种：天、访问、无。
- 天：设置口令有效天数，比如 30 天强制改密，适合安全要求高的企业。
- 访问：限制该用户同时登录系统的人数，比如业务高峰期防止同一账号多人共享登录。
- 无：口令不过期，适合内部测试环境。
有效日期是管理用户生命周期的关键。员工离职、转岗时，不要直接删用户，正确做法是把有效日期截止到某一天，或者把该用户的某个责任有效截止日期填上。这样用户还能保留，但无法登录，历史数据也不会因为删用户而失去关联。
分配责任的步骤是：定义新用户或查询出已有用户 → 逐行录入责任、应用、有效日期 → 保存。注销某个责任时，只改该行责任的有效截止日期即可，不需要动用户本身。
2.3 监控登录用户：排查“谁在跑什么”的实用手段
运维中经常遇到这种情况：业务部门反馈某个模块很慢，但又说不出是谁在跑什么报表。这时“监控用户”窗口就是第一排查工具。路径是“安全性 → 用户 → 监控”，能看到当前登录用户的登录名、登录责任、当前使用的 Form、环境和登录时间。
我一般会按用户或责任过滤查一遍，比如某财务同事说总账对账卡住，我直接查她当前用的责任和 Form，再结合后文的并发请求状态，基本能判断是死锁还是并发管理器资源不够。
注意：监控窗口只能看当前在线用户，历史登录记录需要查审计表，手册没展开，但效果类似。
2.4 功能安全与菜单定义：控制表单级按钮的隐藏逻辑
功能安全保护是 EBS 安全管理里最容易踩坑的一环。业务部门经常提“我们需要在这个窗口加个按钮/去掉一个按钮”，这往往不是改代码，而是通过功能安全来实现。
路径是“应用 → 功能”，定义时要注意功能类型有两类：表单功能（可以出现在定位窗口）和子功能（非表单功能，只能在表单内部触发）。比如一个“审批”按钮，如果定义成表单功能，可能会出现在菜单里；如果定义成子功能，就只能挂在某个表单内。实际配置时，开发员在开发阶段就要注册功能，系统管理员再把功能挂到菜单构造里。
菜单定义的路径是“应用 → 菜单”。每个菜单由若干功能或子菜单构成，需要为每个菜单项指定提示名、对应功能或子菜单。这里有个细节：菜单名的“顾客菜单名”和“提示”字段，前者是菜单值列表里显示的别名，后者是实际菜单项上的文字，两个别搞混了。
3. 并发程序与请求管理：报表跑不动、请求卡住时的救火手册
3.1 并发处理的三个概念：请求、并发程序、并发管理器
EBS 并发处理是后台跑报表、跑定时任务的基础。手册里明确了三个概念的区别：用户提交报表时生成的是“请求”；实际执行报表逻辑的是“并发程序”；由“并发管理器”负责调度和启动这些程序。
举一个实际场景：用户跑资产负债表日报，点击提交后，系统生成一个请求。这个请求进入并发管理器队列。并发管理器根据操作系统启动的进程数量，按优先级和队列顺序把请求调度给具体的并发程序执行。如果并发管理器停了，前端所有报表提交都会挂在“待处理”状态。
3.2 提交与查看请求：日志文件是第一个排查入口
提交请求的按钮在每个报表界面里的“提交”或“运行”按钮，查看请求则用菜单“查看 → 请求”。所有请求都有唯一编号，运维时要让用户把请求编号给你，不要只看“报表没出来”。
请求运行完会产生两种文件：输出文件（报表实际结果）和日志文件（程序执行过程记录）。排查步骤我一般这样走：
- 查看请求状态是不是“已完成”“正常”；
- 打开日志文件，看有没有报错，比如 “no data found” 或 “ora-xxxxx”；
- 如果日志文件没有明确错误，再看输出文件是不是生成了空报表。
常见的一个坑是请求状态显示“错误”，但日志文件里没有详细 SQL 错误信息。这时要去并发程序的“参数”定义里看是不是设置了无效参数，或者去管理员责任下查看并发管理器日志。
注意：请求生命周期里有“待处理→运行→已完成/错误”多个阶段，不要看到“运行”就以为还在正常跑，有时卡在“运行”超过半小时，基本是并发管理器资源问题。
3.3 请求集与请求组：批量运维的秩序管理
请求集是把多个请求串成一个批次，比如月末结账时把“日记账过账”“试算平衡表”“利润表”三个请求按顺序跑。定义请求集时要注意后一个请求能否引用前一个请求的输出参数，手册里的做法是“定义请求集 → 添加请求 → 指定请求顺序和参数”。
请求组则是责任里配置的“标准请求、报表”集合。一个责任下的用户，提交新请求时能看到的请求类型范围，就是由请求组控制的。比如只让财务用户看到总账相关的报表，不让他们看到库存报表，就在责任定义里指定对应的请求组。
实际配置时，我对请求组的建议是：按业务模块建组，比如“总账报表组”“应收报表组”，再把对应报表挂进去。这样新增报表时工作量小，也不会误开放权限。
3.4 并发管理器的工作班次与资源控制：高峰期不翻车的设置
并发管理器最让人头疼的是资源分配。手册提到用“工作班次”平衡处理工作负荷，这个功能在并发管理器定义里设置。比如上午九点到十一点是报表提交高峰，可以设置更短的并发进程数量上限，避免把所有操作系统进程都占满；夜间批处理时段则可以放开到最大进程数。
控制并发管理器的操作包括启动、暂停、终止某个管理器。实际操作里，我一般会先查“系统管理员 → 并发 → 管理器”的状态，如果是“等待”状态但队列里有大量等待请求，就考虑增加管理器进程数或调整工作班次。
提示：修改并发管理器参数后，要重启管理器才能生效，重启时老请求会中断，最好安排在下班后操作。
4. 用户预置文件与弹性域、值集：个性化设置和关键字段扩展的实操口径
4.1 预置文件的分层结构：为什么同样代码在不同环境显示不同
用户预置文件是 EBS 里控制用户界面行为、默认值、系统参数的核心机制。手册把预置文件分成系统层、用户层、个人层。分层的意思是：系统预置文件对所有用户生效，用户层预置文件对指定用户生效，个人层预置文件只对该用户本次会话生效。优先级从高到低是个人 > 用户 > 系统。
实际工作中最常见的坑是：两个用户看到的同一窗口字段宽度、默认日期格式不一样，就是因为预置文件在用户层做了个性化覆盖。这时候要去“用户预置文件”窗口查看该用户的预置文件值，不要怀疑代码有问题。
4.2 关键性弹性域与描述性弹性域：字段扩展的本质区别
弹性域是 EBS 里给标准字段扩展自定义属性的一种机制。手册里分了两类：关键性弹性域（KFF）和描述性弹性域（DFF）。
关键性弹性域是系统用来唯一标识业务实体的字段组合，比如总账科目弹性域由“公司段+成本中心段+科目段”组成。它的段值必须提供在值集里，并且通常参与唯一性校验。定义关键性弹性域时，要指定“结构”，比如不同帐套可以有不同的段结构。
描述性弹性域则是附加在表单上的自定义信息字段，比如在客户上增加“客户等级”“行业分类”两个全球字段。描述性弹性域不参与唯一性检查，只是存储附加信息。实际场景中，客户要求加字段时，先问清楚是参与报表查询的唯一标识，还是仅仅备注性质。前者用 KFF，后者用 DFF。
4.3 定义值集：从手工输入到验证规则的完整配置
值集是弹性域的基础，它定义了段的可选值范围及验证方式。手册里重点介绍了值集定义界面，字段包括值集名称、格式类型（字符/数字/日期）、最大长度、验证类型。
验证类型有“无验证”“列表验证”“独立验证”“非独立验证”等。最常见的做法是主段用“独立验证”，子段用“非独立验证”——子段可选值依赖主段的选择。比如科目段选“1000”后，成本中心段只显示“A01、A02”，这就是非独立验证。
定义值集时有个容易翻车的点是“安全性”。关键性弹性域的段值集如果启用了安全性规则，用户提交业务数据时可能看不到某些段值，但管理员用同一责任又能看到。遇到这种问题，先检查值集的“安全性类型”是不是“层级”，以及是否绑定了安全性规则。
注意：弹性域结构变更之前，一定要先备份值集和段定义。改完结构后，已有业务数据的关键性弹性域段组合可能无法重新通过验证，导致保存失败。
5. 单据序列号管理与安全性控制：从单据编号连续性到数据行级权限
5.1 单据序列管理的三种类别：连续性、可重用与空号
单据序列管理是 EBS 中控制单据编号的理论基础。比如应付发票、销售订单、总账凭证都需要连续编号，审计要求不能有断号。手册里把单据类别定义、单据序列分派作为重点。
单据序列可分为三种类别：
- 连续序列：必须按顺序使用，不允许跳号，适合财务凭证。
- 可重用序列：当原单据被删除时，编号可以被再次使用，适合内部单据。
- 空号序列：允许跳号，适合非关键业务。
实际运维中，出现“发票号断了一个”时，不要直接调整序列，而是看单据是否被删除或者序列状态是否设置为“废除后重新使用”。正确做法是定义新的序列，而不是修改已有序列的当前值，否则容易造成主键冲突。
单据序列分派操作要把序列号设计到具体帐套、单据类型和生效日期。分派时通常会保留一段缓冲编号，比如当前序列是 10000，下一次从 10050 开始，防止并发同时取号时冲突。
5.2 安全性规则：让同一把钥匙开不同的锁
安全性规则控制的是“行级数据”，而不是“表单级功能”。管理系统管理员模块时，我们常看到两个用户都能使用同一窗口，但查询出的数据范围不同，这就是安全性规则的作用。
安全性规则定义路径是“安全性 → 规则 → 定义”，规则要指定名称、应用和规则类型。规则类型有“表”和“视图”两种，一般建议基于视图定义，避免直接针对数据库表做行过滤。指定规则时要给“用户/责任/应用”指定规则，比如“销售部门用户只能看到自己的订单”。
操作步骤：
- 定义安全性规则，选择基础表和启用状态。
- 指定规则目标，包括应用程序、用户或责任范围。
- 设置排除条件，如“WHERE created_by = :user”；
- 将规则指定给责任或用户。
提示：规则里用到了绑定变量，比如 :USER，运行时自动替换成当前登录用户。调试规则时，先用系统管理员责任测试，再切换到目标用户责任验证，不要拿管理员责任当测试结果。
6. 避坑手册：EBS 系统管理员日常高频踩坑记录
做系统管理员模块的运维，一些坑是避免不了的常见问题，能快速定位基本就能挽回半天到一天的工时，值得单独再强调一遍。
6.1 新建用户登录失败，提示职责无效
现象：用户建好后，输入账号密码登录，提示“无有效责任”。 原因：用户责任表中没有录入授权责任，或责任的有效日期未覆盖当前日期。 解决：在定义用户界面，进入用户责任块，录入责任及开始日期（例如“01-01-2024”），确认日期覆盖到当前。
6.2 并发请求状态一直卡在“待处理”或“运行”
现象：提交的报表请求状态 30 分钟没变化，日志文件也没有内容。 原因：并发管理器没有启动；或者内部管理器运行数量已达上限；或者请求被意外的外部进程阻塞。 解决：在系统管理员职责下查“并发管理器”，确认管理器状态为“运行”，若管理器数为 0 就启动它；若管理器正常，查看“管理员审阅中的请求”并重新安排调度计划。
6.3 责任定义后，用户看不到预期菜单，或缺少按钮
现象：A 用户比 B 用户少了某些菜单项，但确认都分派了相同责任。 原因：责任定义的“功能和菜单排除”中配置了排除项；或者功能安全保护中该菜单项对应的功能未注册到该责任的菜单结构里。 解决：检查“功能排除”与“菜单排除”清单；登录责任时按住“帮助 → 关于 Oracle 应用”查看当前责任的功能列表，反向验证菜单构造。
6.4 弹性域值集修改后，旧数据保存报错或无法验证
现象：修改值集后，再打开历史单据修改保存，提示“值无效”。 原因：历史数据中的段值在原值集里存在，但新值集改成了独立验证并删除了旧值。 解决：保留旧值集并设置为失效日期，而非直接删除；或新增一个值集并同时开启旧值集的验证，保证历史数据不失效。
6.5 预置文件设置了值，但用户看到的还是系统默认
现象：在用户预置文件窗口中对该用户设置了字段默认值，用户登录后没生效。 原因：设置到了“系统层”，或者该用户存在“个人配置文件值”覆盖，预置文件值可能被更高优先级覆盖。 解决：在“个人预置文件值”里再加一遍；检查三层优先级，个人层 > 用户层 > 系统层，并确认设置的目标用户字段正确填写。
6.6 打印机设置后，报表输出的格式不对或没有输出
现象：用户选择打印机批量打印报表时，输出文件格式不对；或者打印任务提交成功，但打印机不动作。 原因：打印机类型设置错误，比如注册打印机时选择了“PCL”类型，但实际打印机是 PostScript；或者打印机名称与应用程序中的打印机名称不匹配。 解决：确认打印机类型、打印机驱动程序与物理打印机的型号匹配；核对打印机名称区分大小写，建议先在“打印机注册”页测试小打印任务。
7. 验证与进阶：用五个自检动作确认系统管理员配置是否到位
7.1 快速验证安全管理模块的五个命令级操作
你配置完用户、责任、并发、弹性域后，建议按下面五个动作自行验证，保证配置有效。
第一，创建测试用户，并分配一个只读责任，登录后确认“定位”窗口中的菜单与责任定义一致。第二，提交一个简单请求，例如总账报表，记录请求编号，观察状态从“待处理”到“正常”，用时不超过一分钟。第三，修改一个用户的口令过期选项为“访问”，并同时启用两个会话，确认第二个会话被拒绝登录。第四，定义一个新的描述性弹性域字段，并保存一条新单据，确认字段内容被存储到数据库。第五，用 SQL 查询请求表，确认刚才提交的请求与请求集的关联正确。
7.2 进阶技巧：从日志文件定位并发请求失败的真正原因
并发请求失败时，第一动作是打开请求的日志文件，但我通常不看最后几行，而是先看日志文件头的并发管理器信息，以及程序执行的起始时间。
-- 查询请求日志的关键信息，确认运行时参数和错误代码 SELECT request_id, phase_code, status_code, logfile_name, outfile_name, argument3, argument4 FROM fnd_concurrent_requests WHERE request_id = 123456;逻辑说明：查询并发请求表，分析请求的阶段、状态和参数。logfile_name 是日志文件路径；outfile_name 是报表输出文件路径。argument3 和 argument4 是提交请求时传入的后两个参数，常用于排查自定义并发程序接到的参数是否正确。
参数说明：phase_code 用 P（待处理）、R（运行）、C（已完成）、E（错误）；status_code 用 N（正常）、W（警告）、E（错误）等。实际排查时，若 status_code 为 E，结合日志文件最后一行错误码和请求表中的参数组合，能快速判断是数据问题还是并发程序逻辑问题。
7.3 从系统管理员转 DBA 的桥：用并发请求反向验证基础数据
并发请求不只是在报表模块里出现，它还用来跑一些核心数据补录和维修任务。比如审计要求“调整账套期间”，可以用“账套关闭/打开”程序作为一次真实请求运行。如果该请求成功，则账套期间的基础验证、权限控制、期间状态都算正确。
我自己的习惯是，每次配置完一批新权限或新责任，都会强制走一遍上述五验证，再开一个测试用户在测试环境下完整提交一次请求，并用 SQL 抽查请求生命周期。连续三周不出问题，这套配置才算真正落地。以后每次上线新报表，我都会先确认并发组和请求组是否覆盖它，而不是等业务用户跑来反馈报错再去排查。希望这套手册拆解过程能帮到你，少走几个我踩过的弯路。
本文还有配套的精品资源，点击获取
