Posts by Vasu Balla
As with any product, when a new feature is introduced, there is always increased chance of bugs. Oracle E-Business Suite is no different. In release Release 12, Oracle introduced a usability feature called Configurable Homepage. This is a new homepage layout which is drastically different from 11i. This feature brings in a new gamut of…
I always followed all Oracle OpenWorld happenings through blogs, but this is the first OpenWorld that I physically attended. The blog post from Michael Abbey on tips for OOW first timers was a godsend for me. This helped me to navigate OOW like a pro. This is what I checked out..
Oracle hosted a webcast of Sysadmin-oriented Preview of EBS 12.2. It was an enlighting webcast, which gave a very good idea about things coming up in Release 12.2. Today I want to discuss about a prominent feature of the upcoming Oracle E-Business suite Release 12.2, Online patching feature. The screengrab in thiis post of a slide from presentation gives a nice overview of the feature.
If your configuration matches the following setup, then this blog could be helpful to you. Set up: OS: Redhat Enterprise Linux 3 or 4, JDK: Sun Java 1.3 or 1.4, Apps: 11.5.9 or 11.5.10, Users: many Oracle Self Service Web Applications Users e.g., iProc, iRec, Timecard, and HR self-service With this setup, you might have already faced issues like the Apps login page not responding, or browsers timing out in loading SSWA pages. You might have raised numerous long-running TARs with Oracle support on this and ended up uploading lot of Apache and Jserv debug logs, and you always end up recycling or bouncing the Apache service to fix the issue. Don’t worry—you are not alone here.
As an Apps DBA, you might have been asked to clear the JSP cache many times, either by Developers or Oracle Support. The usual directory that holds the JSP cache is $COMMON_TOP/_pages in 11i and R12 releases. In older versions of 11i it used to be $OA_HTML/_pages. What is this JSP Cache? It’s the compiled version of JSP files. When JSP gets compiled by Apache Jserv, it gets internally gets converted into a .java file (servlet) and then that .java file gets compiled into a .class file Why do we need to clear the JSP cache?
Recently, an Oracle-L discussion on Sun T2000 servers got me thinking. The T2000 servers have Sun’s new line of processors, UltraSPARC-T1. These processors come with 8 physical cores, and each core has 4 threads (similar to hyperthreading in Intel Xeon Processors). So each UltraSPARC-T1 processor shows up as 32 Processors (8 cores * 4 threads) at the operating system (OS) level. Sun termed this technology “Cool Threads”. It is supposed to give high-volume throughput along with saving millions on power and cooling costs. But many discussion forums have more complaints against these T2000 servers than praises.
Anybody who has tried this multi-node to single-node cloning in 11i knows that it’s difficult and very error-prone. If we outline the Apps Tier cloning process, it looks like this (supposing we have a two-node instance with the DB and CM on one node, and Web and Forms on the other): This process is called merging appltops. It’s not as easy as it looks. Many times, the production environment might not have proper values in the fnd_nodes table, which makes adcfgclone.pl fail to properly recognize the appltops for merging. But in R12, life is made easy. Let me show you.
One of the main goals in architecting a Disaster Recovery (DR) solution is to make a DR failover transparent to the end users. Too often, users must reboot their desktops, clear their browser cache and the jinitiator jar cache, and so on, even when we have made sure that the post-failover URL of the 11i instance is the same. After a failover of an 11i instance from a primary site to a DR site, if the user can operate without changing anything in his desktop, only then can we say that the goal is achieved.
If you are a early adopter of R12 with a version earlier than 12.0.3, its time to patch up to 12.0.3 or 12.0.4. and migrate to the Linux 64-bit platform. This migration to Linux 64-bit should not be a big hassle, as it is binary-compatible with Linux 32-bit. I expect it be as simple as 1) copy, 2) relink, and 3) startup. I will, however, find out the exact method, and post here in the blog.
From my previous post on TXK rollup patch, you already know the significance of adctxinf.tmp file in $AD_TOP/admin/template directory. It has wealth of information about different XML tags in the Context XML file of an Apps 11i instance. In relation to the same file, now I want to share with you all a small XSL (XML style sheet) file I wrote back in 2005. It makes adctxinf.tmp much more readable; all tags are presented in a tabular format in the browser.