Re: Logical logs

Art, I am planning to keep LTXHWM,LTXEHWM as 50 & 60. I will increase the no. of logs from 80 to 160. We have 2 dbspaces for logs. Do you suggest any sequence to add logs like add log to logdbs1 add log to logdbs2 add log to logdbs1 add log to logdbs2 add log to logdbs1 add log to logdbs2 add log to logdbs1 add log to logdbs2 or add 40 logs to logdbs1 add 40 logs to logdbs2 Thanks very much for your advice Vinod >From: "Art S. Kagel" <kagel@bloomberg.net> >Reply-To: kagel@bloomberg.net >To: informix-list@iiug.org >Subject: Re: Logical logs >Date: Wed, 24 May 2000 12:35:22 -0400 > >BAD IDEA to modify LTXHWM and LTXEHWM unless you also have LBU_PRESERVE and >a VERY large total logical log size. Otherwise instead of more frequent >long transaction rollbacks you may find your engine hung by an unusually >long transaction rollback that fills the remaining logical logs EVEN after >pausing all other transactions. Informix originally used 80 & 90 as the >defaults but they were getting so many tech calls to help recover from >hung instances with not enough log space left to even archive the logs that >they changed the default and recommended values to 50 & 60. > >Art S. Kagel > >Girish Punjabi wrote: > > > > HI Vinodh, > > > > Nothing wrong with more logical logs except that is is inefficient from > > an administrative point of view. > > Instead of having 120 logical logs of 2MB each you can have 30 logs of > > 8MB each.You can also set LTXHWM & LTXEHWM are 80 and 90 > > respectively.We have overcome the long transaction problem here by > > deviating from Informix suggested values of 50 and 60. > > Also , as William suggested, you need to have a look at the code as > > well , as no amount of tuning can help if the code is inefficient. > > > > In article <8ge25v$s64$1@news.xmission.com>, > > William Rice <ricew@operamail.com> wrote: > > > > > > I do not feel their is anything wrong with having that many logical > > logs. > > > One thing you might want to establish is why you are having long > > transactions > > > and whether or not what is being done is required to be one > > transaction. > > > > > > If the cause is a process which is required to be updated in one > > transaction > > > you have no choice but to increase the number of logs. > > > > > > If the cause of the long transactions is a purge or something of that > > nature, > > > which can be done in smaller increments without effecting the > > validity of the > > > data, you might want to look into making the purge use a select cursor > > > and deleting each record and committing periodically.(If their is a > > better way > > > to do this I would love to hear it.) If you just increase the number > > of logs, > > > as > > > the amount of data purged grows, the likelihood of hitting a long > > transaction > > > again grows. A program which commits at regular intervals bypasses > > > these emergencies. > > > > > > If the cause of the long transactions is a lock held for an > > inordinate period > > > of time, it might be worth implementing some sort of timing mechanism > > > to cause the user to abort after holding a lock for some period of > > time, > > > or rewriting the application to not hold locks while waiting for user > > input. > > > > > > Hope this helps, > > > Will > > > >===== Original Message From "Vinod Bhansali" <iiug@hotmail.com> ===== > > > >In our system, I am noticing Long Transactions being caused > > sometimes. We > > > >have 80 log files, each of size 2048. LTXHWM & LTXEHWM are 50 & 60. > > I don't > > > >want to increase them. I am planning to increase the no. of log > > files to 120 > > > >or to 160. Are there any pros and cons of having more no. of logical > > log > > > >files. We have continuous logical log backup running and we take > > zero level > > > >db backup daily using ontape. > > > > > > > >Thanks in advance > > > >Vinod Bhansali > > > > > >_______________________________________________________________________ > > _ > > > >Get Your Private, Free E-mail from MSN Hotmail at > > http://www.hotmail.com > > > > > > ------------------------------------------------------------ > > > This e-mail has been sent to you courtesy of OperaMail, as a free > > service from > > > Opera Software, makers of the award-winning Web Browser, Opera. > > Visit us at > > > http://www.opera.com/ or our portal at: http://www.myopera.com/ Your > > free e-mail > > > account is waiting at: http://www.operamail.com/ > > > ------------------------------------------------------------ > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

