Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Apps R12 Upgrade Paper

Apps R12 Upgrade Paper

Ratings: (0)|Views: 172 |Likes:
Published by hemalroha

More info:

Categories:Types, Reviews
Published by: hemalroha on Aug 02, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Oracle E-Business Suite R12 Upgrade 
August 2009 Vasu Balla Pythian 
A typical Oracle E-Business Suite R12 upgrade (from 11i) is normally not meant to be thatcomplicated as the procedure is pretty much detailed in the Oracle Applications Upgrade Guide,which as we all know, can be downloaded from OTN (Oracle Technology Network).However, not everything in life is typical. During the past few months, we (Pythian) were one ofthe prime technical Apps database experts on a rather interesting and challenging Apps R12upgrade for one of our clients, which entailed quite a few particularities. As a note: during theupgrade, we encountered several challenges, which we were able to solve with very limitedOracle Tech Support assistance, resulting in significant time savings.As a requirement, the final Apps R12 upgraded system (12.0.6 in this case) needed the followingconfiguration specifications:-
SSL enabled-
load balanced-
external users to access iSupplier-
external users to access iReceivable-
external users to be authenticated through NAM3 (Novell Authentication Manager 3.0)-
have a reverse proxy server between NAM3 and the Load BalancerNot only was the R12 upgrade successful it was achieved in 48 hrs as opposed to the estimated72 hrs initially projected.As anyone would expect, merging the patches played an important role in speeding up the overallupgrade time. We ended up merging all Post 12.0.4 upgrade patches (including the 12.0.6 R12RUP6 Patch) in which, we applied the rule of thumb of merging both "non-AD" and "non-FND"patches together and thereafter, to individually apply AD, FND and online-Help patches. Mergingthe patches did save a lot of time, both in limiting the number of adpatch runs, and also in limitingthe number of times the actual adpatch maintenance steps were executed (i.e. compiling Appsschema, compiling jtf files, etc.).Following are the main issues we encountered and how we fixed them. Obviously, every AppsR12 upgrade is unique as it is based on the existing setup, version upgrading from, and R12version upgrading to. The intent of this paper is to share our experience in the hopes that youcan glean some insights to help with your next upgrade.
Purging Non-Required Data From the "GL_INTERFACE" Table Dramatically ReducedOverall Patch RuntimeIn reviewing the patch runtime worker jobs, we've clearly noticed that script "jaiglintfsrcmig.sql"was taking roughly 4 hrs 55 mins to complete. After carefully reviewing the script's SQL path,we noticed that the script was actually doing several updates on the "GL_INTERFACE" table.And this was occurring on an implementation where table "GL_INTERFACE" is (was) not beingpurged after data loads. We then proceeded to ask the client's Development team to identifythe non required data from the "GL_INTERFACE" table, which was then purged prior toengaging the Apps upgrade. Purging the non-required data from the "GL_INTERFACE" table,turned out to save approximately 4 1/2 hours of upgrade time.Apache Lock File IssuesIn setting a second and third Mid-Tier nodes, we've successfully completed the configuration ofa shared APPL_TOP and shared Tech Stack. Redhat GFS was used for the shared filesystem.The only issue faced with the shared filesystem, was that Apache would fail to startup due tothe "adapcctl.sh" startup script timing out. After carefully diagnosing the issue (using the"strace" command to see where the "httpd" processes were hanging), we identified that theissue resulted in Apache trying to lock files on the GFS mountpoints. This appeared to be ageneric issue with most shared filesystem when locking files take place (which is in fact anApache requirement). The issue was fixed by configuring Apache parameters "s_lock_pid_dir","s_pids_dir" and "s_web_pid_file" (in the context xml file) to point to local mount point "/var/tmp"(instead of pointing to shared mountpoints). These changes were made to all context xml filesfor all nodes in the cluster.R12 Login Page not Working After Applying the 12.0.4 PatchAfter applying the 12.0.4 patch, for some reason, the R12 login page stopped working properly,more specifically, the R12 login page would loop between "/OA_HTML/AppsLogin" and"/OA_HTML/RF.jsp?" and consequently, the login page would not come up at all. Afterthorough troubleshooting, we determined that the FND tables and WF tables were notcompletely synchronized, thus making the "RF.jsp" go back to the AppsLogin page as user"GUEST" which in fact, does not have necessary responsibilities against WF tables. Theproblem was then fixed by running the "WF_LOCAL_SYNCH.VALIDATEUSERROLES"procedure.Scrolling with the Mouse Causes the Forms Session to CrashYes, scrolling with the mouse in the Forms screens was indeed causing the users' Formssession to crash. When researching Metalink, the only solution found was to actually patch up

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->