Installing EBS 11.5.10.2 Vision? Quick list of useful links.

My EBS 11i Vision VM bit the dust recently, and I found myself needing to reinstall. I know, yes, backups. I know, okay? I KNOW. I know. *whimper*

Anyhow, time to party like it's mid-2005! This isn't going to be as super-long as my R12 Vision install series (which is now an eBook that you should totally buy). Instead, it's a quick list of links to help you get started on something you'll hopefully only need to do once, if ever. At least I now have public notes in case, heaven forfend, I need to do this again myself. Please note that these links are biased toward an installation on Oracle Enterprise Linux 5, because that's the 32-bit Linux media I had closest to hand. There are a few quirks when installing on OEL5, but thankfully they're all well-documented.

Start with the basics

Installing Oracle Applications: A Guide to Using Rapid Install Release 11i (11.5.10.2)
Just in case you need a refresher on system resource requirements and various other setup bits.
Note 316803.1: Oracle Applications Release Notes, Release 11i (11.5.10.2)
Not a lot of meat here, but it does provide a reference to the most recent Rapid Install/"startCD" patch, in the unlikely event that it changes. Don't hold your breath; the product's in Extended Support, and the release notes document hasn't been updated in 2 years.
Note 316806.1: Oracle Applications Installation Update Notes, Release 11i (11.5.10.2)
Here's the really useful stuff, listing required kernel versions, OS packages, and special instructions for various OS releases. The information in this note gets you 95% of what's needed to do the install. Make sure to apply patches 6365595 and 6078836, to avoid errors on "afmkinit.sh INSTE8_SETUP 127" and "libdb.so.3: cannot open shared object file," respectively.
Most recent Rapid Install patch
Why go digging through the release notes for the patch number?
Note 316843.1: MD5 Checksums for 11i10.2 Rapid Install Media
Just in case you think your old disk-based staging area may be suspect, and you're wondering if you need to go back to the install DVDs. You know, theoretically.

OEL5-specific stuff

Setup for Oracle's public YUM server
You might need this setup to download additional packages, if you don't want to search your install media.
Oracle Open-source "compatibility" project
This is where to grab the additional required RPMs listed in note 316806.1. If you're wondering where to find binutils 2.15, it's in compat-binutils215-2.15.92.0.2-24.i386.rpm.
Note 730444.1: Oracle Applications 11i Installation on OEL5 or RHEL5
This note provides solutions to a pair of quirks related to installation on OEL5.
Note 451994.1: Unable to Find 'kshell' in Path When Running adcfgclone.pl
Rather than chasing down and installing pdksh, as suggested in Note 730444.1, I found that a simple export KSH_VERSION='@(#)PD KSH v5.2.14 99/07/13.2', as suggested in this note, to be sufficient to satisfy the installer's requirements.
Note 747424.1: Installation of 11.5.10.2 On OEL Fails
To avoid an interruption in the installation process, use the steps described in this note (replacing LD_ASSUME_KERNEL in adgetlnxver.sh) before running the zip commands described in the pre-installation tasks for patch 6365595 in Note 316806.1. Depending on your version of OEL, this may not be necessary, but why risk it?

Thanks for joining me on this trip down memory lane. Please return your Wayback Machines, Deloreans, and telephone booths to their assigned places. Be excellent to each other.

EBS R12 Vision Install Guide is now an eBook (for Kate)

Chet and Jake have both already covered this topic, but please allow me the small conceit that someone out there might read about it here first. :) About a year ago, I wrote a series of guest posts for the ORACLENERD blog about installing a Vision instance of Oracle E-Business Suite Release 12. It proved to be inexplicably popular, and even spawned something Chet called the EBS Challenge, so Chet and I have bundled the whole series together into a PDF document that flows a bit better than a handful of posts spread over two blogs. Same quirky style, same nigh-endless stack of highly informative screenshots, but way less clicking, and you can take it with you!

Donationware

I was initially resistant to asking people to pay for content that I'd already made available for free, even considering the value-add of content restructuring and packaging. When we considered a charitable angle, though, I was all in. If you're a regular reader of Chet's blog, you'll know that one of the primary passions in his life is his daughter, Kate, who has been diagnosed with PDD-NOS. All proceeds from sales of the eBook, after Paypal takes their cut, will be directed to defraying the costs of Kate's care.

