RE: Performance problem - Informix,cgi-webdriver,HP-UX
Posted in 1999
Topics: Performance & Tuning, Storage & Space Management, Logging & Checkpoints, Platform-Specific Issues
The only suggestions I might make which I haven't already seen made are. >PHYSDBS rootdbs # Location (dbspace) of physical log You might put this in a different dbspace on a different disk than rootdbs, and llogdbs . >LBU_PRESERVE 0 # Preserve last log for log backup LBU_PRESERVE 1 This has nothing to do with performance, and may cause you problems due to how few logical logs you have, but it makes recovering from running out of logical log space a much more friendly experience. This way you can add logs. If you do not have LBU_PRESERVER and you run out of logical logs, you can not just add a log and continue. Recovering from that state is a bit more of a complex preocess. The reason this is possible is LBU_PRESERVE saves the last logical log for administrative purposes, meaning itis easier to run out of logs for data processing, but you have more options when you do. If you were willing to break that into 100 logical logs of 1/10th the size then the chances of filling up the logs because you saved the last one for administrative tasks is much much less Hope this helps Will Rice ------------------------------------------------------------ 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/ ------------------------------------------------------------
William Rice wrote: > > The only suggestions I might make which I haven't already seen made > are. > > >PHYSDBS rootdbs # Location (dbspace) of physical log > You might put this in a different dbspace on a different disk than rootdbs, > and llogdbs . > > >LBU_PRESERVE 0 # Preserve last log for log backup > LBU_PRESERVE 1 > This has nothing to do with performance, and may cause you problems > due to how few logical logs you have, but it makes recovering from > running out of logical log space a much more friendly experience. This way > you can add logs. If you do not have LBU_PRESERVER and you run > out of logical logs, you can not just add a log and continue. Recovering > from that state is a bit more of a complex preocess. The reason this is > possible is LBU_PRESERVE saves the last logical log for administrative > purposes, meaning itis easier to run out of logs for data processing, but > you have more options when you do. > > If you were willing to break that into 100 logical logs of 1/10th the size > then the chances of filling up the logs because you saved the last one > for administrative tasks is much much less You can always add just one more log file to compensate for LBU_PRESERVE. An obvious, but, often overlooked solution to the LBU_PRESERVE dilemma. Art S. Kagel