Fun with clntsh

Installing iAS 10.1.2.2 onto an Oracle oms grid control box.

Got the following error during linking, looks to be a Solaris 10 + 10R2 issue.

ld: fatal: file /u01/app/oracle/product/oms10g//lib32//libclntsh.so: unknown file type
ld: fatal: File processing errors. No output written to webcached
*** Error code 1
make: Fatal error: Command failed for target `webcached'

Here's the fix:

Edit $ORACLE_HOME/genclntsh
Change LD="ld -m -i -G -z text -L${ORACLE_HOME}/${LIB}"
to LD="ld -m -i -G -z text -L${ORACLE_HOME}/${LIB} -Bsymbolic"

Then run $ORACLE_HOME/bin/genclntsh

Then retry the linking phase.

Sometimes it's just a login issue.

Trying to install iAS 10.1.2.2 on a 10.1.0.2 server, I got the following error, among others, while updating OC4J:

FAILED!
ERROR: Caught exception while undeploying 'portletapp' from 'home':
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at oracle.j2ee.tools.deploy.Oc4jDeploy.doDeploy(Unknown Source)
at oracle.j2ee.tools.deploy.Oc4jDeploy.execute(Unknown Source)
at oracle.j2ee.tools.deploy.Oc4jDeploy.deploy(Unknown Source)
at oracle.j2ee.tools.deploy.Oc4jDeploy.main(Unknown Source)
Caused by: com.evermind.client.orion.AdminCommandException: Could not connect to the remote server. Please check if the server is down or the client is using invalid host, ORMI port or password to connect: Connection refused
at com.evermind.client.orion.Oc4jAdminConsole.executeCommand(Oc4jAdminConsole.java:115)

Also got an error with wsrp-samples.

After spending quite a bit of time looking at log files, and finding nothing interesting, I realized it was a password issue.

Earlier in the day I had followed an oracle doc to reset ias_admin's password from emctl prior to installing the update.

Here's the thing -- to _really_ set the password, you have to login to iasconsole and change it there. Apparently that changes the passwords in more places than emctl does.

Problem solved.

Selecting on dates using the interval clause.

When I've wanted to select all records in the last day or the last couple hours I've done a query like the following:


-- select records from the last day
select count(*) from table where some_date > sysdate - 1;

-- Select records from the last 3 hours
select count(*) from table where some_date > sysdate - 3/24;


Starting in 9i there's another way to do this.

-- select records from the last day
select count(*) from table where some_date > sysdate - interval '1' day;

-- Select records from the last 3 hours
select count(*) from table where some_date > sysdate - interval '3' hour;


Fun with tar

Quick tip for copying directories between systems:

tar czf - -C /u01/app/oracle/stage/patchset cpu2008oct | ssh server2 tar xzf - -C /u01/app/oracle/stage/patchset

What's important here is the -C flag. In this case it tells tar to change working directory to /u01/app/oracle/stage/patchset, and only then begin backing up cpu2008oct. Same scenario on the extraction, change working directory then begin extracting.

Provisioning pack actually works

As we recently discussed, there are some issues with Grid Control 10.2.0.4 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.

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.

Provisioning, Patching, and Grid Control

Attempted (again) to get 10.2.0.4 Grid Control to patch a few databases. Fail. Hard.

Eventually, we found the following glorious DocID on Metalink: 427577.1. Bookmark it now.

It identifies a few patches you'll need to install on GC in order for patching to work. Or you end up with some very irritating, strange, and mostly undocumented errors:

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

oracle.sysman.emgc.provision.UrnException: The URN, 'null', is not properly formatted

There are others, not totally related:

There was an error saving 'p4898608_10.2.0.4_2000' below 'OracleSoftwareUpdates' in the deployment library

Fixed that one by deleting from Deployments>>Provisioning select and deleted p4898608.

There's a really handy guide to look at -- grid-automation-deployment-procedures.pdf Found that to be pretty useful.

Couple more random things:
1) Setup your software library: info here
2) Run the metalink & opatch update scripts. Now.
3) Patch the system from the docid above.

Should work. Hasn't for me yet, but when it does I'll post the last lil bits.