ADOP and your new Techstack
As promised, I’m going to continue the discussion about about my R12.2 upgrade and the lessons learned as a part of it by digging into the techstack. There’s a lot of ground to cover here!
General Upgrade Flow and Layout
For a general understanding, I thought I’d start with a basic explanation of the upgrade process. Let’s assume a simple installation, where you have a database tier and an applications tier. As usual, I’m tossing out my disclaimer that this list is NOT complete. It’s a high level look at the basic tasks. Follow the official doc!
- 11i Pre-Patching/Prep Work
You will need to first prep your old environment (in my case 11i, though I suspect this will hold true if you’re on 12.0/12.1) for the upgrade. This means under 11i, you need to apply database patches, run checkers, clean up your customizations, etc. Since R12.2 allows for a 64-bit front end, we chose to create a new front end host and leave the database where it was (since it ran fine). Compared to 11i, these new certifications allow you all kinds of nice things, such as running Linux 6, and allocating huge sums of memory (with a 64-bit OS) to the host without running a PAE (physical address extension for memory) kernel. This in turn allows you to easily accommodate many, large JVMs on the front end. Regardless, you need to be at the appropriate baseline before you begin the upgrade.
Pretty self explanatory; there’s a bunch of mandatory patches to the RDBMS tier.
You first lay down the file system(s) on whatever will be your new R12 application server. Note: You can’t do this ahead of time in production. At this point you’re touching the database and affecting 11i
In the middle of your upgrade, you need to perform a bunch of AD tasks. Such as getting on the right version of the techstack, extending tablespaces, fixing customizations, etc.
This is the last time you’ll run adpatch, and it’s a monster: the largest, longest bit of work involved. Lots of worker fails with errors which you have to go research.
- Another 12.2 Rapid Install pass
Short pass here, against your new R12 filesystem. Congratulations, after this you’re on 12.2 (not a production release, but you can login after this).
- Enabling 12.2 Online Patching
This is why you decided to install 12.2 right? This is a long, database intensive task.
- Applying Techstack Patches
You can mitigate this by using the latest install CD for 12.2.X, but you’ll be installing patches against Weblogic, forms and reports, http server, FMW etc
- Applying 12.2.3 (or 12.2.4, presumably!)
This is it’s own patch, applied with adop
The devil is in these details, which are specific to your installation. An example is configuring Vertex (tax) for your financials
If you’re serious about this upgrade, please Google up Oclay Sariouglu and Dimas Chbane’s (both from Oracle) presentation from East Coast Oracle Users Group conference titled “E-Business Suite 12.2: Architecture and New Features”. Specifically, a PowerPoint called Chbane 12.2 Architecture.pdf is worth reviewing; I’m sorry I don’t know with certainty that you can get it easily if you didn’t attend the conference, you can probably get it through official channels. Here’s the bottom line: Oracle has a scaling recommendation (and a revised scaling recommendation!) for adding oacore and forms JVM’s based on the number of users. The default installation for R12.2 gives you one (1) JVM for forms (forms_server1) and one (1) JVM for oacore (oacore_server1), and each take maybe 256MB or 512MB (I forget which). This is ludicrously small, for any real deployment, and I’m glad I went to this conference and attended this session to at least get the references on how to size them and how to add them. These JVMs live inside of Weblogic, and you need to size them correctly. Because if you go live with the defaults and more than a few dozen users, your JVMs will crash. Check out 1905593.1. We went live with 4 of each (forms, oacore) at 2GB per for an installation footprint of about 1000 users (about a third of whom are in professional forms) and it’s served us well. The truth is our forms footprint is probably too big, but we haven’t cut it back yet.
Adding JVMs is a somewhat manual, command line process, or at least was when we did it, and for being rather essential to a go-live, it stands out as an after-thought to the whole process. This task also includes changes to the context files, which also has hooks to your start/stop scripts (adstrtal.sh/adstpall.sh). Consequently, this has the side effect of making an application server startup (or a maintenance adop cutover) even slower (if it will go down cleanly at all, but I digress). Another bit of fallout is that when you clone, you may need to cut back these JVMs, depending on the memory resources you have available on your non-production host(s). If you find yourself in this situation, I’ll offer this tidbit: this can be accomplished by changing the s_oacorename and s_formsname parms in the context file to eliminate, for example, oacore_server2, oacore_server3, etc. until you get it sized appropriately.
As you probably know, officially, AD is the product abbreviation for Applications DBA, and TXK corresponds to Teckstack. The two are tightly interwoven, to the point that in R12.2 (perhaps in earlier editions, unsure) they must always be on the exact same version, and patched together. It raises an interesting aside, in that to me, as the DBA, as they’re now indistinguishable why bother to make any distinction and not just roll them up under one product… but I digress.
In the middle of your upgrade, you apply AD.C. In my original plan, I think I had the choice of applying AD/TXK delta 3 or delta 4. Since I had nothing to lose, I went with delta 4, and during the course of our upgrade testing delta 5 was released. Delta 5 fixed so many critical bugs in the AD stack that I had to beg the project manager to let me put it in late in the testing phase. For example, we use mobile supply chain (MSCA) and under delta 4 the telnet ports would change during an adop cutover phase (imagine if you will telling hundreds of manufacturing operators to change their telnet ports on PC’s and hand-held devices after every maintenance weekend). All of this gets rather confusing, because officially I’m on AD/TXK delta 5, but that’s not all. Now there’s essential updates on top of AD/TXK which get released, seemingly at random. For example, patches 19445058/19581770 (now superseded by 20034256: additional fixes that were not in the first bundle/November bundle patches for AD Delta 5!) are called “BUNDLE FIXES FOR R12.TXK.C.DELTA.5” and “BUNDLE FIXES FOR R12.AD.C.DELTA.5”. This is a mess. To me, it would be much simpler to consolidate the AD/TXK patches and put some meaning to the versions. Why can’t AD/TXK delta 5 with bundle fix 1 be called, simply, AD.C.5.1? No TXK, I don’t care about the distinction since I always have to apply them together, why are they distinct products to the customer? It’s like selling a cup and the water separately at a restaurant.
Regardless, my point about the AD/TXK C, Delta 3, 4 and 5, additional fixes, essential bundles, mandatory mess ups, fantastic fixes, or whatever else they call it: they change a lot. Research what the latest, greatest version is and install it. Now welcome to another new job task: you need to keep up with this in 12.2 (subscribe to Steven Chan’s blog, at least you’ll get an email when these are released, among other things).
I’ve rambled enough for today, I have plenty more to cover. Up next time: more AD changes and your new techstack!