Is there a way to kill an informix process in a graceful manner? Does onmode -z take into account what is going on with a job and wait until its in a "good place" before killing it?

Hi,
onmode -z is the best way to clear an informix process.
onmode -z <session_id>

This is similar to Unix kill -9 <pid> interrupt signalling. Onmode takes care about the trasactions in progress condition too, if so it will judge the stage of the transaction, and tries to commit, if possible. But in most of the cases it rolls back the transactions. Such cases it may take a longer period to terminate a session.

Hi,

Look here for the original post dated Dec 12, 2003:
http://www.tek-tips.com/viewthread.c...PID=179&page=4

I request all forum members, while copying solutions given by others, at least give credit to the original poster.

Regards,
Shriyan

Hi,

If you were not able to get inside tek-tips.com page containing the subject with earlier URL here is the exact pointer to that page:

http://www.tek-tips.com/gviewthread....179/qid/728199

Regards,
Shriyan

Hi Shriyan,

Thanks for the post. How can we do the above in a script. For eg. i take a daily dbexport of my database through cron. On most of the occasssions some sessions are connected to the database and so the dbexport fails. Do you have an automated script which will check for open sessions & delete them before doing a dbexport.

Best Regards,

Lloyd

Hi Lloyd,

One of the primary requirement for successful execution of dbexport job
is that it needs a database access in exclusive mode. A DBA need to monitor active sessions and plan dbexport job according to the least traffic situation in the database. A automated (batch process) may result in havoc of active sessions, should such batch process kill all those active sessions!

Anyway, you may fall upon steps outlined below to automate it.
1. output to aa.cmd without headings select 'onmode -z '||sid from sysmaster:syssessions ;
2. Run aa.cmd
3. Wait for some time. (example: sleep 10) Let the engine commit/rollback those active sessions having transactions.
4. Check for any remaining active sessions: select count(*) from sysmaster:syssessions;
5. If any sessions are active repeat steps 1 to 4
6. dbexport -d <database> -ss ...

Regards,
Shriyan

Hi Shriyan,

Thanks once again for your prompt reply. I will work on the below steps.

Best Regards,

Lloyd