11gR2 Database Control, Shared Servers and the DBSNMP User

I'm working with a production database which is configured with shared servers for the web applications that use it, and end users should only ever connect with a dedicated server (though should != does).

When users connect with the "basic" mechanism in SQL Developer instead of the TNS that we've set up, this can sometimes lead to their session essentially blocking an entire shared server for themselves.  This isn't a huge issue as there's plenty of resource to spare, but it makes my ASH reports look ridiculous - 90% Virtual Circuit Wait isn't uncommon and it's all because of these users.

I've taken to using this query to identify the culprits and killing their sessions when they're idle:

 select
    n.SID
  , n.SERIAL#
  , s.name
  , s.status
  , n.LOGON_TIME
  , n.username
  , n.OSUSER
  , w.event
  , n.WAIT_TIME_MICRO/1000000 "Seconds"
from
    v$shared_server s
  , v$circuit c
  , v$session n
  , v$session_wait w
where
      s.circuit = c.circuit
  and c.saddr =   n.saddr
  and w.sid =     n.SID
order by
  n.LOGON_TIME ASC
;

An annoyance since I've been monitoring this, is that the OEM/DBConsole/Database Control DBSNMP user connection has always used a shared server.  Despite me setting an explicit connection string with SERVER=DEDICATED, it still used a shared server.

Today - while searching for something completely different - I found this blog post from Purple DBA: OEM and Shared Servers.  It explains how to resolve the problem.  I have to admit, it felt wrong even trying it.  It feels like such a bodge.

In the "Monitoring Configuration" page, replace the "SID" entry with this:

SID)(SERVER=DEDICATED

That's it.  As soon as I tested it, and applied it, the permanent DBSNMP connection using the shared server disappeared.  Purple DBA said to restart dbconsole, but I found that this step was unnecessary.