Kevin Kempf's Blog

October 12, 2010

The /dev/null of adpatch?

Filed under: 11i — kkempf @ 1:17 pm
What 6863618?

Staging the Mystery

So I have to admit, up front, that this post is, in fact, a supporting document for a future post about Oracle Patch Wizard.  It seemed necessary to set the stage, so to speak, on existing problems, before I built on that assumption with a whole posting about Patch Wizard.

The gist of this post is that somehow, despite all appearances otherwise, Oracle 11i “forgets” about patches having been applied. Hence the picture here of Tommy Lee Jones from Men in Black.  If you haven’t seen it, or have forgotten, Tommy Lee Jones and Will Smith employ a “forget about it” stick which makes the viewer forget whatever alien thing they just witnessed in the film.    In my mind’s eye, I see this same thing happening to my 11i applied patches database table.


OAM says: Not there

So I’ve innocently decided to use patch 6863618 as my demo.  Being a good DBA (or, depending upon how you look at it, a bad one, in that I have to check the database to see if it’s applied and not my own documentation), I go to OAM and search for it:

Never seen him



Apply 6863618

Using adpatch, I apply the patch without incident:

So far so good




Look into the Neuralyzer

And here’s the proof that something has run afoul internally in the patches database:

Sounds familiar, but nope, haven't seen him







Obviously (with the times circled in red for your viewing pleasure) something isn’t right.  Either I didn’t just apply this patch, OAM isn’t looking for it right, or it hasn’t been recorded in my patch inventory.  This example will serve as a springboard for my (surprise!) rather disparaging review of the patch wizard next posting.  Incidentally, in the interest of due dilligence, I’ve submitted this issue for review via SR at My Oracle Support.  While I have no faith that the analyst will even grasp the concept of the issue, I nevertheless felt compelled to ask.

October 6, 2010

Over Riding Workflow Email in 11i

Filed under: 11i — kkempf @ 10:07 am

In the Real World

ERP environments get cloned, products get implemented, and users are inadvertently sent Workflow notifications from non-Production systems.  In this quick post I hope to show you how you can avoid this.

Pull the Plug

The absolute simplest way to avoid confusing, non-Production deliveries from a non-Production system: Turn it off.  Almost didn’t mention this, but figured in the interest of completeness, I would.  Just click the radio button for Workflow Notification Mailer, then use the drop down box to select Stop and hit go.

Collecting Disability

The Over-Ride

The next simplest way to avoid confusing deliveries is to send all outbound messages to one person.  From the screenshot above, hit the View Details button (which is confusing, because you’d think it would be under edit), and you get to a screen that looks like this:

Note that I prefix the sender name with DEV, wheras in Production, it’s PROD.  This is an easy way for me (or the helpdesk) to identify errant emails which cause phone calls, and if it says “DEV Workflow Mailer” I can confidently tell the user to hit the delete key and hang up the phone.  Incidentally, a confirmation code is sent via email which must be entered to “finalize” the override.  It’s like an episode of Chuck.


We all know that 10 minutes after you set the over ride to the project manager for the product they’re implementing, he or she will call you and say “no, that’s not what I meant”.  Un-over riding this functionality is a little harder to find, but within the view details screen you can see below how to “clear” it:

Never Mind

Old School

If you’re trying to script this (for example, as part of a post-cloning procedure) and don’t wish to be bothered by verification emails, an update like this should do the trick:

parameter_value = ''
parameter_id =
display_name = 'Test Address'

Create a free website or blog at