Oracle MVA

Tales from a Jack of all trades

OID11 on Windows 2008R2 abnormality

leave a comment »

One of the organizations I work for is running their middleware on Windows (on VMWare), to be precize on Windows 2008 R2. Last week service pack 1 was applied on their boxes and somehow OID died on me. When I checked opmn I noticed that oid was really down:

opmnctl status

Processes in Instance: asinst_1
--------------+--------------+------+---------
ias-component | process-type | pid | status
--------------+--------------+------+---------
oid1 | oidldapd | N/A | Down
oid1 | oidldapd | N/A | Down
oid1 | oidmon | N/A | Down
EMAGENT | EMAGENT | 3868 | Alive


Now when I called opmn to start all processes, I didn’t see an error, but somehow OID still didn’t start:

opmnctl startall
opmnctl startall: starting opmn and all managed processes...

opmnctl status

Processes in Instance: asinst_1
--------------+--------------+------+---------
ias-component | process-type | pid | status
--------------+--------------+------+---------
oid1 | oidldapd | N/A | Down
oid1 | oidldapd | N/A | Down
oid1 | oidmon | N/A | Down
EMAGENT | EMAGENT | 3868 | Alive


When I checked the logfiles I noticed that the .oidmonstdout had a different filesize from normal. The contents was this:


ORA-24550: signal received: Unhandled exception: Code=c0000005 Flags=0

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
kpeDbgCrash()+83 CALL??? kpedbg_dmp_stack()+ 0774AB328 00168DD86 000000000
0 005CFD9D0
kpeDbgSignalHandler CALL??? kpeDbgCrash()+0 00168E026 000000000 005CFD9D0
()+122 000000002
skgesig_Win_Unhandl CALL??? kpeDbgSignalHandler 000000000 000000000 000000000
edExceptionFilter() ()+0 000000000
+171
0000000077439490 CALL??? skgesig_Win_Unhandl 000000001 000000000 000000001
edExceptionFilter() 000000000
+0
00000000776543B8 CALL??? 0000000077439330 005CFDB40 000000006 000000000
000000001
00000000775D85A8 CALL??? 0000000077654374 000000000 000000000 000000000
000000000
00000000775E9D0D CALL??? 00000000775D850C 005D00000 005CFFF90 005CFFF90
077702DE8
00000000775D91AF CALL??? 00000000775E9D00 005D00000 0774ADF08 000012F24
00369C680
0000000077611278 CALL??? 00000000775D8E20 005CFE780 005CFE290 000000000
000000000
0000000000402877 CALL??? 000000007761124A 000000000 00056B5BC 005CFE730
005CFE6A8
0000000010011A80 CALL??? 00000000004027B4 000000000 000000000 004FCD010
003790000
0000000010005E3E CALL??? 0000000010011A24 000000000 7FEFD8E1413
004FCD010 004FCD010
000007FEFD92C387 CALL??? 0000000010005E08 00504E900 000000000 000000000
000000000
000007FEFD92C424 CALL??? 000007FEFD92C370 7FEFD971EA0 004FCD010
000000000 000000000
00000000773B652D CALL??? 000007FEFD92C3A8 000000000 000000000 000000000
000000000
00000000775EC521 CALL??? 00000000773B6520 000000000 000000000 000000000
000000000

----- End of Call Stack Trace -----


Some googleing tought me that this has to do with some sqlnet settings for diagnostics. Funny how diagnostics can actually break your stuff on Windows… Anyway, placing a sqlnet.ora in C:\Oracle\asinst_1\config (yes, that’s the config directory of your instance, or any other location if you have modified your opmn.xml manually) with this contents fixed the issue:

DIAG_ADR_ENABLED=OFF
DIAG_SIGHANDLER_ENABLED=FALSE
DIAG_DDE_ENABLED=FALSE

Hope this helps.

Advertisements

Written by Jacco H. Landlust

April 4, 2011 at 6:05 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: