简介：面向Oracle EBS系统管理员的培训手册，详细讲解了安全管理、并发程序与请求管理、预置文件管理、弹性域及值集设置、单据序列管理、安全性控制和打印机设置等核心模块，系统梳理了系统配置、日常运维和问题处理的关键操作。资源为单个DOC文档，大小1.44MB，目前已有58人学习下载，适合作为企业内部培训或自学参考资料。针对Oracle Application 11i中文版，手册从实际使用角度出发，重点阐述了责任与用户定义、功能安全保护、登录用户监控、并发请求生命周期管理、请求集与请求组定义等内容，并配有课堂练习和详细操作步骤。读者可按章节对照实施，快速掌握EBS后台配置、权限控制、并发管理及安全防护技能，为管理Oracle EBS系统提供全面指导，有效提升企业应用系统的运行效率与安全性。

1. 从一份《OracleEBS系统管理员培训手册.doc》说起：系统管理员到底管什么

刚接手第一套 OracleEBS 的时候，我手里总共三样东西：一份安装记录、一套生产库密码、以及这份《OracleEBS系统管理员培训手册.doc》。当时以为系统管理员就是建建用户、改改密码、偶尔导条数据，真正翻完手册才发现判断完全偏了。这份手册的核心不是教你点页面，而是把一套系统的日常运转拆成几个稳定环节：应用层文件结构、数据库连接、并发管理器调度、用户职责与请求集。它解决的是“系统出问题时按什么顺序查”的问题，也顺带讲清楚了日常巡检该看哪些状态位。适合 OracleEBS 的实施顾问、甲方运维和刚转岗的 DBA 作为第一个月的学习主线。下面几章，我按手册的讲述顺序把它拆成能直接落地操作的内容。

2. 先把架构立住：OracleEBS 系统管理员培训手册的技术主线

OracleEBS 这套东西有个特点：界面看着是网页，背后却站着三层进程和无数个配置文件。系统管理员如果只会在页面上点来点去，遇到问题会非常被动。培训手册开篇通常不急着讲操作，而是先把“应用层 / 数据库层 / 客户端”这三层关系理清楚，后面每个维护动作才有着落。

2.1 从三层架构看系统管理员的工作边界，为什么培训手册要花大量篇幅讲架构

OracleEBS 传统上分成三层：客户端（Form 或 Web 界面）、应用层（并发管理器、Web 服务、报表引擎）、数据库层（Oracle 数据库实例）。系统管理员真正的工作边界，横跨应用层和数据库层之间那一块灰色地带：既要维护应用服务器上的文件和环境变量，又要保证数据库里APPS这个 schema 能正常连接，还要让并发管理器把用户提交的报表请求顺利跑完。

画一条更具体的主线：用户登录后，请求从 Web 层进入应用层，应用层把数据操作会话交给数据库；数据库返回结果，应用层再把输出整理成报表或页面。这个链路里，系统管理员负责的不是业务逻辑，而是链路本身。培训手册爱用“实例拓扑图”把端口、域名、节点关系画出来，目的就在这儿：哪个进程挂了看哪层。业务上显示连接超时，问题未必在数据库，很可能只是应用层某个监听进程没起来。

另一件必须理解的事情是环境文件。每套 OracleEBS 应用层在安装时会生成一个实例目录，目录里放着上下文配置文件和环境变量脚本，通常叫APPS_<环境名>_<主机名>.env。所有日常运维动作，比如跑 adadmin、跑 autoconfig、重启应用层，都要先加载这个环境文件。它定义了大量环境变量，包括APPL_TOP、INST_TOP、AD_TOP、FND_TOP这些关键路径。培训手册里反复强调“先 source 环境文件再执行命令”，是因为环境变量错了命令根本找不到对象，会报出各种无关的错误，新人很容易在这里浪费半天。

