Posts by Vasu Balla
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.
The 11i TXK AutoConfig and Templates Rollup Patch S (6372396) was released on May 5th. This patch differs from traditional TXK autoconfig template patch releases in that the ATG team decided to include some other important TXK patches also with this release. One of these is TXK Advanced Utilities Rollup Patch C (5011249). As a side effect of this generous inclusion of import updates, the patch size has increased from 16mb (RUP R) to 65mb (RUP S).
I ran into an 11i E-Business Suite instance which is using Apache/JServ to do forms load-balancing. Here is quick sketch of the instance architecture, a brief overview on how forms load-balancing happens in above architecture, and me more technical details — basically, the XML tags in the Context XML file in APPL_TOP that need to be edited.
It is quite common for Oracle Tech support, while troubleshooting any 11i E-Business Suite Self Service Applications (SSWA) related error messages, to ask to enable debug logging in JServ configuration files. The procedure we followed here saved us a complete bounce of Apache, but unfortunately, for changes in jserv.conf to take effect, we still need a complete Apache bounce. This trick will only work for files jserv.properties, forms.properties, viewer4i.properties, and xmlsvcs.properties.
My name is Vasu Balla, and I’ve been with Pythian for about four months now. I have worked on Oracle E-Business Suite instances for over five years, and I’ve never had a moment where I felt bored. I am constantly challenged with new technologies and new issues, and my Pythian team’s clients continue to present interesting issues. Our team recently encountered an issue a client had had with Oracle Configurator for two years. They had followed up with Oracle Tech Support for over a year and had eventually learned just to live with the problem. When Pythian came in, we were shocked to learn the history of the problem. It turned out to be one of the most exciting problems we’ve resolved.