Kevin Kempf's Blog

July 8, 2009

RDBMS 11g Cloning “Gotcha”

Filed under: 11g, Oracle — Tags: , , , , — kkempf @ 3:08 pm

As you might be able to tell, I’ve been doing some cloning (and cloning streamlining) lately and hit another obscure bug which required some attention. Toward the end of my cloning process I used the FNDCPASS utility to change the apps and non-apps but related (GL, AR, AP, etc) passwords so they differ from production. I’m going about my normal business of running the script which does this for me, and next thing I know, I can’t log in as apps with either the old or the new password. Bugger.

After making this mistake once, I re-cloned the environment (which is a VM) and took a snapshot before I started messing with the offending script. Two or three tries (and snapshot reverts) later, while following 159244.1, I’m out of ideas. I’m doing it verbatim from their doc. I even opened an SR with Oracle. I told the analyst I was running this in a VM. Thus it was of no value to me to try to troubleshoot the “broken” post-FNDCPASS condition, since I could just revert the snapshot. I think her head exploded when she read this. She didn’t know what a VM was, or if FNDCPASS could possibly even work in one. At this point, I (once again) gave up on support.

After trying to relink the binary without a change in behavior, I came to the sudden realization that I could not cite a case where I had successfully used this utility since going to RDBMS 11g. All my non-production environments were upgraded in place, and thus had never had this utility run against them. That’s when I found a note on Metalink which ultimately fixed the issue (751868.1). Curiously, it is worded to imply that this condition came up only in cases where you were migrated from 11i to R12, and also 10.2 to 11.1 RDBMS. Upon reading it in detail, however, you can see that R12 is irrelevant and this did fix my issue.

Reverted my snapshots, started RDBMS with sec_case_sensitive_logon=false in my init file, and voila, suddenly FNDCPASS correctly changes the password.

Advertisements

When EM Flips Out

Filed under: Bugs, Enterprise Manager, Oracle — Tags: , , , — kkempf @ 7:35 am

For no apparent reason, yesterday afternoon about 2pm Enterprise Manager went haywire. It was using 100% of 1 CPU, and causing considerable I/O (log writer). The truth is, it doesn’t take much to kill a 1-CPU virtual machine, but this was without precedent.
EM1EM2

After some digging, the offending SQL was:
SELECT execution_id
FROM MGMT_JOB_EXEC_SUMMARY e, MGMT_JOB j
WHERE e.job_id = j.job_id AND j.is_corrective_action = 0
AND status IN (5,4,3,18,8)
AND (CAST(SYS_EXTRACT_UTC(SYSTIMESTAMP) AS DATE) – e.start_time) > (:tf)
AND ROWNUM < 500 ORDER BY start_time desc

A few searches on Metalink, and I find DOC 839080.1, which tells me to apply patch 8517252. This patch applies against the EM Application Home, not the database. So I shut down the application, opatch in 8517252, but the post script @post_install_script.sql is hanging. Had to hard kill (kill -9) the 100% cpu process at the OS level and this cleared the lock contention. Finished installing the patch, fired up the EM application again, and all was good (this is in the graphs above, about 5pm).

Create a free website or blog at WordPress.com.