Oracle 9.2.0.8, running on Solaris 9 64 bit
We use advanced queuing to trickle (800 per minute) real time
transactions into a datamart. This has been live for a month and is
working great. Apart from the fact we have noticed that the EMN0
process is now at 1.8g. This is a 24x7 database so restarting the DB
is a last resort. We have an SR open with oracle ... but I am after a
couple of swift answers from here...
The process we have implemented looks like this.
Trigger puts payload onto a non-persistent queue, which invokes a
callback, before placing a message on persistent queue from where it
is sent across a dblink into a destination queue on the Datamart.
The server still has plenty of RAM spare, but I am concerned that we
will imminently hit a process limit at 2g. Is this the case? If I kill
the process, what will be the impact on any transactions? ( I don't
want to loose any data and don't want the firing of the trigger to
hang if EMN0 is not there ... I doubt this will happen). Oracle will
restart the process, but what happens in the interim.
We have tried this in another environment (and EMN0 does restart),
though not one that was under load...(we are working on getting hold
of the stress harness to test this...)
If anybody has any light they could shed on this, that would be a
help.
Cheers
Ralph
With a 64 bit install of oracle on a 64 bit os you "shouldn't" run
into problems related to 2 gig. Used to be that one would get quality
support from oracle on solaris ... keep your fingers crossed.
I would think about scheduling downtime real soon for a bounce while
you keep trying to push support.
Good luck.
Thanks for that...
We managed to get hold of the test harness and had some interesting
results which I shall share here just incase anybody else hits this
issue.
Basically when EMN0 was killed (kill -9 was the only way) when under
load, all of the server processes trying to insert into the table with
the trigger on (the trigger that enques to the non-presisitent queue)
hung with a "waiting for EMN process to spawn" event.
So the answer is "Processes that enqueue to non-persistent (and
probably persisitent) queues will wait about if EMN is not present
until it is back ...which can be up to 3.5 minutes", which is bad news
for me, as it means I'll be getting up at some ungodly hour to kill
the thing...unless anybody can think of a way to pursuade pmon (I
think...) to create me a new EMN0 process "on demand"?
Cheers
Ralph