Re: Informix SE
On Tue, 28 Nov 2000, Aletha D. Chrietzberg wrote: >Can anyone give me a little help on this? I am not an Informix DB, >just an admin. I have asked my Informix friends but no one knows. > >We are running the SE version on AIX platform but when we go to >shutdown informix which should as I understand it should only require >killing the sqlexecd daemon, the port (1526) is still considered in >use. I did go check out the script that someone wrote and they are >also killing the rest of the sqlexec processes. I cannot get the port >released unless I reboot the system which is what our vendor suggested >with no alternatives. I need to avoid rebooting if at all possible. >We are now moving into a HACMP environment so this is really going to >present a problem. > >Any help would be greatly appreciated if anyone has resolved this one.. On Solaris, there's a netstat utility that tells you something of what is going on in terms of network activity. Is there an equivalent in AIX? What does it tell you? Killing sqlexecd is an important step. Not killing sqlexec processes is another important step -- you can screw up an SE database very quickly if you kill sqlexec processes. Since the sqlexec processes are forked from the sqlexecd process, it is quite likely that they have the port in use, even though they spend most of their time talking to the client on another port. So, it is not impossible that you will need to clean up the sqlexec processes after all. Just be very careful and gentle about it. The first signal to try is SIGPIPE. Then SIGTERM and SIGHUP. Don't use SIGKILL except under extreme duress, and not until after giving the process to wind up its activities if at all possible. Killing an sqlexec that is in the middle of a TX means you should do a ROLLFORWARD DATABASE from a backup before allowing anyone to restart using the database. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"
Thanks Jonathan, They are performing a kill -9 on the follow up sqlexec processes. Then when we start up again the vendor had me put this statement into the script to release record locks: echo "DELETE FROM rowlock" | isql hospital I don't know if any ROLLFORWARD's are being performed or not since I don't know about that. I will go change the signal to 13 or 15 as you stated on the kill statement for the killing of the user's sqlexec processes. With HACMP we need this to shutdown rather quickly for failovers. Will the signal 13 or 15 stop these quickly or is this a variable? Thanks for your input. Any further info would be appreciated. Jonathan Leffler wrote: > On Tue, 28 Nov 2000, Aletha D. Chrietzberg wrote: > > >Can anyone give me a little help on this? I am not an Informix DB, > >just an admin. I have asked my Informix friends but no one knows. > > > >We are running the SE version on AIX platform but when we go to > >shutdown informix which should as I understand it should only require > >killing the sqlexecd daemon, the port (1526) is still considered in > >use. I did go check out the script that someone wrote and they are > >also killing the rest of the sqlexec processes. I cannot get the port > >released unless I reboot the system which is what our vendor suggested > >with no alternatives. I need to avoid rebooting if at all possible. > >We are now moving into a HACMP environment so this is really going to > >present a problem. > > > >Any help would be greatly appreciated if anyone has resolved this one.. > > On Solaris, there's a netstat utility that tells you something of what > is going on in terms of network activity. Is there an equivalent in > AIX? What does it tell you? > > Killing sqlexecd is an important step. Not killing sqlexec processes is > another important step -- you can screw up an SE database very quickly > if you kill sqlexec processes. Since the sqlexec processes are forked > from the sqlexecd process, it is quite likely that they have the port in > use, even though they spend most of their time talking to the client on > another port. So, it is not impossible that you will need to clean up > the sqlexec processes after all. Just be very careful and gentle about > it. The first signal to try is SIGPIPE. Then SIGTERM and SIGHUP. > Don't use SIGKILL except under extreme duress, and not until after > giving the process to wind up its activities if at all possible. > Killing an sqlexec that is in the middle of a TX means you should do a > ROLLFORWARD DATABASE from a backup before allowing anyone to restart > using the database. > > -- > Yours, > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > "I don't suffer from insanity; I enjoy every minute of it!" -- ----------------------------------------------------- Click here for Free Video!! http://www.gohip.com/free_video/
"Aletha D. Chrietzberg" wrote: > Thanks Jonathan, > They are performing a kill -9 on the follow up sqlexec processes. Ouch! > Then when we start up again the vendor had me put this statement > into the script to release record locks: > > echo "DELETE FROM rowlock" | isql hospital Well, that's an application-specific table; Informix does not have a rowlock table and therefore cannot know how to release those locks. Further, any tools such as DB-Access won't know how to respect those locks, so there could be unexpected changes if someone does change the data behind the scenes while something thinks it has a lock on it via the rowlock table. Just a warning... > I don't know if any ROLLFORWARD's are being performed or not since I don't > know about that. OK. If you have a transaction log, and if the sqlexec is killed part way through a transaction, then the data that has been written will effectively be committed, even though the transaction is not complete. [If you don't like that (I don't), then you need OnLine and not SE] If you do a ROLLFORWARD, then those uncommitted transactions should be backed out of the database by the recovery process. > I will go change the signal to 13 or 15 as you stated on > the kill statement for the killing of the user's sqlexec processes. With > HACMP we need this to shutdown rather quickly for failovers. Will the > signal 13 or 15 stop these quickly or is this a variable? It depends on what the sqlexec process is doing at the time. If it is waiting for information from the application, it will be quick. If it is part way through rewriting an index file, it might be rather slow. But did you really want the failover to corrupt your database? Killing sqlexec before it is ready is likely to corrupt your database, which is seldom desirable. > Thanks for your input. Any further info would be appreciated. > > Jonathan Leffler wrote: > > On Tue, 28 Nov 2000, Aletha D. Chrietzberg wrote: > > >Can anyone give me a little help on this? I am not an Informix DB, > > >just an admin. I have asked my Informix friends but no one knows. > > > > > >We are running the SE version on AIX platform but when we go to > > >shutdown informix which should as I understand it should only require > > >killing the sqlexecd daemon, the port (1526) is still considered in > > >use. I did go check out the script that someone wrote and they are > > >also killing the rest of the sqlexec processes. I cannot get the port > > >released unless I reboot the system which is what our vendor suggested > > >with no alternatives. I need to avoid rebooting if at all possible. > > >We are now moving into a HACMP environment so this is really going to > > >present a problem. > > > > > >Any help would be greatly appreciated if anyone has resolved this one.. > > > > On Solaris, there's a netstat utility that tells you something of what > > is going on in terms of network activity. Is there an equivalent in > > AIX? What does it tell you? > > > > Killing sqlexecd is an important step. Not killing sqlexec processes is > > another important step -- you can screw up an SE database very quickly > > if you kill sqlexec processes. Since the sqlexec processes are forked > > from the sqlexecd process, it is quite likely that they have the port in > > use, even though they spend most of their time talking to the client on > > another port. So, it is not impossible that you will need to clean up > > the sqlexec processes after all. Just be very careful and gentle about > > it. The first signal to try is SIGPIPE. Then SIGTERM and SIGHUP. > > Don't use SIGKILL except under extreme duress, and not until after > > giving the process to wind up its activities if at all possible. > > Killing an sqlexec that is in the middle of a TX means you should do a > > ROLLFORWARD DATABASE from a backup before allowing anyone to restart > > using the database. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"