数据库层由 DBA 负责，但系统管理员不能完全撒手。至少要知道APPS账号是 OracleEBS 应用层连接数据库的统一入口，绝大多数并发请求和表单操作都通过它执行。掌握了这三层关系，后面看并发管理器状态、查请求表、做备份恢复，才不会被一大堆进程名绕晕。

2.2 职责、数据组、请求集：培训手册里最容易被跳过的一段

在 OracleEBS 里，“管理用户”和普通应用软件里建账号完全是两码事。用户只是一个人名，真正决定他能看到什么、能跑什么报表的，是一整套映射关系：用户挂职责，职责挂菜单，菜单由安全列表控制；同时职责还能决定他能提交哪些请求，数据组决定他能访问哪些业务表。培训手册把这块内容放在中间偏后的位置，实际上它才是权限管理的核心。

职责（Responsibility）是 OracleEBS 里最基础的安全单位。一个人可以同时挂多个职责，不同职责登录后看到完全不同的导航菜单。比如某个用户同时挂了“应付管理”和“系统管理员”两个职责，他就能在两种身份之间切换。系统管理员日常最频繁的操作，就是给新员工挂职责、调整已有职责的菜单、停用离职员工的职责。

数据组（Data Group）是另一个容易理解错的概念。它控制的是职责在连接数据库时使用哪个 schema 去解析业务表。同一套职责，在不同数据组下可能查到不同库的数据，这在多组织、多实例环境里特别关键。请求集（Request Set）则把多个并发请求串成一个批次，用户提交一次就能按顺序跑一串报表。很多运维负责人把请求集当作自动化入门，其实它只是简化了操作，真正的调度仍然由并发管理器完成。

这三者的关系可以这样记：职责管“菜单和权限”，数据组管“连接和解析”，请求集管“报表和批处理”。系统管理员在配置用户时，如果只建了用户忘了挂职责，那这个人登录后等于什么都没有；如果职责挂好了但数据组不对，看到的就是一堆打不开的菜单或者没数据的报表。培训手册里常用一张权限关系图把这几个实体串起来，我自己的习惯是在维护记录里也画一张同样的映射表，改任何一头都回头更新一次，避免三个月后自己也查不清楚。

3. 按培训手册跑通日常运维：adadmin、并发管理器与请求集的最小操作集

架构看得差不多了，就该动手。日常运维的起点不在界面，而在命令行。那些图形界面能做的操作，底层都是调用了应用层目录下的脚本。系统管理员至少要熟练 adadmin 和并发管理器相关的状态检查，才能算入门。

3.1 用 adadmin 完成应用层日常维护：登录、菜单顺序与三个常用选项

adadmin 是 OracleEBS 应用层最老牌的一个维护工具，培训手册里一般会把它放在第一节课。它本身是个交互式菜单程序，不同版本菜单布局略有差异，但核心功能稳定。常见用法是先在应用服务器上用applmgr用户登录，再加载实例环境文件，最后调用 adadmin。

# 以应用层运维账号登录应用服务器 # 假设实例名 PROD，主机名 ebsapp01 # 环境文件实际路径在 $INST_TOP/admin/scripts/ 下 source $INST_TOP/admin/scripts/APPS_PROD_ebsapp01.env cd $INST_TOP/admin/scripts adadmin

这段命令里，source环境文件是必须的一步。如果不加载，adadmin 找不到APPL_TOP、FND_TOP这些路径，启动后第一屏就会报错或直接退出。加载完环境文件后进入交互菜单，我日常用得最多的有三个选项：

第一个是“生成应用文件”（Generate Application Files），它会把最新的表单、报表和消息文件重新生成一遍。业务顾问改了表单注册信息之后，系统管理员要跑一次这个功能，否则用户端拿到的还是旧版本。第二个是“并发管理器维护”（Manage Concurrent Managers），在这里可以查看管理器状态、调整同时运行的进程数，也能启动停掉某个管理器。第三个是“验证应用层安装”（Validate Installation），它会检查应用层目录里的关键文件和链接是否完整，适合在应用起不来的时候先跑一遍。

