Re: Logical log sizing

"Carlson@WHSmith" wrote: > > "Art S. Kagel" wrote: > > > > If you were not throwing your log files away one issue affecting the choice > > of log size would be the granularity at which you want to be able to archive > > the logs and the number of transactions you are willing to lose if the log > > drives crash hard (of course they should be mirrored but we always hope for > > the best and plan for the worst). Since you are tossing your logs into the > > bit bucket it really does not matter. I'd probably lean toward configuring > > 55 50MB log files to get 2.75GB of logs (to allow for long transactions, cut > > this to 26->30 logfiles if you already allowed for that). > > > > Art S. Kagel > > > > So then conventional wisdom is to backup early and often when keeping More or less. You evaluate how quickly you will fill a particularly sized logfile and determine what level of risk you are willing to live with. If your llogdb is mirrored you can live with a larger risk of total disaster since it is less likely, though still not impossible (vendor maintenance tech knocks a cup of coffee into the drive cabinet). > transaction logs? Makes sense then to create smaller logical log Yes, but with consideration for the next thing you mention... > files. How small should one go and how would this affect performance? The more archive activity the more system impact. Like everything else in our domain it is a trade off. > My guess is that performance would be affected a bit like LRU writes vs. > checkpoint writes in this area; a little bit all along as opposed to the > big write after a 10MB (or so) log file gets written to tape or disk. Correct. > BTW, I'd like to fully implement transaction logging . . . . . just need > a way around that onstat -c (dedicated terminal) requirement. I find that using the SYSALARMPROGRAM solved this dilemma for me. Get my utils3_ak which contains a shell script, like logs_full.sh but using ontape instead of onbar, and C program that will backup your logs to disk, using ontape, and even gzip the files in addition to handling many other system events by emailing you when there is trouble. For us we have duplicate machines for every server so we live with sweeping the log backup files to tape daily and cleaning the directory of any file older than seven days with a cron job. If you want more safety it is trivial to modify either logs_full.sh or eventalarm.c to also trigger a copy to tape of the new log archive file or an rcp to another machine (I actually do this on one system using a cron job that wakes every 5 minutes and sweeps any new log archive files to the backup machine). Art S. Kagel