If you are using any of the schemes that archive the log files as they are completed, ie ontape -c, or using the ALARMPROGRAM, then alternate the logs on the drives so that you are not reading the last log and writing the next one to the same device. Art S. Kagel Vinod Bhansali wrote: > > Art, > > I am planning to keep LTXHWM,LTXEHWM as 50 & 60. I will increase the no. of > logs from 80 to 160. > > We have 2 dbspaces for logs. Do you suggest any sequence to add logs like > add log to logdbs1 > add log to logdbs2 > add log to logdbs1 > add log to logdbs2 > add log to logdbs1 > add log to logdbs2 > add log to logdbs1 > add log to logdbs2 > > or > add 40 logs to logdbs1 > add 40 logs to logdbs2 > > Thanks very much for your advice > > Vinod > > >From: "Art S. Kagel" <kagel@bloomberg.net> > >Reply-To: kagel@bloomberg.net > >To: informix-list@iiug.org > >Subject: Re: Logical logs > >Date: Wed, 24 May 2000 12:35:22 -0400 > > > >BAD IDEA to modify LTXHWM and LTXEHWM unless you also have LBU_PRESERVE and > >a VERY large total logical log size. Otherwise instead of more frequent > >long transaction rollbacks you may find your engine hung by an unusually > >long transaction rollback that fills the remaining logical logs EVEN after > >pausing all other transactions. Informix originally used 80 & 90 as the > >defaults but they were getting so many tech calls to help recover from > >hung instances with not enough log space left to even archive the logs that > >they changed the default and recommended values to 50 & 60. > > > >Art S. Kagel > > > >Girish Punjabi wrote: > > > > > > HI Vinodh, > > > > > > Nothing wrong with more logical logs except that is is inefficient from > > > an administrative point of view. > > > Instead of having 120 logical logs of 2MB each you can have 30 logs of > > > 8MB each.You can also set LTXHWM & LTXEHWM are 80 and 90 > > > respectively.We have overcome the long transaction problem here by > > > deviating from Informix suggested values of 50 and 60. > > > Also , as William suggested, you need to have a look at the code as > > > well , as no amount of tuning can help if the code is inefficient. > > > > > > In article <8ge25v$s64$1@news.xmission.com>, > > > William Rice <ricew@operamail.com> wrote: > > > > > > > > I do not feel their is anything wrong with having that many logical > > > logs. > > > > One thing you might want to establish is why you are having long > > > transactions > > > > and whether or not what is being done is required to be one > > > transaction. > > > > > > > > If the cause is a process which is required to be updated in one > > > transaction > > > > you have no choice but to increase the number of logs. > > > > > > > > If the cause of the long transactions is a purge or something of that > > > nature, > > > > which can be done in smaller increments without effecting the > > > validity of the > > > > data, you might want to look into making the purge use a select cursor > > > > and deleting each record and committing periodically.(If their is a > > > better way > > > > to do this I would love to hear it.) If you just increase the number > > > of logs, > > > > as > > > > the amount of data purged grows, the likelihood of hitting a long > > > transaction > > > > again grows. A program which commits at regular intervals bypasses > > > > these emergencies. > > > > > > > > If the cause of the long transactions is a lock held for an > > > inordinate period > > > > of time, it might be worth implementing some sort of timing mechanism > > > > to cause the user to abort after holding a lock for some period of > > > time, > > > > or rewriting the application to not hold locks while waiting for user > > > input. > > > > > > > > Hope this helps, > > > > Will > > > > >===== Original Message From "Vinod Bhansali" <iiug@hotmail.com> ===== > > > > >In our system, I am noticing Long Transactions being caused > > > sometimes. We > > > > >have 80 log files, each of size 2048. LTXHWM & LTXEHWM are 50 & 60. > > > I don't > > > > >want to increase them. I am planning to increase the no. of log > > > files to 120 > > > > >or to 160. Are there any pros and cons of having more no. of logical > > > log > > > > >files. We have continuous logical log backup running and we take > > > zero level > > > > >db backup daily using ontape. > > > > > > > > > >Thanks in advance > > > > >Vinod Bhansali > > > > > > > >_______________________________________________________________________ > > > _ > > > > >Get Your Private, Free E-mail from MSN Hotmail at > > > http://www.hotmail.com > > > > > > > > ------------------------------------------------------------ > > > > This e-mail has been sent to you courtesy of OperaMail, as a free > > > service from > > > > Opera Software, makers of the award-winning Web Browser, Opera. > > > Visit us at > > > > http://www.opera.com/ or our portal at: http://www.myopera.com/ Your > > > free e-mail > > > > account is waiting at: http://www.operamail.com/ > > > > ------------------------------------------------------------ > > > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com