有些培训材料还会提到 adadmin 里可以做“升级 APPS 密码”“编译无效对象”，但这两件事在新手阶段不急着操作。升级密码有专门的FNDCPASS工具，编译对象更依赖 DBA 配合。我的建议是：前三个月只用上面三个选项，等环境熟悉了再扩展。

3.2 并发管理器状态检查与请求清理：先看 SQL，再去动进程

并发管理器是 OracleEBS 最脆弱的环节之一。用户提交报表之后，请求进入表里排队，由对应队列的 Manager 进程拾取执行。Manager 进程可能因为内存溢出、磁盘空间异常、配置项错误而退出，但请求还会留在表里，显示成一直“Pending”或者“Running”。出现这种情况，先查状态再重动进程。

-- 查看当前各并发管理器进程运行情况 SELECT q.concurrent_queue_name, p.process_status, p.os_process_id, p.running_processes, q.max_processes FROM apps.fnd_concurrent_processes p, apps.fnd_concurrent_queues_vl q WHERE p.concurrent_queue_id = q.concurrent_queue_id ORDER BY q.concurrent_queue_name;

这个 SQL 查的是应用层到数据库之间的进程状态。重要字段有两个：process_status表示这个管理器的进程在数据库侧是否正常，running_processes表示当前真正在跑的进程数。如果process_status是INACTIVE，管理器等于没启动；如果running_processes明显低于max_processes，说明管理器可能启动过但中途退掉了一部分。

确认管理器状态之后，再用第二个 SQL 查用户请求：

-- 检查最近一天是否有异常请求卡住 SELECT request_id, user_name, phase_code, status_code, logfile_name FROM apps.fnd_concurrent_requests WHERE request_date > SYSDATE - 1 AND status_code IN ('R', 'P') ORDER BY request_id DESC;

phase_code取值中，R表示运行中，P表示排队；status_code里的R是正常执行中，但配合phase_code一起看才能判断是否假死。经验做法是：如果一条请求在运行中停留超过两三个小时，多半是 Manager 进程死了，或者会话被数据库 kill 掉了。处理方式不是去数据库杀会话，而是先在并发管理器界面把对应队列停掉再启动，让 Manager 重新拾取请求。动作顺序一定记住：先查状态，再停管理器，最后清理请求，顺序反了会把正在执行的正常请求一起打断。

3.3 用户与职责维护：别只改 FND_USER，要同时刷新菜单安全组

用户管理的落地操作其实不复杂，复杂的是修改之后的同步问题。业务部门反馈新员工登录不了，我去FND_USER里查，账号状态正常、密码没过期，但就是进不去系统。这个问题的常见根源是：账号建好了，职责没挂上。

-- 查用户和职责的对应关系 SELECT fur.user_name, frt.responsibility_name, NVL(TO_CHAR(fur.effective_start_date, 'YYYY-MM-DD'), '无期限') AS start_date, NVL(TO_CHAR(fur.effective_end_date, 'YYYY-MM-DD'), '无期限') AS end_date FROM apps.fnd_user_responsibility fur, apps.fnd_responsibility_tl frt WHERE fur.responsibility_id = frt.responsibility_id AND fur.user_name = 'NEW_MEMBER' AND frt.language = 'US';

这条 SQL 可以快速验证用户挂了哪些职责以及有效期。很多运维同事习惯只查FND_USER.END_DATE，忽略了职责的有效期，结果账号本身没问题，职责却已经过期。如果职责确实没问题但用户还是看不到新菜单，另一个常见原因出在菜单安全刷新上。修改了职责的菜单结构之后，系统不会在所有用户会话里立即生效，需要重新登录，有时还要在“系统管理员”职责下提交一个“刷新菜单”的请求，等它跑完，新菜单才稳定出现。这个刷新请求相当于给权限缓存写一次重置，属于 OracleEBS 里经典的“改了没生效”解药，培训手册里通常会作为单独的提示写出来。

4. 从培训手册到备份与克隆：让环境有后悔药可以吃