If you're interested in building your very own R12 E-Business Suite playground, I hope you'll consider picking up a copy of the PDF version of the guide. If you're one of the thousands (that's still a bit mind-boggling) of people who have already read the guide on Chet's blog, and if you derived some value from the experience, I hope you'll consider buying a copy to show your appreciation. Heck, buy a copy for everyone in your office! Think of it as an opportunity to make a direct contribution to making life easier for Kate and her parents. You even get a chance to "try before you buy;" all the content in the eBook is already available for you to review on our blogs. I probably left in the same embarrassing typos and bad grammar. You can't lose, and if you buy, Kate wins.

Finding debug and trace profiles in EBS

It happens all too often in E-Business Suite systems, especially in test and development. Someone sets a profile option to gather trace information for an SR, or to debug a pesky series of forms. They follow the instructions in the relevant My Oracle Support note to the letter, but in the ensuing rush to ship the trace info to the support analyst or to dive into the debug files, they forget to disable the profile option that produces all of that lovely verbose output.

Time passes. Then the email starts to come in.

From your systems administrators:

"Hey, any idea why /opt is at 95% on the dev database server?"

"Dude, why are there several thousand .dbg files in /var/tmp?"

From that one extra-special user who remembers that you like detail in your problem statements, and whose only noticeable flaw is a reluctance to be cloned:

"I've noticed that when I try to do anything at all in Order Management on the test system, it's really dragging. Other parts of the system seem fine, though. Could you check if anything weird is happening with the three forms shown in the attached screenshots?"

From the Service Desk:

"We have lots of people complaining that E-Business Suite is slow. Have you guys changed anything?"

After a long afternoon of looking around, you learn that:

  • /var/tmp is full of debug files from a concurrent request that runs every 10 minutes
  • /opt is filling up because someone (hey, don't snicker, maybe it was you. We've all been there) decided to set the "Initialization SQL Statement - Custom" profile for your most active user to perform a 10046 database event trace. At level 12. Without restricting by application or responsibility.
  • Thankfully, Order Management debug settings mostly affect only the Order Management module. Unfortunately, when they're not also restricted by user, everyone suffers.
  • Most of the other users complaining about slow E-Business Suite performance aren't even using the instance where the above problems arose. They're just struggling with old desktop machines, trying to keep 20 Forms windows open at once, or failing to resist adding one more really cute widget to their browser toolbar. Hey, not every E-Business Suite performance problem starts on the server side. ;)

All is well again, but it took forever to track down all of those different settings. Wouldn't it be nice if there was a quick way to find debug-related system profile options that had been set recently (or not-so-recently)? You could use a script like this, but that might be a bit too noisy if there are frequent profile option changes.

Here's a script that I use to try to capture as many of the debug and trace profile settings as possible. It's based on the query that I just linked, but filters on some common strings so you're more likely to get results that are relevant to identifying errant debug settings. It also attempts to ignore options that have been set as defaults at install or patch time. I'm not too proud of the multiple scalar subqueries inside the decode() statement. Clearly I stopped somewhere between "okay, it works" and "let me polish this 'til it gleams." :)

Oh, and I'm toying with the idea of dropping my various scripts and snippets into Teh Cloud™ at GitHub. I don't claim to be organized enough to rate a repository, but I think the idea of gists is pretty nifty.

