On 9/12/05, Amaury Forgeot D Arc <Ama...@ub...> wrote:
> I've never used the Intelligent agent, but it seems on the contrary=20
> that a running agent is one of the causes which prevent=20
> SHUTDOWN NORMAL to work.=20
> A quick Google search reveals that some DBAs include a=20
> "agentctl stop" command in their shutdown procedures.=20
Hmm, I was sure I'd seen agent connections on a database which stopped
happily with SHUTDOWN NORMAL. Maybe I was mistaken... I don't have a
system I can do a realistic test of this on at the moment,
unfortunately :-(
> You should try to solve your case differently. Here are some ideas:=20
>=20
> - replace SHUTDOWN NORMAL by SHUTDOWN TRANSACTIONAL, which
> closes the connection after COMMIT or ROLLBACK.
To be honest, I would expect most shutdowns to be IMMEDIATE (or at
least to do IMMEDIATE if NORMAL doesn't respond within a reasonable
time). However, I'm not 100% certain that's the case - and I really
don't want to block a production system shutdown just because I wasn't
aware of it!
=20
> - Implement some kind of connection pooling, where the connection=20
> object is closed after 10 minutes of idle time.=20
> For this you will need another thread to close the connection.=20
That might work, although I expect the connections to spend most of
their time idle. The only reason I'm bothering about this is to
increase responsiveness of an application querying many databases,
with very small queries, where I want to avoid the issue of the
connect time dominating the response. Maybe it's simplest just to
accept the hit, and connect when needed - I can multithread the
connections, so that I'm only limited by the response of the slowest
connection.
> - Use the Oracle "Profiles" feature, and limit the "idle time"=20
> for the session.=20
Not really an option, as it needs changes to the target databases,
where I don't have that flexibility. A connection pool would probably
be better for my specific requirements here.
> Hope this helps,=20
It does, thanks.
Paul.
|
