ontape -c

We have large logical logs and they don't fill up very quickly. Therefore, it's not very often that ontape -c backs them up. In fact it's been 24 hours and we still haven't filled up this one logical log. I guess this makes me a little nervous, in the event of a crash, that I would be able to do a restore up to the minute. I know that ontape -r will try and do a log salvage, but if there's a catastrophic crash, then it wouldn't be able to and I'd lose a days worth of processing. Any thoughts? I guess I could always make the logs shorter, but wouldn't this make long transactions more common on days when we are doing some large batch processing?

Top Cat wrote: > > We have large logical logs and they don't fill up very quickly. Therefore, > it's not very often that ontape -c backs them up. In fact it's been 24 > hours and we still haven't filled up this one logical log. I guess this > makes me a little nervous, in the event of a crash, that I would be able to > do a restore up to the minute. I know that ontape -r will try and do a log > salvage, but if there's a catastrophic crash, then it wouldn't be able to > and I'd lose a days worth of processing. Any thoughts? I guess I could > always make the logs shorter, but wouldn't this make long transactions more > common on days when we are doing some large batch processing? No. It is the log size times the number of logical logs that determines how large of a transaction can be handled without a Long Transaction rollback being triggered (along with the volume of other transactions of course) not the size of each log. So if you have 5 500MB log files you can safely replace them with 25 100MB log files. Just note that with smaller log file sizes it is VERY important to set LBU_PRESERVE which can be ignored if you have huge log size. Note also that you can run ontape -a periodically during the day to improve your recoverability. You will have to stop ontape -c to do so and change the tape, though. Doing this it is more convenient to make the log backups to a disk file and push that file to tape immediately after it is completed which may mean using the ALARMPROGRAM rather than ontape -c to backup full logs. See utils3_ak in the IIUG Software Repository for two examples of how to do this. Art S. Kagel

In article <38038ECD.57A46361@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes >Top Cat wrote: >> >> We have large logical logs and they don't fill up very quickly. Therefore, >> it's not very often that ontape -c backs them up. In fact it's been 24 >> hours and we still haven't filled up this one logical log. I guess this >> makes me a little nervous, in the event of a crash, that I would be able to >> do a restore up to the minute. I know that ontape -r will try and do a log >> salvage, but if there's a catastrophic crash, then it wouldn't be able to >> and I'd lose a days worth of processing. Any thoughts? I guess I could >> always make the logs shorter, but wouldn't this make long transactions more >> common on days when we are doing some large batch processing? > >No. It is the log size times the number of logical logs that determines >how large of a transaction can be handled without a Long Transaction >rollback being triggered (along with the volume of other transactions of >course) not the size of each log. So if you have 5 500MB log files you >can safely replace them with 25 100MB log files. Just note that with >smaller log file sizes it is VERY important to set LBU_PRESERVE which can >be ignored if you have huge log size. > remember you can have update 32767 logical logs and the smallest size is 250Kb. I normally have 1000 250Kb logical logs. >Note also that you can run ontape -a periodically during the day to >improve your recoverability. You will have to stop ontape -c to do so and >change the tape, though. Doing this it is more convenient to make the >log backups to a disk file and push that file to tape immediately after it >is completed which may mean using the ALARMPROGRAM rather than ontape -c >to backup full logs. See utils3_ak in the IIUG Software Repository for >two examples of how to do this. > >Art S. Kagel -- David Williams

Top Cat (cstefanick@ocsmgmt.com) wrote: : We have large logical logs and they don't fill up very quickly. Therefore, : it's not very often that ontape -c backs them up. In fact it's been 24 : hours and we still haven't filled up this one logical log. I guess this : makes me a little nervous, in the event of a crash, that I would be able to : do a restore up to the minute. I know that ontape -r will try and do a log : salvage, but if there's a catastrophic crash, then it wouldn't be able to : and I'd lose a days worth of processing. Any thoughts? I guess I could : always make the logs shorter, but wouldn't this make long transactions more : common on days when we are doing some large batch processing? As Art has already pointed out, it is the total space of the logs that determine long transactions. I have heard recommendations such as "you should fill up a log every two hours of normal transaction periods" with the two hours number actually changing depending on the recoverability desired. Also of note, I think, is that if you are using replication there is overhead associated with filling up a log file. -- Rob Wilson rwilson@ntsource.com

David Williams wrote: > > In article <38038ECD.57A46361@bloomberg.net>, Art S. Kagel > <kagel@bloomberg.net> writes > >Top Cat wrote: > >> [SNIP] > remember you can have update 32767 logical logs and the smallest size > is 250Kb. I normally have 1000 250Kb logical logs. [SNIP] Whoa! I thought I have lots of logs with 75 of them. Good thing you don't run on DG/UX M99K, David, it takes so long to attach to shared memory (OS problem) that it can take ever a minute to add one log file. It used to take me almost an hour and a half to create 75 logs before we moved to Solaris and DG/UX Pentium. I shudder at how long 1000 logs would take there. :-) > David Williams Art S. Kagel