Oracle EBS中快速查看某个请求的Output File或log File等信息(转载)

    项目上,经常有请求报红报黄等问题反映到技术顾问这边,但是由于某些权限的限制,有时候哪怕System Administrator职责也只能看到某个Request信息,但是不能查看它的Output File。用下面这个方法可以很方便地查看请求的输出和日志等信息,甚至不用进系统就可以查看了,只需要一个请求编号就可以:

/* Function: GET_URL
*
* Purpose: Constructs and returns the URL for a Concurrent Processing
*          log or output file.
*
* Arguments:
*  file_type – Specifies the type of file desired:
*       fnd_webfile.process_log = The log of the concurrent process identified  by the parameter ID.
*       fnd_webfile.icm_log     = The log of the ICM process identified by ID.
*                                 Or, the log of the ICM process that spawned
*                                 the concurrent process identified by ID.
*                                 Or, the log of the most recent ICM process
*                                 if ID is null.
*       fnd_webfile.request_log = The log of the request identified by ID.
*       fnd_webfile.request_out = The output of the request identified by ID.
*       fnd_webfile.request_mgr = The log of the concurrent process that ran the request identified by ID.
*       fnd_webfile.frd_log     = The log of the forms process identified by ID.
*       fnd_webfile.generic_log = The log file identified by ID.
*       fnd_webfile.generic_trc = The trace file identified by ID.
*       fnd_webfile.generic_ora = The ora file identified by ID.
*       fnd_webfile.generic_cfg = The config file identified by ID.
*       fnd_webfile.context_file= Applications Context file identified by ID.
*       fnd_webfile.generic_text= Generic file using text transfer mode.
*       fnd_webfile.generic_binary = Generic file using binary transfer mode.
*       fnd_webfile.request_xml_output = The xml output of Concurrent Request.
*
*  id        – A concurrent process ID, concurrent request ID, or file ID
*                 depending on the file type specified.
*              For fnd_webfile.context_file,fnd_webfile.generic_text,
*              fnd_webfile.generic_binary this value is null.
*  gwyuid    – The value of the environment variable GWYUID used in constructing the URL.
*  two_task  – The database two_task, used in constructing the URL.
*  expire_time – The number of minutes for which this URL will remain valid.
*  source_file – Source file name with full patch
*  source_node – Source node name.
*  dest_file   – Destination file name
*  dest_node   – Destination node name
*  page_no     – Current page number
*  page_size – Number of lines in a page
*  Returns NULL on error.  Check the FND message stack.
*/
FUNCTION GET_URL(FILE_TYPE   IN NUMBER,
                 ID          IN NUMBER,
                 GWYUID      IN VARCHAR2,
                 TWO_TASK    IN VARCHAR2,
                 EXPIRE_TIME IN NUMBER,
                 SOURCE_FILE IN VARCHAR2 DEFAULT NULL,
                 SOURCE_NODE IN VARCHAR2 DEFAULT NULL,
                 DEST_FILE   IN VARCHAR2 DEFAULT NULL,
                 DEST_NODE   IN VARCHAR2 DEFAULT NULL,
                 PAGE_NO     IN NUMBER DEFAULT NULL,
                 PAGE_SIZE   IN NUMBER DEFAULT NULL) RETURN VARCHAR2;

 

–调用代码

SELECT FND_WEBFILE.GET_URL(3, –输出类型  
                           523502, –请求编号  
                           'APPLSYSPUB/PUB',
                           'FCWW',
                           10)
  FROM DUAL;

–参数介绍

第一个参数4表示request的output,(可根据需要决定)
/* Define file types for get_url */
process_log constant number := 1;
icm_log constant number := 2;
request_log constant number := 3;
request_out constant number := 4;
request_mgr constant number := 5;
frd_log constant number := 6;
generic_log constant number := 7;
generic_trc constant number := 8;
generic_ora constant number := 9;
generic_cfg constant number := 10;
context_file constant number := 11;
generic_text constant number := 12;
generic_binary constant number := 13;
request_xml_output constant number :=14;

第二个参数是request_id
第三个参数是环境参数GWYUID
第四个参数是two_task,
第五个参数是url有效的分钟数. 
然后就是把这个url复制到ie就可以看到了.

转载自:https://zhangzhongjie.iteye.com/blog/1815442

EBS Concurrent Manager(并发管理器)异常处理

EBS R12.1.3

并发管理器如果出现问题, 一般重新启动即可解决,但有时候adcmctl.sh stop 仍然关闭不了, 还是有很多
并发管理器进程在系统中运行, 这时我们可以使用kill 来进行清理,之后需要执行oracle提供的cmclean.sql
来清理并发请求 。

Kill 并发管理器进程 –
如果是 LINUX :
ps  -ef |grep FNDLIBR|grep -v grep|cut -c 9-15|xargs  kill -9

如果是 AIX : 
ps  -ef |grep FNDLIBR|grep -v grep|cut -c 9-17|xargs  kill -9


kill掉FNDLIBR这个并发管理器中最多的进程后,还有一些进程比如FNDSM,FNDSCH,FNDCRM,
INVLIBR 等这些大小字母进程是属于CONCURRENT MANAGER并发管理器的,也需要kill掉,
然后使用cmclean.sql 进行并发请求的清理。 通过数据库SQL查看是否存在ICM程序还在运行:

select sid, serial# from v$session where  program like  '%ICM%' ;

如果存在记录, 通过 alter system kill session 'sid,serial#' ; 进行清理。

最后重新开启  adcmctl.sh start, 登入EBS查看状态。

转载:http://blog.itpub.net/35489/viewspace-1262307/

Oracle EBS控制会话时间及超时

1. ICX:会话超时                            ICX:Session Timeout
            定义系统保持一个非活动的用户会话的超时间隔。默认为1800000毫秒(30分钟)。

2. ICX:限制时间                            ICX: Limit time
            定义系统保持一个用户会话的最长登陆时间。默认为4个小时。

3. IEU:桌面:会话超时(分钟)  IEU: Desktop: Session Timeout( min )
            = 30|60|90|120|150|180|210|240 = 90
    不仅仅是ICX:session.timeout 设置。在Jserv中也有一个session.timeout,(zone.properties文件中)它默认的值为30分钟。
这两个值以最小的一个为准。在EBS profile的ICX:session.timeout值设的再大。Jserv 的session.timeout的值不改也起不了作用。
但Jserv的session.timeout值oracle建议最大为30分钟。设的过大会造成JVM内存出错。
(这个是不是可以解释为什么更改了会话超时的时间,但仍然没有什么效果?),这个根据我之前的实际测试,icx:限制时间最好不要更改,直接修改icx:会话超时(一般也不要超过4小时)就没问题了。

技术笔记(小潘的技术记录博客)