Wednesday, June 13, 2012

URGENT BULLETIN: Disable JRE Auto-Update for All E-Business Suite End-Users

This notice just came out on Steven Chan's blog. If you're not following it, you definitely should.

The issue at hand is not that Auto-Update in itself causes problems. The real issue is that Oracle is going to push (through Auto-Update) the JRE 1.7 update. The JRE 1.7 update is NOT certified with E-Business Suite (any versions) at this time.

So, in order to keep your user's desktops on JRE 1.6, you MUST turn this auto-update feature off!

The update for JRE 1.7 could be pushed as early as July 3, 2012. The update WILL definitely be pushed after September 7, 2012 (after the release of JRE 1.6.0_35).

Steven Chan's blog has more information (including instructions on what you can do to undo the JRE 1.7 update if you get hit by it). The full link to the posting on Steven Chan's blog can be found here:


OAUG Connection Point 2012 in Austin, TX (July 11-12, 2012)

OAUG Connection Point 2012 is coming to Austin, TX, July 11-12, 2012! The conference will be held at the Omni Austin Hotel in beautiful downtown Austin, TX.

The keynote will be given by Jeanne Lowell, Vice President, Oracle E-Business Suite Strategy, Oracle Corporation. (Hopefully we can extract some R12.2 news from her!)

Other featured speakers include:

Elke Phelps, Senior Principal Product Manager, Oracle E-Business Suite Applications Technology, Oracle Corporation. (Elke always gives interesting and informative presentations!)

David Bowin III, Oracle Fusion Applications Product Development, Oracle Corporation

Amrita Mehok, Senior Director, Product Strategy, Oracle Corporation

Some other names you may recgonize will be presenting as well:

