|
|
发表于 2008/10/19 07:55:24
|
显示全部楼层
先给你贡献一篇文档
Applies to: Oracle Applications Technology Stack - Version: 11.5.9 to 11.5.10
Information in this document applies to any platform.
GoalHow To Fix The Forms Timeout Issue In Oracle Applications 11i
The goal of this Document is to find a medium between End Users and proper Server administration. In many cases the Users do not want to ever see a Timeout, but the User do not understand why Timeouts are needed. From a System Administrator point they are required to maintain System Resources and System Stability.
SolutionPlease understand that the ICX Profiles handle the Forms Session. This can be confusing since ICX in the past is known to be associated with Self Service. This is no longer the case since the release of Framework for the ICX Profiles that control the Timeout Functionality.
The Timeout functionality does not work with the Old ICXINDEX.htm, which has been replaced since the release of FND G and 11.5.9. Per the readme's and changes sections of the FND G and 11.5.9 release notes, it states to use the AppsLocalLogin.jsp as the new method of login.
The reason for this is because of the use of Framework. Since the release of Framework ICXINDEX.htm is no longer Q&A Tested against Patches and New Functionality with Tech Stack. There was a Patch released some time ago to prolong 11.5.9, that allowed users to continue using the ICXINDEX.htm until
they could migrate to AppsLocalLogin.jsp. However this patch may no longer work for 11.5.9 customer depending on there current Patch Level. Patch <3764779> (SSO Pre-Req for Application Products - Rollup F).
In addition, Note 306075.1 (How to Change 11i to use AppsLocalLogin.jsp Instead of ICXINDEX.htm) provides further information on AppsLocalLogin.jsp.
ICX: Session Timeout controls the time of inactivity of the session. If set to 30 minutes, then after no activity for 30 minutes you will get the popup window. This is for the Forms Session.
ICX imit Time controls the total time a session can be logged in. If set to 8 hours, then after 8 hours you will get the popup window regardless of what activity is being done. This is for the Forms Session.
ICX:Limit connect is a profile option determines the max number of connection requests a user can make in a single session. If a user sends more requests than the value specified by this profile option in a single session, then the session will expire. This needs to be bumped up to 2000 +, because each time Session Time is checked it adds another ICX connection. This IS NOT DETERMEND BY THE NUMBER OF USER CONNECTIONS. The more ICX checks its self the more ICX connections you are going to see for a user.
Session.timeout is set under the Apache's zone.properties. This should be set to default which is 1800000. Anything higher can result in performance and out of memory errors. Typically session.timeout and ICX:Session Timeout are set to the same value.
FORMS60_TIMEOUT = 5 Check .env for this. This is used to clean up and terminate the Forms Processes. The higher this variable is set, the longer the Forms processes will take to be cleaned up.
Heartbeat = 2 check $OA_HTML/bin/appsweb.cfg and or appsweb_<sid>_<host>.cfg. This is used to send a packet to the Server to indicate it is still active.
The following is an Example from a FRD Trace, that proves how the ICX Profiles are called for the Forms Session.
----------------
SELECT LIMIT_CONNECTS, LIMIT_TIME, FIRST_CONNECT, COUNTER, NVL(DISABLED_FLAG,'N'), LAST_CONNECT, USER_ID, NVL(:B3,RESPONSIBILITY_ID), NVL(:B2,RESPONSIBILITY_APPLICATION_ID) FROM ICX_SESSIONS WHERE SESSION_ID = :B1
END OF STMT
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
---------------
SOLUTION
---------
The following are the best practice setup
1. Profile Options:
ICX: Session Timeout = 30
ICX:Limit Time = 12
ICX:Limit connect = 2000
These Profiles control the Forms Session. If a Timeout is caused by a ICX Profile you will be prompted to log back in. Please understand the higher you set the Profile ICX Session Timeout, the more of a performance hit your server will take. If set to high, the Server can randomly crash. It is recommended to
set this profile no higher then One Hour (60). If the Profile is set to One Hour (60 minutes), the Users should never encounter a Timeout unless the PC has been left unattended for a hour. Also by setting this to One Hour, this will allow the Resources being held by that Inactive session to be timed out, so that Active Users can have access to the resources.
2. Apache zone.properties:
session.timeout = 1800000
Under Apache_Top:
$ grep -i session.timeout zone.properties
session.timeout=
Session.timeout is what controls the Self Service Timeout. If this times out, you will not be prompted to log back in and will receive a JSP/WEB type error message.
3. Modify the $FORMS60_WEB_CONFIG_FILE, which points to the appsweb_host_sid.cfg file:
networkRetries=30
heartbeat =2
Under OA_HTML/bin:
$ grep -i heartbeat appsweb.cfg
heartBeat=
networkRetries=
$ grep -i heartbeat appsweb_<SID>_auohs<host>.cfg
heartBeat=
networkRetries=
4. If for 11.5.9 check for the following Patches and make sure they are applied:
Patch <2999849> Fix for Javascript error on IE with ICX:Session Timeout Window
Patch <3102240> New Personal Home Page opened when re-establishing ICX session
Patch <3251742> "ICX Session Timeout and login results in forward to incorrect home page.
5. If using Forms servlets check the following:
Check formservlet.ini in Apache for FORMS60_TIMEOUT=5
To check if using servlets look for the line in jserv.conf file:
#ApJServGroup FormsGroup 1 1 /u02/oracle/visora/iAS/Apache/Jserv/etc/forms.properties
If using servlets this line will be uncommented.
Check also the appsweb.cfg under OA_HTML/bin for line:
; serverURL=/forms/formservlet
If using servlets this line will be uncommented.
$ grep -i forms60_timeout formservlet.ini
FORMS60_TIMEOUT=
6. FORMS60_TIMEOUT = 5 (check SID.env for this or echo$FORMS60_TIMEOUT)
Heartbeat = 2 (check $OA_HTML/bin/appsweb.cfg)
Note: There can be two different errors that affect the FROMS60_TIMEOUT and the heartbeat. If there are Intermittent FRM-92100 type errors it is due to the heartbeat being to high and timing out. So the heartbeat setting will need to be adjusted to suit your needs. If the FORMS60_TIMEOUT is set to a higher value you may see run away f60webmx processes. If there are run away f60webmx or f60webmx processes not terminating, then return the FORMS60_TIMEOUT to the default value of 5 and retest.
7. Bounce Forms Server.
8. Clear Apache cache $OA_HTML/_pages
9. Bounce Apache Server.
Intermittent Errors seen from different Timeouts:
--------------------
Customers often change the heartbeat around for what suits them best. If you see FRM 92100 type errors this would be related to the heartbeat. If you see FRM 92050 or 92102 type errors then the FORMS60_TIMEOUT setting would be related to this type of error. Some Customer may have a long FROMS60_TIMEOUT setting and may get caught by the heartbeat timing them out, so they will
extend the heartbeat. An example: User takes a break that and leaves their Forms Session open, heartbeat see no activity with the f60 process, so times them out and when the user attempts some activity they will see an FRM 92100 type error. Other customer prefer not to see this type of error, so they will extend the heartbeat, but what will happen in this case if the user has no activity by the time the FORMS60_TIMEOUT comes around, it will time them out resulting in a FRM 92050 or 92102 type of error. Regardless if users complain about random FRM 92050 , 92102 and 92100 errors you should be double checking your FORMS60_TIMEOUT and heartbeat settings.
AutoConfig Note:
------------
Make the above changes in AutoConfig, otherwise the next time AutoConfig is run the modifications made will be reset by the running of AutoConfig.
Autoconfig will match up the zone.properties session.timeout to the Profile ICX Seesion Timeout each time Autoconfig is run, if the two variables do not match.
Example:
In the autoconfig log, you can see the Profile ICX_SESSION_TIMEOUT is getting updated when the afwebprf.sh is being run under $OAD_TOP/admin/install/_/afwebprf.sh. The shell plainly shows what the old value of the profile was and that it replaced it with a new value in the output.
This shell calls afwebprf.sql to update the profiles. When looking at the SQL, it sets the Profile to match the value of the session.timeout in the zone.properties file under Apache. This even does the math and converts from milliseconds to minutes.
Now the rule is that the IXC Session Timeout must match the Apache zone.properties session.timeout.
AutoConfig Paramaters
---------------------
oa_var="s_sesstimeout" = session.timeout
oa_var="s_frmNetworkRetries" = networkRetries
oa_var="s_f60webcfg" = $FORMS60_WEB_CONFIG_FILE
oa_var="s_f60time" = $FORMS60_TIMEOUT
Concerning the issue with heartbeat not being in the autoconfig file, this issue is documented in Bug 4211534. The bug says it is ok to manually modify the appsweb_<sid>.cfg file until the fix is available. The Fix will be available in Patch <4489303> :TXK (FND) AUTOCONFIG TEMPLATE ROLLUP PATCH L
Performance Note:
--------------
Timeouts are meant to serve two main functions:
One to maintain the Performance of the Server.
Two minimize security risks. It is a Security Risk if the User leaves the PC unattended for extended period of time, leaving the Applications session open. This allows anyone else to enter false information. Timeout Functionality senses the inactivity while the user is away from the desk and times out, rendering the open window useless.
Timeout functionality maintains the performance on the Server. This goes into JVM Performance which will drain and cause out of memory errors in the Apache Server. At this point the JVM can run out of Memory and "SPILL" into the DB which increase the performance problems.
Customers think the quick fix is to just extend the Timeout Functionality out to many hours latter, but the longer Timeout Functionality is set, the more performance you are taking away from the system Mainly memory and CPU. Space would be a factor depending on activities and log files being written to for
those activities.
The key to the timeout value is finding a happy medium between getting rid of sessions soon enough after people have stopped using the session but not forcing people to re-authenticate too often because they have left their session alone for a 30 or 60 minutes.
Any time Performance becomes a issue on a Server, the Timeout Functionality should be the first thing checked.
Common Database Timeouts seen in Event logs:
-----------------------
ORA-02396 : exceeded max Idle Time, please connect again
Cause: A user has exceeded the maximum time allowed to remain idle.
Action: The user must reconnect to the database
This is a error generated from the Database. In this particular case, it looks like the User that reached MAX IDLE_TIME has to reconnect to unlock the DB.
Need to log into SQLPLUS as the System Manager!!
Now I have a seeded DB, so I can still use Scott as the Username to get my Profile Name.
Once you get the Profile Name, then we can check the IDLE_TIME.
SQL> select profile from sys.dba_users
2 where username = 'SCOTT';
PROFILE
------------------------------
DEFAULT
SQL> select limit from sys.dba_profiles
2 where profile = 'DEFAULT'
3 and resource_name = 'IDLE_TIME';
LIMIT
----------------------------------------
UNLIMITED
When the ORA-02396 error is seen, it is because there is a numeric value returned form the SQL above. By default, the value is "Unlimited". If you do not see Unlimited, then please update the IDLE_TIME is set to Unlimited as given above.
SQL Timeout
--------------
Check the $DB_ORACLE_HOME/network/admin/<CONTEXT>/sqlnet.ora for the SQLNET.EXPIRE_TIME. This parameter determines the time period between successive packets across a connection between client and server. This is basically the equivalent of the Applications Heartbeat.
It is recommend to keep this at the default value of 10 minutes. If for some reason you need to adjust this parameter, keep it under the ICX Session Timeout value. This will allow the Database to clean up inactive DB Sessions.
This is also known as Dead Connection Detection (DCD) for the DB. |
|
|Archiver|小黑屋|手机版|壹佰网 ERP100
( 京ICP备19053597号-2 )
IP卡
狗仔卡
发表于 2008/10/14 22:54:24
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主