"EMPTY" Virtual Circuits causes the dispatcher proces D000 use 100% CPU

Question

(29th April)
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Apr 29 14:59:56 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
Could someone please indicates why the D000 process uses 100% cpu while no XDB action seems to be running? Whe are not using shared server (besides the XML DB usage) and the only value for the dispatcher parameter in the init<SID>.ora = (PROTOCOL=TCP) (SERVICE=<SID>XDB).
update (30th april)
When I lookup the virtual circuits I notice 2 VC without server and waiter address and without session info.
GERE@ARG_DV8>
# SELECT RAWTOHEX(C.CIRCUIT), RAWTOHEX(C.SERVER) SRV, RAWTOHEX(C.WAITER)WTR,
2 D.NAME,
3 S1.NAME,
4 S.SID,
5 S.SERIAL#,
6 C.STATUS,
7 C.QUEUE,
8 C.MESSAGES,
9 C.BYTES
10 FROM V$CIRCUIT C, V$DISPATCHER D, V$SHARED_SERVER S1, V$SESSION S
11 WHERE C.DISPATCHER = D.PADDR(+) AND C.SERVER = S1.PADDR(+) AND
12 C.SADDR = S.SADDR(+)
13 /
CIRCUIT SRV WTR NAME NAME SID SERIAL# STATUS QUEUE MESSAGES BYTES
C0000002398456C0 00 00 D000 NORMAL NONE 6 261
C000000239840DC0 00 00 D000 NORMAL NONE 7 280
2 rows selected.
The SADDR is empty also.
GERE@ARG_DV8>
# SELECT SADDR, CIRCUIT, DISPATCHER, SERVER, SUBSTR(QUEUE,1,8) "QUEUE", WAITER
2 FROM V$CIRCUIT;
SADDR CIRCUIT DISPATCHER SERVER QUEUE WAITER
00 C000000239840DC0 C000000214C05FB8 00 NONE 00
00 C0000002398456C0 C000000214C05FB8 00 NONE 00
2 rows selected.
A lsnrctl services shows 2 current
Service "ARG_DV8XDB" has 1 instance(s).
Instance "ARG_DV8", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:58903 refused:0 current:2 max:2046 state:ready
DISPATCHER <machine: leo, pid: 5672>
(ADDRESS=(PROTOCOL=tcp)(HOST=leo.argenta.be)(PORT=53044))
Stop and start of the listener doesn't solve this problem but killing the unix process will do. When I killed the D000 proces a new dispatcher is started (does pmon do this?) and the current shows 0. This workaround is fine on the DVL machine but no sollution on a production DB :-)
Kind regards,
Rene
Edited by: Rene Geilings on Apr 30, 2009 2:28 AM

Answer 1

By the way... you just could be unlucky hitting a very rare situation that caused the phenomenon decribed by you. Deamon processes also could arise due too standard JDBC, ODBC or other connection methods. As long as you don't provide Oracle Support with a SR, you will not know if it is actually XDB related or not.
If I would implement XDB functionality in a production system than at least I would:
a) disable automatic memory management by setting SGA parameters manually
b) set the large_pool_size to a appropriate value to support the shared server processes
c) tweak dispatcher and shared server processes to match at least values that represent
   the minimum++ needed processes (= a higher value then needed maximum)
d) set java_pool size to a decent size (250 Mb or higher)
e) set an appropriate PGA setting to support XML fragment handling
f) DISABLE autoregistering database functionality with the listener
   (see amongs others "Registering non-default XMLDB HTTP/WebDAV and FTP ports
   on a non-default Oracle Listener port" - http://www.liberidu.com/blog/?p=116)
g) alter the xdbconfig.xml file with more appropiate timeouts, locking and cache handling.
h) dedicate a specific listener (aka a a listener not called "LISTENER") for shared server
   connection handling (this for management reasons and specific debugging).
i) use version 10.2.0.4.0 or 11.1.0.7.0 for production environments (I know that this
   matches your environment)
j) always enforce that client software matches the database version
   (as in your case 10.2.0.4.0)
k) keep NLS settings on client and database equal and support a AL32UTF characterset
   (IMHO a minimum requirement on the database side)