Alyssa Johnson, ROLTA (Sessions # 10913 and 10933)
Anne Carlson, Oracle (Session # 10868)
Art Dowd, O2Works (Session # 10829)
Barbara Matthews (Session # 10925)
Bill Dunham, OATC, Inc. (Session # 10915)
John Stouffer (Session # 10880 and 10924)
Michael Barone, OATC, Inc (Session # 10905 and 10907)
Mike Swing, TruTek (Session # 10878)
Susan Behn, Infosemantics, Inc. (Session # 10821)
...and many more!

Oh, and I'll be there too! I'm giving my "Anatomy of an Upgrade to 12.1.3 (including Platform Migration)" presentation (Session # 10802). I'll also be participating in John Stouffer's "R12.1 Upgrade Panel" (Session # 10924) along with Bill Dunham, Mike Swing, and Alyssa Johnson. The panel discussions are always entertaining and provide an excellent way for the community to discuss their challenges and experiences.

"Early Bird" Registration is open through June 24th. Particularly if you're in or near the Austin, TX area, this can be a very cost-effective way to network with the community and find solutions to your problems. More information on the conference is available through the OAUG website or this direct link:

I hope to see you there!


Friday, June 8, 2012

On DBAs, Developers, and Performance

Cary Millsap has an excellent (as usual) blog posting today about the software development process employed by so many oranizations.

You can read his full posting here:

This plays into one thing that I see quite a bit as a DBA at client sites. Most developers that I encounter at client sites don't tend to focus so much on performance (unless it is painful during their testing). This isn't, specifically, their fault. In many cases, the developers are under significant pressure to "make it work" and move onto the next thing. As a result, they don't really have the time to worry about performance. Besides, that's the DBA's job, isn't it?

Well, actually, it isn't. See, here's the thing, from a DBA perspective, we have a relatively small handful of tools at our disposal. From the bottom-up, here is a basic list of things that a DBA generally does to impact the performance of a system:

Properly configure disk and I/O. This is (or should be) really a collaboration between the DBA, the Systems Administrators, and the Storage Administrators. Done correctly, this shouldn't really be a problem. However, as with everything, it is still possible to screw it up. Make sure that you have redundant I/O paths that have sufficient bandwidth for your system. Spread your I/O across many physical drives. With RAID technologies (particularly RAID 1/0) this is VERY easy to accomplish. Forget about the old concept of the DBA moving datafiles around to avoid a "hot disk". The disk array can do this at a much more granular and consistent level than any human possibly can. Your primary goal here should be to have as many spindles involved in every I/O operation as possible.

Properly size your hardware. Another collaboration between the DBA and Systems Administrator. Make sure you have adequate horsepower and RAM. And ALWAYS plan for growth! My general recommendation is always to put more RAM into the box than you think you'll need. Given that so many systems that I encounter these days are x86-based Linux systems (rather than "big iron" like Solaris or AIX), memory for these systems is a relatively small portion of their cost. Also, RAM doesn't impact your Oracle licensing!

Properly tune your OS Kernel and Database parameters. I think that this is one area where developers, managers, and users tend to have gross misconceptions. While it's true that tuning a system to truly "optimal" performance is a dark art, the truth is that, unless you've really screwed something up (sized your SGA too small, too few buffers, etc.), odds are you're not going to see huge performance gains by tweaking these parameters. In most cases, "decent performance" is fairly easy to achieve. Now, squeezing out that extra 20%? That can require in-depth analysis of statistics, utilization, I/O patterns, etc. This is where the "dark art" comes into play. And, honestly, this requires time to observe and adjust.

Unfortunately, too many developers, managers, and even users, seem to wonder why that idiot DBA didn't just set the magic "MAKE_SQL_RUN_FASTER=TRUE" parameter. (Shh! Don't tell anyone, that's OUR little secret!)

The truth is, unless something is wrong at these lower levels, the biggest performance gains are going to come from tuning the code. And, in my opinion, since it's the developer's job to produce a quality product, it's ultimately the developer's job to do tune their code.  Unfortunately, as Cary points out, too many organizations are structured in a manner that breaks the feedback loop required for developers to do this properly.

That MUST be fixed.


Wednesday, June 6, 2012

EBS R12.2 Online Patching Webcast

For those of you who are (like me) anxiously awaiting the release of R12.2, the Applications Technology Group (ATG) is hosting a live webcast to preview the Online Patching feature in R12.2.

Kevin Hudson, one of the lead architects of this particular feature, is the presenter for this webcast.  I had the pleasure of attending Kevin's session at Collaborate 2012 where he discussed this feature in-depth.  He is an excellent presenter and is very well-versed on this topic.  I'm sure this webcast will be worth your time.

This two hour webcast will take place on June 14 @ 8:00am (Pacific Standard Time).

Full details are on Steven Chan's blog at the link below.

ATG Live Webcast June 14: Technical Preview of EBS 12.2 Online Patching

-- James

E-Business Suite and the 32-bit vs. 64-bit question

Before I get flamed on this, I want to make clear that, for the purpose of this posting, I'm speaking specifically about operating systems (not hardware). Most of the hardware being sold today is already 64-bit, however, you can run most 32-bit operating systems on 64-bit hardware. It's that distinction that I'm discussing here.

The first thing that you need to know here is that the big benefit of using a 64-bit operating system really is memory. In particular, it is not about the total amount of memory that can be installed in the machine (that tends to be hardware), but, about the addressable size of "per process" memory.

In the case of components such as those used on an appsTier in EBS, per-process addressable memory doesn't matter so much, as each process has it's own private memory (and isn't depending on "shared memory" like the database server is). So, aside from the fact that it makes our life much easier from an administrative standpoint (and the industry is going that way), there really isn't much of technical advantage to a 64-bit appsTier.
For EBS 11i (where the DB is certified on x86-64, but the appsTier is only certified on x86-32), you can still use much more than 4GB on an appsTier node (the operating system has a way of addressing large memory). It's just that the amount of memory that can be addressed by a single process is limited to something between 3 and 4 GB.

In the case of EBS R12, the appsTier binaries are still 32-bit, even when you're running on a 64-bit operating system. This makes sense because the only component that can really take advantage of it is the database (because the database processes all attach to the same large chunk of memory [the SGA]).

Note that EBS R12 appsTier is certified on both Linux x86-32 and Linux x86-64.

So, for 11i, the best that they can hope for is to have a separate dbTier (database only) running on Linux x86-64 and use Linux x86-32 for their appsTier nodes. Remember, that the 11i appsTier is NOT certified on Linux x86-64. That doesn't mean that it can't be done, but I seriously doubt that Oracle has any intention to certify a release that old on, what is effectively, a different platform. In both cases, they can/should be 5.X (5.7 is current). Having, effectively, two different platforms will be something of a headache from a Linux administration standpoint, but it's something that they'll have to deal with.

When they get to R12, they should use Linux x86-64 on all tiers (to simplify administrative tasks, as well as being "among the mainstream" of installations). Keep in mind that 64-bit is where "the market" is going. Even though you can (It is certified) do R12 on x86-32, you're better positioned if you're on x86-64.