Joel,
I don't THINK that is the case. I believe there never was a "death
signal" from the client at all. However, as we're unable to reproduce
the problem, I cannot be certain. And about the "solution" you warned
me about - no, never even thought of trying to hunt those sessions
down myself. Especially not like that.

Phil,
yes, that's true. There a few bugs regarding this issue on MOS and the
one that appears to be the root cause is marked as fixed in 11.2. I'll
create an SR and see what solution they come up with. Originally I
thought I was just missing something obvious.

I'll update this once we find a reliable solution or a workaround.

Thanks everyone,
David

On Thu, 23 Jun 2011 00:43:11 -0700, gonzo wrote:

I already suggested that, but it's not what the OP needs.



--
http://mgogala.byethost5.com

David:

DCD seems to have a number of bugs and problems in recent releases
10.2 and 11.1 ... it won't work correctly in 11.1.0.7.7 unless ( they
say ) patch 6918493 is applied.

You may need to do some custom patching of your environment also.
Kind of hard to believe that fixes to an old functionality like DCD
need one off patches even on top of recent patchset updates ... but
there you have it.

# And about the "solution" you warned me about - no, never even
thought of trying to hunt those sessions down myself. Especially not
like that.

Nothing wrong with building in some custom reporting for exceptions
( long idle sessions for example ). You can always report on them for
a while without taking any actions to actually kill them off.

Really enabling DCD is not very different from killing sessions from
outside of oracle it is mostly a difference of who the hit man is
right?

On Jun 23, 2:24*pm, Mladen Gogala <gogala.mla... (AT) gmail (DOT) com> wrote:
Using SQLNET.EXPIRE_TIME is NOT the same as using the DB Resource
manager.
Your suggestion, which I agree is a valid one although doesn't seems
to work on the OP environment, address this issue in the Network
layer.
What I was proposing is to let the DB server identify and kill idle
sessions regardless of their connection status. The advantages of this
approach are two, the network is not affected by connection probing
and you can precisely control which sessions you need to monitor and
when to kill them.

On 22.06.2011 22:28, joel garry wrote:
As far as I remember Oracle's architecture in Windows versions they do
not use multiple processes with shared memory there but rather a single
process with a thread per connection (which would be the dedicated
server process on *nix).

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Fri, 24 Jun 2011 18:59:03 +0200, Robert Klemme wrote:

That was stated in this document:

http://download.oracle.com/docs/html...01/ap_unix.htm

This, however, doesn't apply to Windows 7 and Oracle 11.2. Does anyone
have anything more on that? I did one NNF installation on Windows 7, but
that was all. I don't have sufficient knowledge to be able to
differentiate between processes and threads on Windows. I must say that I
am more interested in Windows 7/ 11G combination than in the older
software.



--
http://mgogala.byethost5.com

On 25.06.2011 03:14, Mladen Gogala wrote:
Still seems to be the same for 11gR2:

http://download.oracle.com/docs/cd/E...ix.htm#i634536

Everything else would have surprised me. Such a dramatic architectural
change is not done easily.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Apologies for forgetting which OS we were talking about and generally
blanking out on Windows architecture. Thanks to all for correct info.

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2...-space-gamble/