H E L P Requested
Posted in 2008
Topics: Installation, Setup & Upgrades, Error Codes & Troubleshooting, Versions, Editions & End-of-Life
10:39:06 Maximum server connections 66 10:43:08 Assert Failed: No Exception Handler 10:43:08 IBM Informix Dynamic Server Version 9.40.UC2 10:43:08 Who: Session(17517, swx@ATMSWPROD2, -1, 4b2374d8) Thread(19286, sqlexec, 4b219aa8, 1) File: mtex.c Line: 431 10:43:08 Results: Exception Caught. Type: MT_EX_OS, Context: mem 10:43:08 Action: Please notify IBM Informix Technical Support. 10:43:08 stack trace for pid 6116 written to /tmp/af.4f3ee58b 10:43:08 See Also: /tmp/af.4f3ee58b, shmem.4f3ee58b.0 10:43:26 Error writing '/tmp/shmem.4f3ee58b.0' errno = 28 10:43:26 mtex.c, line 431, thread 19286, proc id 6116, No Exception Handler. 10:43:26 invoke_alarm(): /bin/sh -c '/appl/informix/etc/log_full.sh 5 6 "Internal Subsystem failure: 'MT'" "mtex.c, line 431, thread 19286, proc id 6116, No Exception Handler." ' 10:43:26 invoke_alarm(): mt_exec failed, status 127, errno 0 10:43:27 The Master Daemon Died 10:43:27 PANIC: Attempting to bring system down ____________________________________ Dear All, Unfortunately I am experiencing database crashes with the above message. I am using IDS 9.4 UC2. I have raised this issue to IBM support and they mentioned that I have to upgrade to 9.4 UC9, as a bug causing these crashes. Can anyone help me from where I can get the patches to upgrade from UC2 to UC9. Second thing when I restart the database the number of server connections starts as 25 and start increasing by the time, this number never decreases no matter the volume of transaction is low or high. Is this normal or the number of server connection should be decreased during the Low volume of transaction and increases during peak hours. I shall highly be obliged if anyone can suggest any remedies to rectify the situation. Thanks and regards
SYED ALI wrote: > 10:39:06 Maximum server connections 66 > 10:43:08 Assert Failed: No Exception Handler > 10:43:08 IBM Informix Dynamic Server Version 9.40.UC2 > 10:43:08 Who: Session(17517, swx@ATMSWPROD2, -1, 4b2374d8) > > Thread(19286, sqlexec, 4b219aa8, 1) > > File: mtex.c Line: 431 > 10:43:08 Results: Exception Caught. Type: MT_EX_OS, Context: mem > 10:43:08 Action: Please notify IBM Informix Technical Support. > 10:43:08 stack trace for pid 6116 written to /tmp/af.4f3ee58b > 10:43:08 See Also: /tmp/af.4f3ee58b, shmem.4f3ee58b.0 > 10:43:26 Error writing '/tmp/shmem.4f3ee58b.0' errno = 28 > 10:43:26 mtex.c, line 431, thread 19286, proc id 6116, No Exception Handler. > 10:43:26 invoke_alarm(): /bin/sh -c '/appl/informix/etc/log_full.sh 5 6 > "Internal Subsystem failure: 'MT'" "mtex.c, line 431, thread 19286, proc id > 6116, No Exception Handler." ' > 10:43:26 invoke_alarm(): mt_exec failed, status 127, errno 0 > 10:43:27 The Master Daemon Died > 10:43:27 PANIC: Attempting to bring system down > ____________________________________ > Dear All, > Unfortunately I am experiencing database crashes with the above message. I am > using IDS 9.4 UC2. I have raised this issue to IBM support and they mentioned > that I have to upgrade to 9.4 UC9, as a bug causing these crashes. Can anyone > help me from where I can get the patches to upgrade from UC2 to UC9. > If you have a valid support contract, then IBM Tech support will happily send you a CD/DVD with the appropriate release or place them on an FTP site to which they will give you access so that you can download the files. If you do not have support, then you will likely have to renew your support agreements. > Second thing when I restart the database the number of server connections > starts as 25 and start increasing by the time, this number never decreases no > matter the volume of transaction is low or high. Is this normal or the number > of server connection should be decreased during the Low volume of transaction > and increases during peak hours. > I shall highly be obliged if anyone can suggest any remedies to rectify the > situation. > The number of connections is not dependent on the transaction volume, but on the number of connections requested and maintained by clients. If the number of running clients is not increasing over time, then it is likely that you have some poorly written applications that are creating connections and never releasing them. This is a common problem with Object Oriented applications that are written by developers not knowledgeable with developing for a connection oriented data store. Look for thread initialization functions or class constructors that create connections for every connection or object of a class that is created and only drop the connection in the destructor for that class. There rather should be a single master connection or a pool of connections created in a static instance of some supertype that is inherited by all classes that need access to Informix data and passed among all threads of execution as needed. Then there will be only a single connection, or a planned and controlled pool of <N> connections, shared by all objects and threads. Art S. Kagel Oninit > Thanks and regards > ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========
my thoughts are in alignment with Art's. if your IDS software came from IBM, you have to go through their support for the patch. if your IDS is running under something like SAP, and you got IDS with your SAP agreement, you'd put in an SAP OSS ticket and ask for the patch. Either way, your support agreement needs to be current. Additional thoughts on your connections not going away... if you are running under some big app like SAP, you'd have to go into the app and kill connections and/or bounce the app to reset connections (be they memory hogs or what have you, they won't go away unless u bounce (stop/start)...and then of course when u start the app, the connections will come back).
Thanks a lot to Art S. Kagel,NORMA JEAN SEBASTIAN for their usual support.