简介Oracle EBS系统管理员培训手册是一份面向Oracle EBS系统管理员、运维人员及企业信息化支持团队的培训电子文档基于Oracle Application 11i中文版环境编写。内容围绕系统日常运维展开涵盖责任与用户管理、功能与菜单安全、报表权限控制、并发程序和请求监控、预置文件配置、关键性/描述性弹性域及值集设置、单据序列与安全性控制、打印机配置等核心模块同时涉及并发管理器工作班次、请求生命周期状态调整、请求集/请求组定义等高级管理功能目录结构清晰便于按章节检索。资源包内共1个doc文件约1.44MB适合在Windows或Office环境下直接查看与标注学习。已有58人学习使用。手册配有大量实践操作示例和分模块练习能够帮助初学者理解系统管理员职责也为有一定经验者提供查漏补缺的速查参考从而提升Oracle EBS系统的运维效率与安全管理水平。1. OracleEBS 系统管理员培训手册背后的基本功从救火到建制接手第一套 Oracle EBS 时很多人是被一个告警电话叫醒的——某个并发请求跑了四小时还没结束财务在催关账而你连并发管理器在哪查都不知道。Oracle EBS 系统管理员培训手册之所以一直是团队里流传最广的文档正是因为这类系统没有“概览”可言你面对的是一整套由应用层、数据库层、并发管理器、配置文件和职责权限交织成的运行体系任何一个角落出问题业务侧感受到的都是“系统卡了”“报表出不来”。本文想梳理的不是把某份 DOC 抄一遍而是把一个系统管理员五年内最常踩的坑、最该背下来的命令和参数逻辑讲透。无论你是刚拿到 EBS 环境的新手还是已能独立处理 P1 故障的熟手这里都有值得核对一遍的细节。Oracle EBS 系统管理员的日常本质上就是三件事维护并发管理器使其稳定消化请求管理用户、职责和功能权限保证访问可控在打补丁和月结之间用最小的代价保持应用与数据库的一致状态。这三件事背后又都依赖一组固定的运维对象应用文件系统、数据库表、配置文件选项和日志目录。这套体系和管理一个普通 Web 应用完全不同因为没有“重启一下就好”的魔法你必须先知道状态查哪里、日志写哪里、参数改哪里。2. Oracle EBS 的关键架构组件与系统管理员必须理解的数据流2.1 两层应用架构下的系统管理员视野Oracle EBS 通常部署为两层客户端服务器结构客户端通过 Forms/Web 界面访问应用层运行着 Apache、Forms 服务器、并发管理器和内部服务数据库层负责所有业务数据的存储与处理。系统管理员接触最多的不是业务模块而是应用层与数据库层的连接状态。当一个用户报告“保存失败FRM-92101”时你的第一反应不应该是去看业务表而应该检查应用层到数据库的连接池是否被占满。从培训角度最需要建立的概念是“服务”和“通知”的分离。EBS 里每个请求Concurrent Request被提交后由并发管理器Concurrent Manager调度系统会生成一个请求 ID并把它写入FND_CONCURRENT_REQUESTS表。你后来做的所有查询、杀进程、重跑请求基本都是在和这张表以及相关的FND_CONCURRENT_PROCESSES表打交道。理解了这个基础你就明白了为什么很多经典的排错 SQL 都是从这两张表开始的。2.2 配置文件Profile的继承与优先级另一个必须吃透的组件是配置文件选项Profile Option。EBS 的所有运行时行为从日期格式到打印机的默认队列都由配置文件控制。配置文件有四层作用域站点层Site、应用层Application、职责层Responsibility和用户层User。当你在“个人配置文件”里修改一个值时可能只影响当前用户而在系统管理员职责下修改站点层则影响所有用户。这里的优先级是用户 职责 应用 站点后设置的覆盖先设置的。常见的配置文件比如ICX_SESSION_COOKIE、FND_CP_LOGOUT、PRINTER等在实际运维中经常出现“我改了配置文件但没生效”的情况。原因往往不是没保存而是配置文件的“生效模式”分为延迟会话惰性和即时。修改后必须让对应会话重新登录或者重启 Apache 和 Forms 服务才能真正完全生效。培训时最容易忽略的就是把配置文件当作普通参数直接“改完即用”。2.3 并发管理器的运行机制与请求状态机并发管理器是 EBS 里最容易出 P1 故障的部分。你必须清楚一个并发请求的状态变迁过程Pending→Scheduled→Running→Completed/Normal/Error以及特殊状态Hold挂起和Terminating正在终止。当一个请求长时间停留在 Running 状态你需要先确认它对应的实际数据库会话是否还活着。如果数据库会话已经消失而并发管理器还认为它在运行这就是典型的“幽灵进程”。系统管理员对并发管理器的核心操作有三个查看运行中的请求、终止异常的请求、管理管理器本身的启停。用下面这条 SQL 可以直接看到当前所有正在运行的请求及其对应的进程 IDSELECT request_id, phase_code, status_code, os_process_id, oracle_process_id, actual_start_date FROM fnd_concurrent_requests WHERE phase_code R AND status_code R;这条语句把物理进程与请求映射起来os_process_id是操作系统层进程oracle_process_id是数据库会话的 sid。当你需要强制终止一个请求时单靠界面上的“诊断”按钮往往不够我一般会先查这两个 ID再从操作系统或数据库层 kill避免留下孤儿进程。3. 用 SQL 和运维脚本落地系统管理员的日常任务3.1 用户、职责与表单权限的核心查询在 Oracle EBS 中权限模型由三个概念构成用户User、职责Responsibility和菜单Menu。职责是一个菜单树的入口用户通过被分配职责来获得对应的功能访问权。系统管理员培训中最容易混淆的是“职责”和“权限”的关系职责里包含了菜单、请求组和数据权限范围因此修改一个职责的菜单会同时影响所有被分配该职责的用户。下面这段 SQL 可以用来快速查找某个用户所拥有的职责SELECT u.user_name, r.responsibility_key, r.responsibility_name FROM fnd_user u, fnd_user_resp_groups_direct ur, fnd_responsibility_tl r WHERE u.user_id ur.user_id AND ur.responsibility_application_id r.application_id AND ur.responsibility_id r.responsibility_id AND u.user_name :username;这里用了fnd_user_resp_groups_direct视图它只查“直接分配”的职责不会包含通过管理员层次结构间接继承的结果。实际运维时我们经常需要查“这个人为什么能打开某个表单”这样的追溯问题那就必须继续关联菜单结构而不是只看职责名。3.2 配置文件值的后台修改与验证当用户说“我的打印机不对”或“我的日期格式是英文”系统管理员一般不会让用户自己在偏好里改而是直接通过FND_PROFILE_OPTION_VALUES表来批量修正。但注意直接写表从来不是官方推荐的方式最佳实践是通过FND_PROFILE包或者应用界面去修改。不过在自动化运维中查询是经常用到的SELECT profile_option_name, profile_option_value, level_type, level_value FROM fnd_profile_option_values WHERE profile_option_name ICX_FND_USERNAME ORDER BY level_type;level_type对应值SITE、APPL、RESP、USER四种层级。这条 SQL 能帮你一眼看出某个配置是不是被用户层或职责层“盖住”了。比如你想设置所有用户的会话超时为 30 分钟却发现站点层改了没用因为用户层已经有值。这时你需要先删掉用户层的记录再修改站点层或者直接把用户层的值改成目标值。3.3 并发请求清理的运维脚本片段并发请求表会随着时间膨胀严重影响磁盘空间和查询性能。定期清理历史请求记录是系统管理员的基本功。EBS 自带请求清理功能但很多团队会用一段自定义的删除脚本在低峰期执行。需要注意不能直接删FND_CONCURRENT_REQUESTS的记录因为它的子表FND_CONCURRENT_REQUESTS_TL、FND_CONCURRENT_REQUEST_DATA等还有外键约束。一个更安全的做法是把某个日期之前的数据归档到一个历史表然后删除。下面的 PL/SQL 片段展示了如何按日期清理已完成请求并同时删除关联的日志文件。注意这里用了x_phase和x_status参数只清理成功和警告状态的请求错误状态的请求会留下供排错。DECLARE CURSOR c_requests IS SELECT request_id, logfile_name FROM fnd_concurrent_requests WHERE actual_completion_date SYSDATE - 30 AND phase_code C AND status_code IN (C, W); v_count NUMBER : 0; BEGIN FOR rec IN c_requests LOOP fnd_file.del_file(rec.logfile_name); DELETE FROM fnd_concurrent_requests WHERE request_id rec.request_id; v_count : v_count 1; END LOOP; COMMIT; dbms_output.put_line(Deleted: || v_count); EXCEPTION WHEN OTHERS THEN ROLLBACK; raise_application_error(-20001, Cleanup failed: || SQLERRM); END;这段代码在清理前先调用了fnd_file.del_file删掉实际日志文件避免留下无主文件。删除主表记录时数据库会自动级联处理子表。如果你运行时报出外键约束冲突说明该请求还有相关子记录未处理可以用ALTER TABLE DISABLE CONSTRAINT临时禁用但我不建议在生产这么干更稳妥的做法是对每个请求单独删除子表。4. Oracle EBS 补丁维护与应用层的可靠性操作4.1 补丁Patch的检查与验证EBS 的补丁应用不像是简单替换几个文件它涉及数据库对象的 DDL 变更和应用层代码文件的同步。系统管理员培训手册里补丁章节往往最厚。核心步骤包括检查补丁依赖、分析影响、应用补丁、验证日志。过去常用的adpatch命令仍然是不少老站点的首选而新版本则推荐adopOnline Patching。不管用什么工具第一步都是读取补丁的README里面会写明需要停哪些服务、是否有强制 downtime。在应用补丁之前有一个经典检查必须做确认目标补丁所需的数据库版本和中间件补丁是否已安装。用如下 SQL 查询当前数据库补丁级别SELECT patch_id, patch_type, applied_date FROM ad_applied_patches ORDER BY applied_date;如果看到patch_id为空或状态是PARTIAL说明之前的补丁应用失败过。这种情况下直接应用新补丁是危险的会有大量冲突。通常要先撤销失败补丁或者手工完成未完成的数据库脚本。4.2 应用层服务管理adop 与 adcmctl新版 EBS 12.2 中应用层服务的管理命令已经从adstrtal.sh转向adop和adcmctl.sh。adop能实现滚动补丁允许在不停机的情况下应用补丁原理是维护两套文件系统run edition 和 patch edition。系统管理员需要理解这两个文件系统的切换机制。下面是一组在 patch 文件系统上应用补丁并切换的标准命令序列# 进入补丁工具 cd $ADMIN_SCRIPTS_HOME # 第一阶段准备 adop phaseprepare patchesYOUR_PATCH_TOP # 第二阶段应用 adop phaseapply patchesYOUR_PATCH_TOP # 第三阶段切换切到 run 版本 adop phasefinalize cleanupfull每条命令执行时都要先查看输出日志里的FATAL和ERROR关键字如果某个 phase 失败不能直接跳到下一阶段要用adop phaseabort回滚。我在实际环境里经常看到有人跳过finalize直接手动重启用adstrtal这会导致文件系统版本错乱。记住adop的日志在$APPL_RGTOP/logs/appl/ctx/adop/下面失败时要先看adop日志和对应 SQL 日志。4.3 服务启停顺序与健康检查EBS 的服务有严格启停顺序先停应用服务再停数据库启动顺序相反。用adcmctl.sh stop apps/apps停止应用服务后才允许正常执行shutdown immediate关闭数据库。但很多人会忽略一个重要步骤停止应用服务前应该先检查并发管理器是否还在跑批。下面的 shell 片段能在停机前检查并发管理器进程数ps -ef | grep FNDLIBR | grep -v grep if [ $? -eq 0 ]; then echo 并发管理器仍在运行先停管理器 # 通过并发管理器界面提交关闭请求或直接使用 cd $FND_TOP/bin CONCSUB apps/appsDBNAME SYSADMIN SYSADMIN CM STOP fi使用CONCSUB提交停止请求的好处是它能等当前正在执行的报表完成或者到达你设定的超时而直接kill很可能造成数据不一致。这里参数中的CM指并发管理器的简称STOP是内部请求名。这个方法比kill -9更优雅也是许多资深管理员推荐的做法。5. 排错实战并发卡死、日志定位与配置文件失效的处理技巧5.1 并发管理器的假死识别与恢复实例最常见的假死现象是请求显示 Running 四个小时但实际数据库会话早没了。处理步骤是固定的先查fnd_concurrent_requests中该请求的oracle_process_id再到数据库里查v$session是否还存在SELECT sid, serial#, status, logon_time FROM v$session WHERE sid :oracle_process_id;如果查不到记录说明会话已经消失。此时可以直接在应用界面告知系统终止该请求。终止后管理器会收到一个“请求被取消”的事件并清理内部标记。若管理器本身也崩溃了你需要重启并发管理器。使用adcmctl.sh start apps/apps管理器会自己恢复状态但前提是应用层的FNDLIBR进程能正常启动。5.2 日志文件快速定位技巧每个并发请求都有对应的日志文件路径通常存放在FND_CONCURRENT_REQUESTS.LOGFILE_NAME。但文件不一定存在于本地应用服务器可能分布在多节点环境中。我一般用这个 SQL 直接取日志路径SELECT request_id, logfile_name, output_file_name FROM fnd_concurrent_requests WHERE request_id :req_id;拿到路径后如果该节点不是当前所在服务器你需要登录到对应节点查看。很多老手会写一个 shell 函数来 grep 日志内容比如grep -i -E error|exception|fail /path/to/request_*.log不要指望日志里直接写着“错在哪里”EBS 的日志经常是笼统的FND-30614或ORA-01403。这时要结合日志上下文比如定位到具体执行到哪一步再去查对应的包或表。比如ORA-01403表示NO_DATA_FOUND在报表中常见于参数查询无结果不一定是错误。5.3 配置文件不生效的排查顺序配置文件问题在运维中反复出现但排查路径是有序的。按以下顺序操作多数情况能在十分钟内解决先确认改的是不是正确层级。比如用户在“我的配置”里改了默认打印机但站点层的值又覆盖了它你需要删掉用户层值。检查配置文件的生效模式。打开中间层服务ADMIN页面查看Profile的Effective Date是否在过去并且是否标注了“需要重新登录”或“需要重启服务”。查看是否有缓存问题。EBS 应用层会缓存配置文件值有时需要清理$APACHE_TOP/tmp下的文件并重启 Apache。重新提交测试请求确认新值是否被写入应用系统。有一种隐蔽情况是配置文件在数据库中存储了多个同名列但应用在不同节点上运行时读取了不同的值。这通常是因为多节点环境中的context file未同步。你需要验证APPLLCTX环境变量是否指向正确的文件并检查每台节点上的上下文值是否一致。5.4 一个常用的自动化监控脚本片段如果希望能在问题发生前收到提醒可以写一个简单的 shell 脚本利用SQL*Plus定期检查运行超过阈值的请求#!/bin/bash export ORACLE_HOME/u01/app/oracle/product/12.2.0/db_1 export PATH$ORACLE_HOME/bin:$PATH sqlplus -s apps/apps$ORACLE_SID EOF set pagesize 0 set feedback off set echo off select count(*) from fnd_concurrent_requests where phase_codeR and actual_start_date sysdate - 2; exit EOF把这个脚本放进cron每小时执行一次如果返回数字大于 0就说明有请求卡了超过两个小时。你还可以进一步结合邮件工具mailx发送告警。这里的关键是actual_start_date是启动时间而不是提交时间避免误报。这一小段脚本看起来简单但它把 EBS 排查中最核心的“按请求状态看问题”变成了自动化。如果一个系统管理员能把上面的 SQL 和 Shell 都熟练运用再遇到并发管理器异常、配置文件不生效和补丁失败时就不再是盲人摸象而是能按步骤快速收敛问题范围。这也正是那份培训手册真正的价值所在不是列举菜单和按钮而是让你理解后台数据表和进程之间的联动关系并给出可复现的排查路径。本文还有配套的精品资源点击获取