how to kill a session?
Ramkumar Vaidyanathan
Hi,
I had hard time in killing a user-session. I issued the command
onmode -z <session ID>
and waited for ever, nothing happened, and meanwhile nobody could
able to connect to database from the client, and I could not connect
using "dbaccess" either.
Then we decided to bring-down the server, and issued the command
onmode -ky
and it never came back!, and nothing was getting logged in the
database-log file
Finally I had to use the oracle, KILL -9 <pid> to bring down the server.
Does any one
know how to really kill a session?
Thanks
Ram
rkus...@rogers.com
news:aaspsj$p15$1...@news.xmission.com...
Please post the output of online.log in the time frame when you tried
to kill.
My guess is that the server was stuck in some blocked mode.
Did you check onstat -m. It will tell you whether the server was blocked
for logical log backup.
Andrew Hamm
kill -9 puts you in grave danger of crippling your engine. It probably
should be written in BIG RED LETTERS on the front page of all the manuals:
DO NOT USE "kill -9" ON ANY INFORMIX PROCESS. If your data is still ok then
consider yourself lucky.
What's needed here is perhaps some background that would explain the
apparent freeze-up.
The engine can appear to freeze for two main reasons: long transaction
rollback, or excessively long checkpoint.
1)
Long transactions occur when a process fills a significant part of the
transaction log, to the point where the engine say "Uhh Ohh! This is looking
bad - I'm going to stop that transaction and roll it back". There is a low
and high "water mark" for this in the transaction log. When the log reaches
the high water mark, all activity stops as the engine rolls back the errant
process. It may need all the space it can get in the log files, and will not
permit other work to consume that space.
While a rollback is going on due to the high watermark being reached,
nothing will happen. Even if other processing is allowed to continue working
(maybe only the low watermark has been breached) it's highly likely that the
greedy process has locks on rows that other processes want access to. If
that's the case, then the other processes will have to wait for the rollback
and there's nothing you can do.
2)
If a process causes so much write activity, and if your engine tuning is
sufficiently bad, you may end up with checkpoints that run for several
seconds, upto several minutes if things are horribly wrong. During a
checkpoint, certain things cannot be done. Like a lot of work, for example.
If you have checkpoints reaching into the minutes then there is nothing you
can do but wait for it to complete. And then tune the engine.
In either of these cases, if you attempt to kill a process with onmode -z,
the process will not disappear from the user list until all it's work is
completed. If it's going to take 10 minutes to roll back a horror
transaction then there's nothing you can do but wait for it. If you try to
get around that by shutting down the engine, crashing it deliberately or
pulling the power from the machine, then you'll have to wait 10 minutes for
the rollback to occur during startup. And you'll probably see the user
process "appearing" during startup! This is because there ghosts are called
up during the startup process, if the engine sees any transactions need
rolling forward or back.
If you attempt to kill a user process, it won't help. The engine has to do
the work and it will. If you attempt to kill the engine itself, it won't
help, and may cause a disaster. The engine has to do the work and it will.
What's worse is, if you kill engine processes, there's a fair chance that it
will screw up your data.
3)
Another possibility is that if your physical and logical logs are too small,
you might deadlock the engine in a horrible combination of required
checkpoints, long transactions and unexpected voodoo curses. Send in details
of how big your data is, and also how big your physical and logical logs are
if you want some feedback on this possibility.
--
Because Windows was not properly shut down,
one or more of your disk drive might have errors on it.
To avoid seeing this message again, always shutdown
and re-install a stable operating system.
NormaJean...@tellabs.com
Did you do an "onstat -u" first and check the flags associated with the
session you wanted to kill?
You may have attempted to whack a session in critical section - a "not
allowed" activity in Informix, thus the session did not die.
Did you try "onstat -g act -r #" (number of seconds to repeat command)
to see if any activity was going on or if indeed the engine was
stalled? Maybe the engine was grunting out a big checkpoint?
If a process was in critical section and you really wanted it dead....
I'm not sure you can kill it without bringing down the engine....
hopefully others may know/remember more?
Norma Jean
-----Original Message-----
From: ramk...@lsil.com [mailto:ramk...@lsil.com]
Sent: Thursday, May 02, 2002 8:07 PM
To: inform...@iiug.org
Cc: ramk...@lsil.com
Subject: how to kill a session?
Hi,
I had hard time in killing a user-session. I issued the command
onmode -z <session ID>
and waited for ever, nothing happened, and meanwhile nobody could
able to connect to database from the client, and I could not connect
using "dbaccess" either.
Then we decided to bring-down the server, and issued the command
onmode -ky
and it never came back!, and nothing was getting logged in the
database-log file
Finally I had to use the oracle, KILL -9 <pid> to bring down the server.
Does any one
know how to really kill a session?
Thanks
Ram
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.
Thank you.
Tellabs
============================================================
Murray Wood
You failed to tell us WHY you wanted to kill a session which is probably the
most important item in this email.
I would guess that your session was rolling back a transaction (after the
onmode -z) or your server was waiting on a resource (maybe your logs had
filled and you did not do anything about it). That information is in your
Informix messages log. If some OS resource required by Informix was not
being supplied then the engine could also appear hung.
Kill sessions with onmode -z only when you know what the session is doing
and the status of the engine.
If you problem was that nobody could connect to the engine then you needed
to resolve that issue first. This session could not be doing that.
MW
Dirk Moolman
What did onstat -u | grep <sid> show after you killed the session ? It
could have been busy doing a rollback, in which case you have to wait for
the rollback to complete. And if this transaction hit the LTXEHWM, all other
sessions would be blocked and it would seem like your system is hanging.
You will see this when doing an onstat -, and instead of ONLINE you will see
LONGTX
Bringing the engine down and up again, won't fix this, the transaction still
has to finish rolling back.
Rajib Sarkar
If no one is able to connect that means there's a problem with the LISTENER
THREAD. Maybe doing a onstat -g stk <thread> would have told something more
about why this was happening.
Not able to kill a session with onmode -z can be due to lot of reasons say,
a) Session in Critical Section
b) Session waiting on a MUTEX
c) Session doing some kind of a Rollback
etc. etc.
the onstat -u and subsequent onstat -g ath , onstat -g stk <thread_id>
would help diagnose the problem far better.
If you have got Tech Support, you can call them up and send them the
following:
a) onstat -a output
b) onstat -g stk all output
c) onstat -o (shmem dump)
and they'll be able to diagnose the reason behind it.
BTW, the valid way of killing a session is onmode -z (for a distributed
transaction it is onmode -Z ).
HTH
Thanx much,
Rajib Sarkar
Advisory Support Engineer(Wells Fargo Bank)
IBM Software Group -- Data Management
Ph: 602-2172100, Fax: 602-2172100
"Murray Wood"
<mur...@quanta.co To: <inform...@iiug.org>
.nz> cc:
Sent by: Subject: RE: how to kill a session?
owner-informix-li
s...@iiug.org
05/02/2002 07:21
PM
You failed to tell us WHY you wanted to kill a session which is probably
the
most important item in this email.
I would guess that your session was rolling back a transaction (after the
onmode -z) or your server was waiting on a resource (maybe your logs had
filled and you did not do anything about it). That information is in your
Informix messages log. If some OS resource required by Informix was not
being supplied then the engine could also appear hung.
Kill sessions with onmode -z only when you know what the session is doing
and the status of the engine.
If you problem was that nobody could connect to the engine then you needed
to resolve that issue first. This session could not be doing that.
MW
-----Original Message-----
From: owner-inf...@iiug.org
[mailto:owner-inf...@iiug.org]On Behalf Of Ramkumar Vaidyanathan
Sent: Friday, 3 May 2002 1:07 p.m.