OracleEBS 的备份不能只理解成“把数据库 dump 出来”。应用层那一大堆环境文件、链接库、表单定义，少了任何一部分，恢复出来的系统都是残缺的。培训手册里备份章节通常把目标写得很清楚：备份要能支撑“完整恢复到某个时间点”的要求，而不只是能导数据。

4.1 RMAN 加 autoconfig 的组合：一致性备份到底要备份哪些层

一套 OracleEBS 环境包含两层内容：数据库层和应用层。数据库层的标准做法是用 RMAN 备份，负责把数据、控制文件、归档日志一并保留；应用层的备份则集中在$APPL_TOP、$INST_TOP和数据库连接配置。很多初阶运维把应用层备份省掉，觉得“数据库在就万事大吉”，等真正恢复的时候才会发现环境文件里的主机名、端口、上下文信息全都对不上。

一个让我少走弯路的备份脚本模板长这样：

rman target / <<EOF BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG FORMAT '/backup/ebs/%d_%T_%U' TAG 'EBS_WEEKLY_BACKUP'; BACKUP CURRENT CONTROLFILE; BACKUP SPFILE; DELETE NOPROMPT OBSOLETE; EOF

这段 RMAN 命令的关键点是PLUS ARCHIVELOG和DELETE OBSOLETE。PLUS ARCHIVELOG会把备份期间产生的归档日志一起备份，保证恢复到任意时间点时日志链是完整的；DELETE OBSOLETE自动清掉超过保留策略的旧备份，免得备份目录被塞满。日常手动执行的场景里，我更常用INCREMENTAL LEVEL 1而不是全备，第一次全备之后，增量备份加归档足够覆盖大多数恢复场景。

数据库备份完成只是第一步。备份完数据库之后，应用层要做一件配套操作：运行 autoconfig，把最新的配置信息重新写入环境文件。因为数据库备份里包含了上下文信息，而应用层的文件可能和数据库里的记录不一致。不要小看这一步，备份时环境和恢复时环境但凡有一点差异，比如端口变了、主机名变了，应用层启动就会失败。

# 重新生成应用层配置文件 # 执行前先加载环境文件 source $INST_TOP/admin/scripts/APPS_PROD_ebsapp01.env cd $INST_TOP/admin/scripts ./adautocfg.sh

autoconfig 运行时会读取数据库里的FND_OAM_CONTEXT_FILES信息，再重新生成应用层的配置文件和应用环境变量。所以顺序必须是先备份数据库，再运行 autoconfig，最后同步备份应用层文件。反过来的话，autoconfig 生成的配置和数据库备份里的旧记录对不上，恢复后依然会出问题。

4.2 克隆 EBS 环境的最小路径：adcfgclone 的三个关键参数

克隆 OracleEBS 环境最常用的是adcfgclone.pl。它的工作逻辑是：复制一套已有的应用和环境到新主机，然后执行配置脚本把数据库层、应用层里的主机名、端口、SID 等参数改成新环境的值。虽然不同版本路径和参数略有差异，但主线一致。

# 在目标数据库服务器上执行数据库层克隆配置 # 进入目标环境的应用产品目录 cd $AD_TOP/bin perl adcfgclone.pl dbTier

执行后会交互式询问数据库 SID、数据库域名、监听端口等。随后在目标应用服务器上执行应用层克隆：

perl adcfgclone.pl appsTier

真正容易踩坑的是三个参数：目标数据库 SID、目标数据库端口、目标应用层上下文文件路径。这三个参数必须在执行前核对三遍。SID 写错，应用层连不上库；端口写错，连接字符串全错；上下文文件路径写错，脚本会去错误的位置找环境和配置。克隆前还需要在目标主机上把源环境的应用文件原样拷贝过去，文件的属主、权限不能变。

一个我反复强调的习惯：克隆前先把源环境的上下文文件导出一份，命名带上源环境和目标环境，比如PROD__TEST.xml。这样执行 adcfgclone 时可以直接对照，避免输入时把新旧信息混在一起。

