EBS表定时分析

EBS中默认定义了并发程序对数据库对象的进行分析，从而对基于Cost的优化器能够有效的工作。这些并发程序主要通过调用程序包FND_STATS来完成。而实际上，这几个并发程序并不是很方便。例如Gather Schema Statistics算是比较方便的一个，一次可以对数据库中的某个Schema下的对象进行分析。但是如果Oracle中有这么多的Schema，需要提交很多次请求才能完成。实际中，通过自己编写的并发程序来完成批量多个Schema下对象的分析。

Gather Table Statistics
Backup Table Statistics
Restore Table Statistics
Gather Schema Statistics
Gather Column Statistics


步骤：
1. 通过SQL*PLUS程序，SPOOL实际饱含分析语句的fnd_stats_run.sql文件，输出到一个应用的目录下，例如$FND_TOP。在这个文件中，对每一个需要分析的对象，都有如下三行语句组成，例如，对于ABM.ABM_BATCH_CALCS：

EXEC DBMS_STATS.DELETE_TABLE_STATS(ownname => 'ABM', tabname => 'ABM_BATCH_CALCS');
ANALYZE TABLE ABM.ABM_BATCH_CALCS ESTIMATE STATISTICS SAMPLE 1 ROWS;
EXEC FND_STATS.GATHER_TABLE_STATS(ownname=>'ABM',tabname=>'ABM_BATCH_CALCS',percent=>30,degree=>1,granularity=>'DEFAULT');

所以，在这个SQL*PLUS中，可以自己编写逻辑确定哪些Schema下的对象需要分析，根据表的记录数，确定分析的百分比等。

2. 将步骤1种程序定义成并发程序FND STATS PRODUCE。

3. 将步骤1中输出到$FND_TOP目录下的SQL*PLUS程序fnd_stats_run.sql，定义成并发程序FND STATS RUN。

4. 定义请求集，将上述两个请求加入请求集。并定义，只有当FND STATS PRODUCE运行成功之后，才运行FND STATS RUN。

5. 最后，定时运行请求集。

在ITPub上提问调查，到底要不要使用系统自带并发程序，意见还真多，FYI:
http://www.itpub.net/822695.html

Error:Function not available to this responsibility

新环境克隆出来，用户发现对于所有的客户化Form都不能访问，提示的错误为：
Function not available to this responsibility. Change responsibilities or contact you System Administrator.

按照Responsibility，Menu，Function检查，相关定义都没有更改。对比了另外一个环境，发现，发现应用层的服务器上相关Costumer的TOP目录都没有在环境中设置。通过echo $CUSTOMER_TOP，输出为空。所以，当通过Function去找Form的时候，就会遇到如上的错误。

回头想想，问题本应该这样：
1） Form和Report在不同的tie上，客户化的Report都没有问题，只有客户化的Form有问题。
2） 客户化的Menu指向一个客户化的Function（Function对应客户化Form）有问题，如果指向系统标准的Function（例如：Standard Request Submit）没有问题。