Re: OnBar Opinions & Experiences from Experienced Users (Administrators) Wanted: Is OnBar Stable?

Terry: We are in the process of installing the same environment. A gotcha that you should be aware of occurs when you allow onBAR to run multithreaded. If the system is doing a checkpoint, you can get into a situation where the ODS does not exit out of the CkPT. You will need to do an onmode -yuk to clear the problem. We are in the process of testing on using a single thread. Here Informix's description of the problem: "Bug: 89810 ONBAR -B -L 0 HANGS SYSTEM IN CHECKPOINT REQUEST BLOCKED:CKPT ARCHIVE WITH ONE SESSION HAVING C-A-X-- FLAGS Description: While doing a whole system backup with onbar -b -L 0, onbar first backups all critical dbspaces. After that it forks child processe for each non-critical dbspace to backup. For every page this threads are copying to the transport buffer, they are calling the function arc_sync_backup, which checks if currently a checkpoint is done. If so, they are calling cond_mt_wait to wait until this checkpoint finishes to precede with backup. Before they are calling mt_wait, they reset their critical section flags to allow checkpoint to be done. After checkpoint has finished (function checkpoint in rsrecvr.c) it resets critical section flags for every archive session. This is ok most of the time. But under certain conditions, if two archive threads are entering mt_wait in arc_sync_backup at the same time, only one of this sessions comes back from mt_wait and precedes with backup. The other session still waits for completion of checkpoint. At this point, checkpoint session resets critical section flags for all archive session - a deadlock situation occurs. While the session is still in mt_wait and waiting for the checkpoint to complete, it gets critical session flags set so that the next checkpoint can not go through, because it does not come beyond the function wait4critex." SteveR Terry R. Gauchat wrote: > Greetings fellow DBAs (etc!): > > Our shop is 7.23 IDS Informix, Solaris, and Legato Networker. > I am testing OnBar and planning its deployment (currently we do local > backups using OnTape). > > On the surface, OnBar looks great -- fast backup performance (with a little > tuning effort), and integrates reasonably well with Networker. I've just > about got the whole "backup strategy" worked out. > > One major snag, however -- Restore tests have not worked consistently. I now > fear I can't trust OnBar. > Depending on the situation, I get various errors from Informix and/or > Networker. > > One major requirement is the so-called "imported restore"; i.e., we need to > be able to restore any of our routine fast parallel onbar backups to an > entirely new environment, in the event that the source environment is lost > in a disaster (e.g., fire). > > Somewhat "officially", Informix implies that this is not possible unless the > "onbar -b -w" command is used (i.e., slow serial whole-instance backup). And > I've heard rumors from within Legato that they have trouble supporting the > "whole-instance" restore function "onbar -r -w"). And my "onbar -r -w" > experiences have been as mixed as with other onbar commands. > > >From testing, I have learned enough about the onbar architecture to show it > can do more than implied in the very thin documentation from Informix and > Networker. But because this is not documented, I am forced to live with > uncertainty and surprises (such as "rootdbs not from same archive version as > physdbs" error messages -- a problem which also exists with OnArchive...!). > > HENCE MY SEARCH AND PLEA! -- Are there any experienced OnBar users out there > willing to share their experiences? Have you tested various types of backups > and restores (whole, PIT, partial, etc.!)? Do you have a similar environment > (Sun/Networker)? Did you have to expand the documentation and develop > work-arounds? Did you just GIVE-UP on OnBar? Or did you trust it without > doing extensive restore testing? > > Your comments would be of tremendous support in my effort to deploy (or > discharge!) OnBar. > > Thanks a gig! > > ...Terry. > tgauchat@jps.net -- ----------------------------------------------------------------- Steve Romankiw + Executive Risk Inc. + DBA + email: sromankiw@execrisk.com 82 Hopmeadow Street + work: (860) 408-2474 Simsbury,CT 06070 + fax: (860) 408-2139 -----------------------------------------------------------------