提示：克隆完成后不要立即用于测试业务，先把并发管理器、Web 服务、数据库监听依次启动，然后用系统管理员账号登录跑一次最简单的报表请求，确认请求能正常从提交走到完成，再交给业务验收。

5. 避坑：OracleEBS 系统管理员最容易翻车的五个典型场景

接手 OracleEBS 一段时间后，你会发现出问题的规律比问题本身更有用。下面列出的五个场景是我在维护经历里遇到最多、也最常被培训学员反复追问的，每一个都按“现象、原因、解决”的方式拆开。这几条不是从手册里原文搬的，是根据实际排障经验沉淀出来的。

5.1 并发请求一直 Pending，Manager 进程根本没有收走

现象：用户提交报表后，请求一直停在 Pending，等了两小时还在排队，系统没有报错。用上一章的 SQL 查fnd_concurrent_requests，状态是P，但对应的管理器进程根本没把它捡走。

原因：并发管理器进程死了，但界面上看起来还在。通常是因为应用服务器内存不足，Manager 进程被操作系统杀掉，或者数据库侧某个会话出了异常。EBS 的并发管理器不会自动拉起退出进程，需要系统管理员手动干预。

解决：先用状态查询 SQL 确认process_status是否为INACTIVE，然后在系统管理员职责下进入并发管理器表单，把对应队列停用再启用。如果还不行，登录应用服务器，用ps -ef | grep FNDLIBR查看相关进程是否存在，确认没有僵尸进程后重新启动管理器。血泪经验是：不要在数据库里直接删fnd_concurrent_requests记录来“清库”，那样请求是没了，管理器内部状态还是乱的。

5.2 用户职责菜单改了，登录后看到的还是旧菜单

现象：系统管理员在职责表单里给某个人重新分配了菜单，刷新页面后用户登出再登录，看到的还是原来的菜单，新菜单选项没有出现。

原因：职责菜单变更没有触发安全刷新。OracleEBS 的菜单信息在数据库表里，但用户会话启动时会读取一次菜单定义，之后短期内不会再重新读取；如果系统里还开了 FND 表单缓存，旧菜单会被保留更久。

解决：让用户彻底退出浏览器再重新登录是最简单的办法。如果重新登录仍然无效，在“系统管理员”职责下提交“刷新菜单”请求，等请求跑完再让用户登录一次。还有一种情况容易被忽略：你改的是职责对应的“菜单”，但该职责下面挂的“请求组”没更新，用户能看到菜单项，但点进去没有可执行的报表。

5.3 清理应用层日志目录把环境给清挂了

现象：某次磁盘空间告警，运维同事把$APPL_TOP下的日志文件按日期删了一批，第二天应用层起不来，报错信息提示找不到某个配置文件。

原因：日志目录和应用配置目录在 OracleEBS 里距离非常近。清理时误删了$INST_TOP/admin/install/logs里还没完成写入的上下文文件，或者把和当前应用环境关联的.env文件一并清掉了。日志文件可以删，但环境文件、配置文件、链接文件不能随手清理。

解决：如果环境文件被删，不要试图手动拼回来。标准做法是用adop或者备用的上下文信息重新跑一次 autoconfig，让系统重新生成环境文件；如果没有备份可用，只能恢复到最近一次应用层备份，这也是为什么第 4 章里强调应用层文件必须单独备份。日常清理时，只处理日志目录里超过保留周期的纯日志文件，保留目录结构和权限，靠近环境文件的位置一律只看不删。

5.4 克隆之后 APPS 密码不一致，连接一测就黄

现象：克隆测试环境完成，用系统管理员登录正常，但业务系统里某些接口连接数据库时报ORA-01017，提示用户名或密码无效。

原因：克隆过程复制了数据库文件，但应用层配置里的APPS密码和数据库里实际记录的密码不一致。adcfgclone通常会在配置过程中统一两边的密码，但如果你执行顺序打乱、或者在克隆后单独手工改过数据库侧密码，这个同步就会被破坏。

