在应用中，应当避免执行一些长时间运行的操作，毕竟对于一个OLTP环境，快速响应才是重心。在某些情况下，可能无法使用批处理的方案，需要在用户界面做操作，但是某些特殊环节可以后台运行。这时候，在设计功能时就应当考虑异步处理机制，尤其是要用好批处理和后台处理等方式。
对于后台处理方式，EBS中大致有这么几种方式可选：
- 并发请求
并发请求几乎可以实现任何耗时的运算，也是在EBS环境中常用的后台处理方式。比如很多地方都允许设置处理方式，如联机处理、后台处理等。根据系统性能和响应要求自行组合逻辑块。这种方式的优点是实现简单，管理方便，缺点是受限于并发管理器的配置。此外，大多数企业里的并发程序都运行在数据库服务器上，如果涉及到异构系统的数据传递需要考虑到安全方面的问题。
- 工作流 (Oracle Workflow)
如果是逻辑判断比较清晰又比较复杂的话，这是不错的候选方案，实施顾问也可以非常清晰的看到各个流程走向。这个方式的优点是可以将运算逻辑模块化，缺点是偏长于逻辑判断，而不适用于大数据量运算。
- 业务事件 (Business Event)
业务事件依托于Oracle Workflow，允许客户自行订阅并执行客户化代码。业务事件底层用到了AQ，可以将消息从数据库层传递到应用层。这也是我最欣赏的一块内容。EBS内置了很多标准的事件，比如付款、BOM更新、资产转移等。这种方式的优点是代码都在应用层执行，管理方式简单，缺点是标准的业务事件数量太少了。
- DBMS_JOB
这其实算是一种非标准的方式，但是对于客户化应用比较合适。有时候，使用并发请求和业务事件都太过麻烦，但是通过JOB可以非常迅速的剥离执行逻辑，对用户而言，这可以算是比较标准的后台处理方式。这种方式的优点是简单方便，缺点是适用范围有限，适合在数据库层的运算。
- 管道 (PIPE)
Oracle数据库管道技术在EBS系统中，我目前只发现MRP运算时有用到。它在应付多程序间通讯方面有优势，一个极端的应用是你可以在操作系统shell中实时看到某并发请求的运行情况。它的实现逻辑简单来讲，就是一个会话将消息发送的缓冲区，另一个会话从消息缓冲区读取消息。这种方式的优点是通讯方便，缺点是可能需要自行设计多会话间的消息封装机制，并且仅适用于小数据量传递。
- 高级队列(AQ)
EBS中很多异步处理机制都利用了AQ，这相对而言太过于“底层”了，很少在二次开发领域有用到的。在大型的客户化应用中用的较多。
简单来看，对于后台处理方式就以上这么几种了。EBS R12中内置了SOA，可以通过外部平台进行运算，但是我不认为这是EBS系统范畴了。
个人比较推荐的是使用JOB，这在我的经验中是最简单有效的，不过前提是需要自行设计一套错误处理机制。如果涉及异构系统，我优先考虑业务事件。
目前，EBS系统中存在多种日志记录方式，有用于PL/SQL的，有用于Java的，有OAF等开发框架自带的，也有Forms Server之类服务器专用的诊断方式。通常来讲，所有二次开发，为了统一规范和便于管理，应当将将客户化系统中日志记录和Oracle EBS中的日志记录进行整合，用统一的方式进行日志记录和诊断。
Oracle EBS调试日志级别
系统中将调试日志级别分为6个级别，分别是：
| Type |
Level |
Description |
| UNEXPECTED |
6 |
未知异常 |
| ERROR |
5 |
错误 |
| EXCEPTION |
4 |
异常 |
| EVENT |
3 |
事件 |
| PROCEDURE |
2 |
过程 |
| STATEMENT |
1 |
语句，该级别最低，记录的日志信息也最详细。 |
该级别通过配置文件 FND：调试日志级别 控制。
调试日志模块
日志必须指定当前所执行的程序，也就是所谓的模块。模块用于区分不用程序产生的日志，比如我的一套用于将EBS事件通过手机短消息发送出去的整套程序统一定义成日志模块：oracle.apps.cux.msg.transport。如此，不论是简单的PL/SQL、Form或并发程序产生的短信内容，都可以作为一个整体进行日志记录。模块名可以自行定义，该定义需要有意义，并能和其他程序明确区分。该特性由配置文件 FND：调试日志模块 控制。
不需要修改代码，诊断时可以根据需要随时启用或关闭调试日志，由配置文件 FND：启用调试日志 控制。
调用示例
先在程序中创建过程，如：
PROCEDURE trace(x_level IN NUMBER,
x_message IN VARCHAR2) IS
BEGIN
IF (x_level >= fnd_log.g_current_runtime_level) THEN
IF (fnd_log.test(x_level, 'oracle.apps.cux.msg.transport')) THEN
fnd_log.STRING(log_level => x_level,
module => 'oracle.apps.cux.msg.transport',
message => x_message);
END IF;
END IF;
EXCEPTION
WHEN OTHERS THEN
NULL;
END trace;
然后用以下方式调用：
trace(fnd_log.level_procedure, 'Enter get_num');
日志查看
SELECT *
FROM fnd_log_messages f
WHERE f.user_id = 1113
AND f.log_sequence > 492519740
ORDER BY f.log_sequence;
对于普通的二次开发（一些较大的平台可能需要有自己的诊断方式），建议使用通过的方式记录日志，否则，如果各行其是，或者随手就自己设计一套日志记录方式的，当开发数量到达一定规模时，会让管理工作变得复杂。
题外：
这是早期时给团队中二次开发制订的相关规范的一部分，记在Confluence上。近日考虑撤出该平台，在角落里翻出来的一篇。另外，知识库的建设真是一项即简单又麻烦的工作……
案例：用户的职责中存在一个form，从Web页面登录后点击form，出来错误信息：“对不起，不存在可用的有效责任”，英文信息为：“Sorry, no valid responsibilities available”。如果cgi模式下，从其他职责切换过去则正常。
检查职责定义发现Responsibility Key（责任关键字）值是中文——这是很糟糕的习惯，任何key-like的存在都不应该出现ASCII（如英文字母、数字、下划线等）之外的字符。Oracle数据库虽然支持索引字段使用中文，甚至字段名都可以用中文，但是对于EBS这种大型应用而言，使用中文便存在风险。在此案例中，职责Responsibility Key用中文貌似正常，但是职责信息需要被同步到其他地方，而同步程序，你不能保证它会正常工作。
这其实是一个常见问题。解决办法也很简单，正常途径是新建职责（使用英文责任关键字），然后替换下用户的职责即可。非正常途径如下：
- 在数据表(FND_RESPONSIBILITY)中将RESPONSIBILITY_KEY修改为英文字符。
- 执行并发请求Sync responsibility role data into the WF table(使责任职责数据与 WF 表同步)
- 清理缓存。路径：Functional Administrator -> Core Services -> Caching Framework -> Global Configuration -> Clear All Cache
P.S: 关于清理缓存的知识请参考《清理 Oracle EBS 的缓存》。
OK，让用户重新登录吧。
APEX的访问权限主要分为两种：Authentication和Authorization，简单来说，前者控制登录权限，一次登录各处可用；后者控制各页面或模块的权限。事实上，APEX应用中甚至无需管理用户数据，你所需要的是管理逻辑上的权限，而不需要存储权限数据本身，如此，登录权限的管理便可以非常灵活。
而EBS的权限控制稍微复杂一点，但是从登录权限来看却简单许多，主要是通过包FND_WEB_SEC来进行验证，如：
SQL> set serveroutput on
SQL> exec dbms_output.put_line(fnd_web_sec.validate_login('ZEENO', 'PW123'));
Y
PL/SQL procedure successfully completed
只需要调用该过程，即可直接使用EBS的用户登录了。如果APEX和EBS分处不同的数据库中，则可以使用远程过程调用方式：
fnd_web_sec.validate_login@DBLINK('ZEENO', 'PW123');
首先，APEX本地库中创建验证函数：
CREATE FUNCTION ebs_auth(p_username IN VARCHAR2,
p_password IN VARCHAR2) RETURN BOOLEAN AS
BEGIN
-- 使用EBS远程验证
IF fnd_web_sec.validate_login@dblink(p_username, p_password) = 'Y' THEN
RETURN TRUE;
ELSE
RETURN FALSE;
END IF;
END ebs_auth;
按照规范，需要添加p_username和p_password两个参数。
接下来，在APEX中创建新的Authentication Scheme，一切按正常方式进行，所需要改动的，是将上面的验证函数添加到Authentication Function：
如此，即可使用EBS用户、密码进行登录了。
当我面对一个并发请求优化的需求时，常常先问自己，为什么我又要面对这个情况？我们为什么不能在设计时就避免出现今天这种情况？我深刻理解优化是持续的过程，但是问题关键常常在于，程序在设计时并不考虑将来是否需要优化，或者就是留了一个很小的余地。
大家已经知道，Oracle Apps对各组件都可以进行相应的Trace（具体方式可自行搜索本站归档文章），即跟踪SQL执行情况。对于并发请求的跟踪方式曾经在《跟踪(Trace)并发请求》介绍过，操作方式很简单，就是在运行并发请求前先设置为“启用跟踪”。此处介绍一个实际的并发请求诊断案例。
操作步骤：
- 启用跟踪(并发 -> 方案 -> 定义)。在并发程序定义界面，找到目标并发程序，选上“启用跟踪”选项。
- 提交并发请求。
- 在UDUMP目录下找到对应的trace输出文件。
此时生成的trc文件有很多工具可以分析，根据目标不同选择适用的工具。这里介绍四种常用工具和方式：
- 使用tkprof。这是Oracle官方工具，简单、有效而强大。
tkprof test_ora_1239_XZB_CR7665696.trc xzb.txt sort=fchela
关键是这里的排序参数sort，比较常用的排序方式是按照消耗时间倒序。通常，查到消耗时间最大的那句SQL，基本上就找到了问题所在。
这是第一句SQL的统计数据，看上去，解决了它，问题就基本解决了。
- 使用TVD$XTAT。由《TOP》作者开发，在性能诊断方面非常著名、实用的工具。具体使用可以参考工具说明文档，或者《TOP》一书中的介绍。
这是一个概览界面，可以再深入分析各部分数据。
- 使用SwingBench Trace Analyzer。这是我所见的最傻瓜化的有GUI界面的trc分析工具，只要打开trc文件，你就可以知道问题出在哪里了。当然，傻瓜式自然有傻瓜式的局限，该工具的强大在于方便，也仅仅在于方便，强烈推荐给初级用户使用。
本站以前推荐过这个工具，请参考文章：《Trace分析工具：SwingBench Trace Analyzer》。
- 使用Oracle Trace Analyzer。这个工具实际上是tkprof的另一个版本，以一种更简单、直观的方式来分析trc文件，同样的，也推荐给初级用户使用。
本站以前推荐过这个工具，请参考文章：《Trace Analyzer》。
到此，你基本上已经找到了问题所在，至于如何让你的程序更有效率，则是另外更深的领域了。
在这个案例中，将运行时间从3小时降到6分钟，而所有修改的代码加起来不到20个字符。事实上，分析trc文件的工具本身并不是最重要的，重要的是找到问题症结所在，然后是你所采取的优化手段。有些时候，优化一句SQL就可以了，但是很多时候，可能需要重新设计你的程序，尤其是那些超大的SQL，它们真的有必要这样设计吗？
我一直说，优化是系统工程，大处从业务着手（如何设计功能和数据流直接关系到后面的优化余地），小处从架构着手（2-tier？N-tier？），微处从程序着手。业务(功能)顾问、技术顾问和DBA，都应该参与进来。当然，目前国内，这样具备各角色充分协作能力的团队很少，但是必须首先培养这样的意识。
之前做了个列表：EBS管理员应当掌握的知识，这里的管理员要和应用DBA区分开来，虽然实际上，很多中小型企业里的IT部门并没有对此做出区分。常规的DBA和EBS DBA工作内容有所不同，EBS是OLAP系统，但是又和大多数其他的OLAP系统有所不同，用户需要从这里实时查看报表，但同时后台又运行着大量的任务，在任何一个时间段，都可能有非常耗资源的批处理程序被启动，并且这些任务不在你的控制之中。
你或许已经看过很多有关优化的文章了，但是只有一个环节永远是最可靠的，那就是你的实践。当亲身实践过后，搜索的范围就会大大缩小。记住一句话，不要轻易尝试他人提供的方式，除非你仔细看过自己的系统分析报告。为了节省时间，作为一名没有优化经验的EBS DBA，与常规DBA工作相比，可能更需要关注以下内容：
- 熟悉并发管理器。在系统资源耗费比例上，这是绝对值得关注的部分，系统多大部分任务都通过并发请求来执行。对于深入的技术细节，没有任何现成的文档可以帮助你，但是官方文档已足够应付常规的优化工作。
- 理解EBS并不是真正意义上的OLAP系统。有大量的用户对数据的处理操作，实际上都在接口中进行，而接口则通过提交并发请求来进行。在日常业务中，你无法知晓何时会出现一个大量数据处理的批处理程序，用户随时可能提交多个非常消耗资源的批处理程序。你应该预估到这种情况对系统运行造成的影响。有时候，理解业务需求，从业务角度来安排此类程序的执行，会让业务和系统都轻松很多。
- 不要轻易应用Patch。EBS系统永远存在解决不完的BUG，在充分理解解决BUG的必要性，以及充分而全面的测试后才可以考虑应用到正式环境。否则，你将承受影响业务操作的风险，也可能导致系统其他功能的异常，而这异常会占用你的工作时间。记住，在任何一次应用Patch之前，你都应该预估到可能带来的影响，并提前做好准备。
- 记录Patch历史。尽管系统记录了每次Patch应用的时间、操作和内容，但是它并不知道你为什么需要它。需要去记录该Patch期望能解决的问题，应用后出现的新问题以及业务的影响。Oracle Support解决问题时会尝试先了解系统最近有没有什么变动。
- 定期重建EBS索引。EBS中存在大量的索引，约有4万个。某些表可能有频繁的DML操作，你需要注意到这种表，并设置相应的索引的重建计划。重建索引可能耗费很多时间，需要安排一个在线用户最少的时间段来进行。
- 谨慎添加客户化索引。EBS本身是优化过的，并不是设计来仅供一两年使用的。很多性能问题实际上是IT人员自己造成的。有时候，你可能注意到某个程序执行效率很低，原因是没有走相关的索引，但是记得，索引并非越多越好，除非你非常熟悉相关应用，知道自己在做些什么，不然还是交给Oracle Support为好。一个未经分析的索引，可能导致系统性能出乎意料。
- 理解应用Patch是如何进行的。除了理解它本身的工作原理之外，还需要了解它带来的影响，比如Patch是如何改变你本来工作的非常好的某段SQL的执行计划的？你需要知道Patch后，某个批处理程序突然变慢的原因。
- 理解预警。理解其工作原理，清楚的知道利弊。比如事件预警会创建什么样的Trigger。
- 熟悉Apache、UNIX Server、OAS等，这些一般情况下不会成为性能优化的优先目标，但是在今后更深入的工作中会考虑到。
这里并没有列出一个普通DBA应当参与的工作，比如监控回滚段、分析Statspack报表、捕获并提出性能恶劣的客户化SQL的优化建议以及其他份内工作。App DBA作为专业的工作职位自然有其特殊性，比如为什么你不能使用DBMS_STATS做统计？为什么不允许KEEP Pool？
Oracle EBS 本身的技术架构已经可以让合格的DBA大展身手，不论从数据库层还是应用层。不要把注意力全部集中到SQL优化上，尽管这可能就是90%的问题所在，但是它通常由客户化引起。对于纯标准化的EBS应用而言，运行5年后，在性能优化领域将需要从更高处审视整套系统。