-- check_ebs_trace_profs.sql
-- Author: John Piwowar
-- Purpose: Identify E-Business Suite system profile option settings that may
-- be related to performance-degrading debug/trace activity
-- Notes: Prompts for a cutoff date for when profile options were set
-- May need additional tweaking for multi-language installations
set pagesize 9999
set linesize 120
set verify off
col "Profile Option" for a25
col "Option Level" for a13
col "set for" for a20
col "Value" for a20
col "Set On" for a11
col "Blame" for a20
PROMPT Enter date value in form DD-MON-YYYY for check_since
   select tl.user_profile_option_name "Profile Option"
        , decode( val.level_id
                , 10001, 'Site'
                , 10002, 'Application'
                , 10003, 'Responsibility'
                , 10004, 'User'
                , 10005, 'Server'
                , 10006, 'Organization'
                , 10007, 'Server+Resp'
                , 'No idea, boss') "Option Level"
        , decode( val.level_id
                , 10001
                , 'EVERYWHERE!'
                , 10002
                , (select application_name
                     from fnd_application_tl
                    where application_id = val.level_value)
                , 10003
                , (select responsibility_name
                     from fnd_responsibility_tl
                    where responsibility_id = val.level_value
                      and application_id = val.level_value_application_id)
                , 10004
                , (select user_name
                     from fnd_user
                    where user_id = val.level_value)
                , 10005
                , (select host || '.' || domain
                     from fnd_nodes
                    where node_id = val.level_value)
                , 10006
                , (select name
                     from hr_all_organization_units
                    where organization_id = val.level_value)
                , 10007
                , 'Look it up' --per specification El-Ay-Zed-why
                , '''Tis a mystery') "Set for"
        , val.profile_option_value "Value"
        , val.last_update_date "Set on"
        , usr.user_name "Set By"
     from fnd_profile_options opt,
          fnd_profile_option_values val,
          fnd_profile_options_tl tl,
          fnd_user usr
    where opt.profile_option_id = val.profile_option_id
      and opt.profile_option_name = tl.profile_option_name
      and regexp_like( tl.user_profile_option_name
                     , '(trace|log|debug|audit|diag|sql)'
                     , 'i'
                     )
      and not(regexp_like( tl.user_profile_option_name
                         , '(catalog|file|login|utilities)'
                         , 'i'
                         )
             )
      and usr.user_id = val.last_updated_by
      and usr.user_name not in ( 'AUTOINSTALL'
                                , 'INITIAL SETUP'
                                , 'ANONYMOUS')
      and val.last_update_date > '&check_since'
    order by val.last_update_date desc
;

Grid Control follies: Looking for perl? Oh, it’s over there, in the perlBin.

Long time since I talked about Grid Control, but this one was weird enough to share. Hostnames and installation paths obfuscated as usual.

After a recent reconfiguration exercise for an Oracle 11g Grid Control agent, all targets monitored by the agent were showing "unknown" status, agent metrics were unavailable, and the performance page host target itself was throwing strange (to me, anyway) "No such metric, Switching to last 24 hours view" errors.

A quick look at the emagent.trc file in $ORACLE_HOME/sysman/log showed a lot of errors of the following form, for every monitored target on the system:

2010-12-03 21:50:35,716 Thread-3027233680 ERROR engine: [oracle_emd,server.domain:1830,ProcessInfo] :
 nmeegd_GetMetricData failed : Missing Properties : [perlBin]

perlBin? That's a new one for me. None of the recent work on the agent configuration had touched the perl installation, and lightweight command-line testing of the perl installed in the ORACLE_HOME didn't reveal any problems. That meant it was time to start digging in $ORACLE_HOME/sysman/config, where there are lots of files with .properties extensions. For once, the most obvious place to look turned out to be the right place.

The culprit? Oh, just one little character in the emd.properties file:

/perlBin=ORACLE_AGENT_HOME/perl/bin

Change /perlBin to perlBin, restart the agent, and all of a sudden everything looks way more sane. Whew. How that wayward / got to be there in the first place is a mystery that can wait for another day. Probably my fault; it often is. :)

“No manager available?” Say what, EBS?

Here's a quick note for those of you running Oracle E-Business Suite 11.5.10.2 in a non-PCP RAC environment. It may be an edge case, but perhaps it'll help someone else out there.

I'd received a report from a member of our development team that certain transaction managers in our E-Business Suite 11.5.10.2 test system were "broken"...but only intermittently. Don't you just love that? Actions in the Forms interface that would submit a request to a transaction manager as 'immediate' requests would return the message, "No concurrent manager is defined to process this request." This problem could persist for most of a day, only affect one developer, disappear for several days, then return and plague the entire team for a week. During that time, other concurrent managers were functioning as expected, and there weren't any obvious performance problems causing concurrent managers to become unresponsive. When tracing a Forms session shown to trigger the error, we saw the following query appear in the trace file right before the "No manager defined" error was thrown:

SELECT /*+ ORDERED USE_NL (fa fcp fr fcpp fcq) INDEX (fcq,FND_CONCURRENT_QUEUES_N1)
INDEX (fcpp,FND_CONC_PROCESSOR_PROGRAMS_U2) */
FCQ.CONCURRENT_QUEUE_ID
FROM FND_APPLICATION FA, FND_CONCURRENT_PROGRAMS FCP, FND_CONC_PROCESSOR_PROGRAMS FCPP, FND_RESPONSIBILITY FR, FND_CONCURRENT_QUEUES FCQ, FND_CONCURRENT_PROCESSES FCPR
WHERE FCQ.PROCESSOR_APPLICATION_ID = FCPP.PROCESSOR_APPLICATION_ID
AND FCQ.CONCURRENT_PROCESSOR_ID = FCPP.CONCURRENT_PROCESSOR_ID
AND FCPP.CONCURRENT_PROGRAM_ID = FCP.CONCURRENT_PROGRAM_ID
AND FCPP.PROGRAM_APPLICATION_ID = FCP.APPLICATION_ID
AND FCP.APPLICATION_ID = FA.APPLICATION_ID
AND FA.APPLICATION_SHORT_NAME = 'xx'
AND FCP.CONCURRENT_PROGRAM_NAME = 'yyyyy'
AND FR.RESPONSIBILITY_ID = nnnnn
AND FR.APPLICATION_ID = nnn
AND FR.DATA_GROUP_ID = FCQ.DATA_GROUP_ID
AND FCQ.MANAGER_TYPE = '3'
AND FCPR.CONCURRENT_QUEUE_ID = FCQ.CONCURRENT_QUEUE_ID
AND FCPR.QUEUE_APPLICATION_ID = FCQ.APPLICATION_ID
AND FCPR.PROCESS_STATUS_CODE = 'A'
AND FCPR.INSTANCE_NUMBER = USERENV('instance') ORDER BY DBMS_RANDOM.RANDOM

This query would return zero rows, and cause EBS to report "No manager available," even though we'd verified before running the test that the required transaction manager was running and successfully processing requests from other sources.

But wait. See that bit right there, where it checks USERENV('instance')? Yeah, it made me think, too.

So what was going on?

The previous query shows that the code submitting the concurrent request was not just checking for a running transaction manager, but for a manager that was running on the same database instance as the user's current session. Since we were running in a RAC environment, it was entirely possible for the transaction manager process and the user's Forms session to be connected to different database nodes. If the CM and Forms sessions were both connected to RAC node 1, or both to RAC node 2, everything worked fine. But if the CM process were running on node 1 and the Forms session connected to node 2, or vice versa, things blew up.

Why did the transaction managers care which RAC node we were using when we submitted a request? The "old way" of running EBS transaction managers in a RAC environment required the use of DBMS_PIPE, which meant that there needed to be a transaction manager assigned to each RAC node. This is the default behavior for EBS 11i. In Release 12, the default is to use Advanced Queueing (AQ) for transaction managers, so the need for a 1:1 mapping between managers and RAC nodes is eliminated. Up-to-date versions of the ATG Family Pack also allow the use of queues for transaction managers in 11i. This behavior is controlled by setting the EBS system profile option "Concurrent: TM Transport Type," which takes the value PIPE or QUEUE.

This is not new information. The instructions for setting the "Concurrent: TM Transport Type" profile option in an EBS RAC environment are very clearly stated...but only in the context of configuring Parallel Concurrent Processing (PCP). Since we were running on a single applications tier at the time, it was decided not to configure PCP until we had deployed a second apps node. We therefore did not address the TM Transport Type profile option. Once we changed the option from PIPE to QUEUE in our single-app-node, 2-db-node environment, the problems reported by the developers were resolved.

So there you go. "Concurrent: TM Transport Type=QUEUE" -- it's not just for PCP anymore. Hey, that would've made a catchy post title!

References

Note 458453.1: What is the difference between PIPE and QUEUE for profile Concurrent:TM Transport Type ? (pay particular attention to the required init.ora adjustments; they vary depending on RDBMS release)
Note 240818.1: Concurrent Processing: Transaction Manager Setup and Configuration Requirement in an 11i RAC Environment
Note 1057802.1: Best Practices for Performance for Concurrent Managers in E-Business Suite
Note 823586.1: Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 11i (or whichever note is appropriate for your database release)

E-Business Suite cloning: Disabling auto-start of applications

A little while ago, Yury Velikanov at Pythian blogged about a new feature in the RapidClone tool for EBS 12.1.2. In summary, Apps DBAs finally have the option to disable the startup of application services after cloning is complete. As Yury notes, this is big help, because there's often a long list of post-clone activities to perform prior to releasing a cloned system to users, many of which are best performed before starting the cloned system for the first time.

If you're not on 12.1.2, and would still like to accomplish this feat, it's pretty straightforward, as long as you're comfortable with editing the adcfgclone.pl script in $COMMON_TOP/clone/bin. It's easy and painless, honest! Just locate and comment out the line that executes adstrtal.sh. If you'd rather not do this manually with your favorite editor, here are two perl one-liners that will do the work for you, and preserve the original version of the script for reference:

For Release 11i:
perl -pi.old -e 's/(system.*adstr)/#$1/' adcfgclone.pl

For Release 12:
perl -pi.old -e 's/(runPipedCmd.*adstr)/#$1/' adcfgclone.pl

Depending on your EBS version and AD patch level, the line you're looking for may be slightly different. As with anything else I write about here, if you're foolish enough to follow along, at least do yourself the favor of testing things first.

On that note, it's occurred to me that the functionality Yury discusses in his blog post may be available in earlier EBS versions than 12.1.2, provided you're running a very recent AD Minipack. I'd welcome your comments confirming or disproving this theory, since I'm too lazy at the moment to dig through release notes on My Oracle Support to check. :-)

Oracle OpenWorld 2010 recap: Time to get ready for that Fusion Apps upgrade?

One of the big announcements to come out of Oracle OpenWorld 2010 was the general availability timeframe (not, you'll note, a date) of the long-anticipated Fusion Applications ("coming soon, since 2006!"). The demogrounds were full of people test-driving Fusion Apps; there are tons of new features and a highly improved user experience. Now that we all know it's for real, it's time to ask for a new set of upgrade boots for Christmas, because when Q1 2011 arrives, it's going to be time to download the software, pore through the fresh, pixels-still-wet documentation, and plan for a transformative experience!

Yeah, okay, maybe not.

Whaddya mean, "maybe not?"

Please note: despite my tone above, Fusion Apps look pretty awesome, and really are a big deal. There's no doubt about that. But Oracle is definitely promoting a "dip your toes in the water, don't dive" approach to the implementation of Fusion. Why? Let's start with the obvious: Fusion Apps, despite all the love and care that went into its development, is version 1.0 software. It incorporates the best-of-breed features from all of the applications platforms; it's not a re-skin of E-Business Suite (or PeopleSoft, or JD Edwards) with Frankensteinian bolt-ons from other Applications products. As such, no matter how much testing is done, no matter how hard the early adopter customers beat on their 1.0 and pre-1.0 releases, there are going to be bugs. Possibly big ones, possibly small ones that turn out to be big for the way you do business. If you don't have a relatively strong need for particular features, or a high tolerance for the *ahem* thrilling rush of excitement that comes with the early-adopter experience, you might want to sit out version 1.0 and let the big dogs hammer out some of the still-to-be-discovered issues.

It may also be that version 1.0 of Fusion Apps doesn't cover all of the features that you need to run your business, or even have a corresponding module that maps to that small-but-critical applications product that keeps the lights on in your organization. This is one of the main drivers behind Oracle's "co-existence" strategy for its applications products. They want you to be able to implement pieces of Fusion Apps as it makes sense for your business, and not have to "leave behind" functionality that isn't quite ready yet on the new platform.

Those are two reasons that Fusion Apps may not be ready for you. It's also worth considering that you may not be ready for them. There are technology components in play in the Fusion Apps tech stack (Fusion middleware, or FMW) that are still relatively new on the scene, and it will take time to adjust to using them for reporting, development, business process modeling, and general systems maintenance and administration. If you're not currently using FMW components in your organization, it may make sense to start easing them into your infrastructure before also taking on Fusion Apps. A bit more on that below.

Planning for an "big-bang" upgrade or re-implementation?

If there isn't a one-to-one mapping of features between your current applications deployment, you aren't stuck. In fact, you probably shouldn't plan for a monolithic upgrade. As noted above, and in just about every piece that Oracle writes on the topic of Fusion Apps, it's possible, and generally recommended, to take an approach that results in Fusion Apps and your existing "Applications Unlimited" products existing side-by-side. For example, you could elect to upgrade Financials to Fusion Apps, and wait for Manufacturing components to mature to the point where you feel comfortable taking that upgrade (Note: That's just an example, not an implied judgement of the quality of either product suite. Remember, I'm an Apps DBA, and not particularly qualified to judge the maturity of products from a functional perspective). The impression that I got is that full one-shot moves to Fusion Apps, whether through re-implementation or upgrade, are going to be exceedingly rare.

There are downsides to this approach, of course. Without (or perhaps even in spite of) careful planning, a split configuration is all but guaranteed to involve a broader footprint of installed software: different middle-tier and database software installations, along with multiple databases, to support the deployment Applications Unlimited and Fusion Applications. Hat tip to Floyd Teter for pointing this out to me after one of his presentations, thereby confirming a nagging suspicion. This has implications for the size and complexity of test and development systems as well; I look forward to reviewing the inevitable white papers that address ways to ameliorate these architectural issues.

Fine, then, what do we do instead?

A major theme of the discussion around Fusion Apps at OpenWorld was "Upgrade, Adapt, Extend." Nadia Bendjedou's "10 Things you can do today to prepare for Fusion Applications" presentation goes through this in detail, but here are the high points:

Upgrade: not what you might think. This is "Upgrade" as in, "Upgrade to the latest release of your current Applications Unlimited platform"

Adapt: This was the meat of Nadia's "10 Things" talk, and elements were reinforced throughout other sessions I attended. The idea is that once you're on the most recent version of your current applications platform, you can take advantage of the various components that underpin Fusion Applications, before implementing Fusion Apps themselves. Examples include: BI Publisher, OBIEE, BPEL, SOA (everyone's favorite), WebCenter, Secure Enterprise Search, and UPK. Furthermore, "Adapt" includes taking advantage of new functionality in the more recent releases to eliminate customizations, or convert them to configurations that are more likely to survive an upgrade. The phrases "upgrade-safe" and "future-proof" were tossed around at the conference, but I try to maintain some level of healthy skepticism. ;-)

Extend: This doesn't imply extending applications functionality with external components, but rather extending your applications deployment into Fusion Applications. Find the areas of your business that are ready for and can benefit from Fusion, and take up those portions as it makes sense to do so. Ideally, this comes at a time after your DBAs and app server admins are familiar with supporting the FMW tech stack, your developers are up to speed on Jdeveloper and the latest development frameworks for Apps, you're managing your business process flows with BPEL instead of Workflow, and your business intelligence architects are cranking out BI Publisher reports and OBIEE dashboards like they've been doing it for years.

The big message, then, is: don't sit still. Get to the most recent version of your current applications system, get comfortable with the new functionality and technology components, see what problems they fix for you, and then start looking at Fusion for the problems that it doesn't fix.

What about EBS 11.5.10 customers?

Now that Fusion Apps are genuinely on the horizon, it may be tempting for E-Business Suite customers that are on 11.5.10 to try to ride out the extended and sustaining product support cycles, and make a big jump to Fusion once the dust settles a bit from the initial release. As implied above, though, monolithic upgrades aren't being encouraged, and there are benefits to getting on the more recent version of EBS (some of which I covered earlier). Oracle is strongly recommending that E-Business Suite 11.5.10 customer get to R12 as soon as they can. Furthermore, as Floyd Teter points out, Oracle is has committed to an upgrade path from 11.5.10 to version 1.0 of Fusion, but they haven't made a commitment for anything beyond that (second time I'm linking him in one post, but hey, Floyd's a smart dude. I listen to Floyd). We've already talked about the potential pain of a jump to 1.0. Do you want to inflict that level of change on your organization, from techstack to data model to end-user experience? Sounds like a recipe for massive levels of discontent to me.

So, bottom line: If you're an EBS 11.5.10 customer and thinking about jumping directly to Fusion Apps, rethink that strategy. You have more to gain by upgrading to R12, building organizational competencies with the more modern technical components, and taking up Fusion Apps as the benefit to your business becomes clear. Naturally, this advice also applies to Peoplesoft, JD Edwards, and Siebel customers; I'm just not up-to-date on the versions numbers in the lifecycles of those products. :-)

But I really want to kick the tires on this stuff! I have pain! I think Fusion Apps is the cure!

Well, that's a topic for discussion between you and your Oracle reps; I'm just one blogger trying to synthesize notes from a week's worth of sessions and informal discussion. :-) Obviously, Oracle has an Early Adopter program for Fusion Apps, if you think you're a viable candidate. I also learned that Oracle has "assessment workshop" teams: groups of functional experts that can come onsite to evaluate your fitness/readiness for Fusion Apps. I didn't scribble down the reference quickly enough, but I'll try to dig up a link and post it here.

Okay, I think I've repeated myself enough here. On to the next post!

Openworld 2010: Gratitude

Oracle OpenWorld may be a technology conference, but the people make the week. Otherwise, one might as well stay home to watch webcasts and flip through slide decks. Before I start generating my requisite nerdy recap content, I want to get started on the right foot: thanking the people that made the trek worthwhile. I worry a bit about my tone, since it's easy for public thank-you's to be misinterpreted as self-indulgent name-checking; I guess I'll just have to ask you to trust my sincerity. :)

In no particular order, thanks to...

... the marketing and communications team at Oracle, for the opportunity to attend on a blogger pass, and providing access to the press area for a quiet area to work and escape the hordes of people.

... the OTN team (Justin {blog | twitter}, Vicky, and Lillian in particular), for making me and so many others in the online community feel welcome.

... Pythian, for the fun bloggers' meetup: Alex Gorbachev {blog | twitter} for spearheading, Vanessa Simmons  for behind-the-scenes cat-herding, and Paul Vallee {blog | twitter} for sponsoring.

... Mogens Nørgaard {blog | twitter} for organizing OCW, and to the attendees for not remarking on the precipitous drop in average IQ when I slipped in to catch a few sessions.

... Floyd Teter {blog | twitter}, for dispensing wisdom, interesting stories, and lunch, and for treating me like we'd met before, even though we hadn't.

... Steven Chan, for covering enough information in his Sunday SIG session that I could sleep in a bit on Wednesday, and for clarifying some outstanding questions for me.

... all the people who bought me beer: Ronald  {blog | twitter}, Floyd, Chet  {blog | twitter}, Jake  {blog | twitter}, Dan  {blog | twitter}, Terrance, and others I may have (shamefully) forgotten. I somehow managed to go the entire show without paying for a beer, which is a bit like winning the lottery, even if (as Jake and Chet pointed out once or twice) I wasn't exactly a heavy contributor to the size of the tab.

... Chet, for housing assistance and for making the week far more entertaining than it would have otherwise been, and for knowing how to give and receive abuse in equal measure. ;)

... Jake, for so much stuff: food, beer, introductions, interesting conversation, taxi service. I could be more effusive, but he'd probably tell me to shut up. ;-)

Y'all are awesome. Thanks again!

OOW10 Day 2 mid-day update: Interesting new EBS techstack functionality

The draft of my Day 1 post is not quite complete, but I want to post this before my thoughts from the recent "EBS Vision, Strategy and Roadmap" session fade into an under-caffeinated haze. OpenWorld is a bit draining; I can only assume I will be a husk of my former self by Thursday evening.

The session covered a lot of information at a pretty high level, including information that is already familiar to people that have already migrated to R12. That's not suggesting that the content was not useful; about 67-75% of the very large room indicated by show of hands that they were still running on Oracle Applications 11i, and a significantly smaller percentage indicated that that they were in the middle of an R12 upgrade. The following points really stood out for me, though:

  1. Support for using Active Data Guard for an E-Business Suite reporting instance. The core challenge in using Active Data Guard and E-Business Suite is that you can't write to an Active Data Guard database, and the simple act of authenticating to E-Business Suite requires writing to the Oracle Applications tables. The Applications Technology Group has devised a way to get around (or perhaps more accurately, work with) this limitation, and have begun an early-adopter program for interested customers. Two important restrictions to note are:
    • The functionality is being made available as a patch on version 12.1.3 of Oracle Apps, so you'll need to be pretty current with your tech stack
    • This will only work for "read only" reports, though Oracle can also provide a method to identify which reports can be run against an Active Data Guard database instance.
  2. Lightweight multilingual support, a feature new to version 12.1.3, allows Apps users to perform general data processing (data entry, reporting, etc) in multiple languages without delivering the full applications UI in those languages. This has the advantage of reducing the patching/maintenance burden on Apps DBAs, and that's never a bad thing. :) It was noted in the presentation that traditional full multi-language implementations can coexist with additional "lightweight" language implementations, and that it's possible to migrate lightweight versions to full language implementations.
  3. Use of a staged APPL_TOP for upgrades from 11i to R12. This topic was actually covered by Robert Farrington on Steven Chan's blog last week, but it's worth calling out again. This feature has the potential to save a lot of time during an R12 upgrade; particularly when you consider that an R12 upgrade these days often will require applying a patchset atop the based release, with the accompanying rebuild of a staggering number of forms and reports.
  4. Finally, a "future release" of E-Business Suite (presumably 12.2) will include support for Edition-Based Redefinition. I had a slightly rambling blog post about this possibility earlier this year, and it's apparently going to become a reality. If you're interested in the possibility of near-zero-downtime EBS patching, now's the time to upgrade your database to 11gR2. Or you could wait until EBS Release 12.2 ships and upgrade both at once, but who needs that kind of stress?

As with all really cool Oracle Applications technical news, you'll undoubtedly find more cogent discussion on Steven Chan's blog in the coming days/weeks as the dust settles from Oracle OpenWorld. I'm just calling attention to these topics for people who might be interested, so you know to watch for more information.

Christmas comes early: SQL Developer Data Modeler now free(r)!

The week that encompasses Oracle OpenWorld is a bit like a holiday season for ORACLENERDs: new toys (product announcements, long awaited product updates, exhibitor tchotchkes), mingling with far-flung "family" and friends, and of course unhealthy amounts of food and drink that will take months of exercise to counterbalance.

Today, two days before the official start of the conference, we got an early gift: SQL Developer Overlord Kris Rice (@krisrice) and OTN Grand Admiral Justin Kestelyn (@oracletechnet) tweeted the following:

201009171826.jpg
201009171824.jpg

That's kind of a big deal. The Data Modeler add-on for Oracle SQL Developer is a great tool, but the licensing fee for the full product -- there's always been a free read-only version -- has been cited by some as pretty steep. No longer! The OTN content related to Data Modeler is still being revised, but it no longer appears on the Oracle price list (PDF warning on that link), and Kris Rice graciously followed up with a clarifying tweet expanding on Justin's "...free for Oracle Database customers":

201009171847.jpg

So there you go. If you have licenses for Oracle RDBMS software, then SQL Developer Data Modeler is all yours. There's a risk that this news might get lost in the flood of other stuff that's coming out of OpenWorld this week, since tweets from the Ace Directors briefing can best be summarized as "OMG U GUYS 2 BAD WE'RE UNDER NDA TIL SUNDAY WOW!!1!one!" If you or your team have need of a data modeling tool, but have been put off by the pricing of some of the big players (I know I have, given how infrequently I need to use one), this is definitely worth a look, and Oracle just removed your last excuse to give it a try.

Kudos to Oracle for getting this done!