解决：用FNDCPASS工具重新设置APPS密码。命令格式一般是FNDCPASS apps/apps_old_password 0 Y SYSTEM/system_password APPLSYS new_password。操作前确认已经加载目标环境的环境文件，并且数据库连接用户有权修改口令。改完之后再用sqlplus apps/new_password@host:port/SID验证一次，确保两条链路都通。

5.5 跑大报表时表空间不足，请求在中间状态卡死

现象：月末跑批量报表时，多个请求同时卡在 Running，DBA 查看数据库发现临时表空间或应用表空间满了，后台日志报ORA-01652或ORA-01653。

原因：并发请求过多时，排序和中间结果把临时表空间撑满；而正常的应用表空间装不下新增的审计、接口表数据。很多系统管理员只盯着请求队列，忽略了数据库空间，导致问题被误判为并发管理器故障。

解决：先扩容临时表空间缓解当前压力，再查哪些请求占用了大量排序区。我的习惯是每天巡检时检查临时表空间使用率，超过 80% 就提前加一个临时数据文件。长期治理则是拆分大报表的提交时间，把几个重量级请求错开，别让它们同时挤在同一个队列上。

6. 把培训手册真正变成自己的运维习惯：脚本化验证与监控

手册里最容易被忽略的一句话是“每次操作后要验证”。系统管理员的工作看着杂，本质上就是“提交变更、验证结果”的循环。如果每次都把验证交给业务用户，自己就一直被动。我后来养成的习惯是把验证动作写成一个脚本，每天早上定时跑一遍，用输出判断环境是不是健康。

# 环境健康检查脚本主干 # 建议放在应用服务器上，由 applmgr 用户执行 source $INST_TOP/admin/scripts/APPS_PROD_ebsapp01.env sqlplus -S apps/apps <<'EOF' SET PAGESIZE 0 FEEDBACK OFF SELECT 'CM_ALIVE=' || COUNT(*) FROM apps.fnd_concurrent_queues_vl q WHERE EXISTS ( SELECT 1 FROM apps.fnd_concurrent_processes p WHERE p.concurrent_queue_id = q.concurrent_queue_id AND p.process_status = 'RUNNING' ); SELECT 'BAD_REQ=' || COUNT(*) FROM apps.fnd_concurrent_requests WHERE request_date > SYSDATE - 1 AND status_code IN ('P','R') AND phase_code NOT IN ('C'); EOF

这段脚本只做了两件事：确认管理器进程存活，统计异常请求数量。第一句输出如果是CM_ALIVE=0，说明所有并发管理器都停了，要立即人工介入；第二句输出如果持续大于零，说明有请求长期排队或卡死，也要处理。脚本里的status_code IN ('P','R')和phase_code NOT IN ('C')这两个条件，组合起来才能准确抓到异常状态，单用一个字段会漏掉很多边界情况。

脚本跑出来的结果不要求立刻修，但一定要有一个稳定的记录位置。我自己会用一个带时间戳的日志文件把每天的输出追加进去，再配合一个简单的磁盘空间检查，每周扫一眼趋势。这套方式坚持几个月，你就会发现环境里很多问题是慢变量：请求积压是慢慢变多的，日志占用是慢慢变大的，等哪天突然爆发再去查，已经很被动了。

另一个值得养成的习惯是“变更前留底”。不管是改职责、停管理器、清理日志，操作前先导出当前状态。这个动作比任何监控都重要，因为监控只能事后告诉你坏在哪，留底才能让你在操作失误时立刻退回去。OracleEBS 的黑匣子太多，很多报错信息并不指向根因，反而是“最后一次改了什么”更有参考价值。把每次变更的时间、命令、预期影响写成一个简短记录，坚持半年，你会发现自己排查问题的速度比被培训时要快得多。希望这套拆解能帮你在系统管理员这条路上少走点弯路。

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