Friday, November 21, 2008

Provisioning pack actually works

As we recently discussed, there are some issues with Grid Control out of the box provisioning functionality.

Want to know if your gridcon is setup for patching? Deployments>>provisioning>>directives>>Oracle Components. See Oracle Patch Prereq Checker? Common Provisioning Utilities?

No? Then you'll likely end up with the hated "Incorrect Directive URN: null" error we mentioned back in October. Will also show up in emoms.log as the following error:

ERROR em.paf_jobs executePAFCommand.142 - Problems with the directive urn parameter format.

How do you fix this?

I'll save you a week of playing with the PARDeploy app.

1) Setup your software lib in deployments>>provisioning>>administration
2) Run Refresh Metalink and Refresh OPatch from Grid control
3) Run $ORACLE_HOME/PARDeploy -action -deploy -parDir $ORACLE_HOME/sysman/prov/paf -force

Still does not work?

Here's the magic from metalink note 727001.1 and a very useful OTN forum thread.

Download the .par files from $ORACLE_HOME/sysman/prov/paf of your oms server to your local machine. Go to Deployments>>Deployment Procedures>> Upload

Select each .par file and upload it.

I found the asprov files, patchadvisor, provCommon, and prereqs were useful, the others, not so much in my installation.

After that, patches installed without much of a problem. Patching speed leaves a bit to be desired (one system took 2 hours, another, 23 minutes. YMMV).

Oh, final note, sometimes the .par files need to be banged around a little bit in order to be accepted by the app. I had to extract one of the zips that got uploaded, move the files around a bit to get them to upload successfullly. Might open a tar on that one.

Friday, November 14, 2008

VMware vs. Oracle support issue

Just found NOTE:249212.1 about Oracle support when running on VMware. Basically, they provide support up until they think it might be a VMware issue, then you get to prove to Oracle that the issue is theirs.

Pretty typical when a platform isn't "certified". But a nasty business practice.

Strange. Back in 2004 VMware and Oracle had a parternship.

... then about a year ago, Oracle releases Oracle VM, and boom, they're not going to certify on VMware. Stupid.

FYI...apparently Oracle does work on VMware, and according to a blog on their site, it runs *best* on VMware.

Strange. Is this just Oracle taking a support stance via not certifying to lure customers away from VMware onto their shiny new toy? Or is there some fundamental problem with VMware that Oracle is saving us from?

It's unlikely. I think someone in the VMware world might have gotten under the skin of one of the higherups at Oracle, cause they have certified Solaris 10 containers:

# Oracle does support Oracle non-RAC databases (10gR2, 10gR1, and 9.2 for SPARC and 10gR2 and 10gR1 for x86-64) with Solaris 10 non-global (local) Containers on the existing supported platforms for SPARC and x86-64. See metalink note 317257.1 for best practices document for deploying Oracle database in a Solaris 10 non-global Container
# Oracle RAC does not work in Solaris 10 local Containers.
# Oracle does not support Oracle with Solaris 8 or 9 containers on a Solaris 10 Operating Environment or any other combination not mentioned in the statement listed above. NOTE:567849.1

Still looking around for a rationale on why Oracle won't certify on VMware.