Re: Whence cometh these log backups?

Can you describe exactly what you mean by "break continuous logging" and what reason that is done for anyway? Also, please describe exactly how the archive is triggered (hopefully forground on command line, ie no background processes - ditto for the continuous logging) NOTE: unless you have to share a tape drive, there is now reason and a few counter reasons for pulling the log tapes just because you are doing an archive. There are a few issues regarding log sizes etc but it is entirely possible and preferable to get archiving done on a live system during business hours (ie when there are people around!) and while the log tapes are still doing their thing. Assuming you don't wanna use onbar - something I admit to being too lazy to have a go at yet! Neil Truby wrote in message <8vc8ul$k3b$1@taliesin2.netcom.net.uk>... >IDS 9.20 on HP-UX 11.0 > >A funny thing has started happening to three out of my four production >servers. The Ops break continuous logging each night and do a level 0 >archive. When they come to re-start the logging, it fails saying that a log >backup is already in progress. And so it is! Tracing back from onstat -u >it turns out that an onbar process is running. We do not use and never have >used ohnbar. What is starting them up - any ideas?

Andrew Hamm <ahamm@sanderson.net.au> wrote in message news:3a19fff1$1@news.iprimus.com.au... > Can you describe exactly what you mean by "break continuous logging" and > what reason that is done for anyway? Because there are four Informix instances on the UNIX server and we have only four DAT drives (and a DLT stacker). The archive of one instance goes to DLT but the other three go to DAT, hence the need to break logging (by that I mean interrupt the currently-running ontape -c, initiated previously as a foreground command). Incidentally, I also break the logging and switch tapes each night on the instance that archives to DLT (where there is no need to do so). This means that I am less susceptible to a single tape failure which might contain many days' logs, and that if I did need to do a roll-forward I wouldn't have to wait while multiple days' logs are bypassed before the correct section of tape is found. I'd be interested to hear the counter-reasons for regularly switching logical logging tapes. Finally, at clients where there is not 24x7 Ops cover I have successfully used scripted logging and archiving (ie not foreground command line), using variants of the iiug archives, and have not found them particularly troublesome (except of course using onarchive!). Neil

Neil Truby wrote in message <8vddb8$oqs$1@taliesin2.netcom.net.uk>... >I'd be interested to hear the counter-reasons for regularly >switching logical logging tapes. No reasons beyond possible people problems. Your reasons are well-considered and you have a valid reason to do what you do and you sound like you know why and how. When I say people problems, I am mainly concerned at customer sites to get the damned things happening regularly! So I far prefer to make it a day-time job, ideally I get one of the really solid citizens in the clerical staff to do the job - I jokingly say a really boring, methodical person is ideal, but it's not really a joke. Such a person is ideal to trust with doing it faithfully every day, faithfully writing down the log numbers etc. In order for archives to have no impact (i'm talking freezeouts and/or serious performance hits here), part of the background requirement is to ensure that the physical and logical logs are of the right size and number, and of course to pick a decent time of day, and a suitable "slow" day for the level zero's. In terms of when to swap the log tapes themselves, I guess the main question is how long it would take to spin thru a day or week's worth of logs, and you've made a decision about that. But this of course has nothing to do with your problem! I was just checking that you are doing the right thing before I weigh in with solemn lectures about doing the right thing. It sounds REALLY like a bug in the engine, doesn't it? We've only very casually touched on the 9.XX engines here, so I can't answer, but I have noted that a few people-in-the-know are saying that 9.2X has known defects and generally you should upgrade to the later versions. 9.3X ?? I'm not all that familiar with the numbers there. I do know we had the odd problem with the 7.2X engine; the same problem at a few sites, and we have upgraded them to 7.31 which is a known quantity - a better engine which I'm very happy with. I understand that the 9.2X engines are based on the 7.2X source, so that's a hint that it would have the same weaknesses that people have experienced. Have you talked directly to Informix support? That's where I'd be going with this kind of problem. I'd really be interested to hear the final answer too. PS - background archiving disturbs me merely because Informix tells us not to do it (for the reasons they list in the books). We have had to ask Informix to repair a few dead sites over the years, and I'd hate them to wash their hands of a recovery because we didn't follow their rules. I know they would wash their hands in certain circumstances because they are very concerned about liability if they get involved in repair work.