Re: Onbar - some advice please

Hi, generally I recommend a newer release of 9.40 (i.e. 9.40.xC4 or the current 9.40.xC5) rather than any 9.30 release. These 9.40 releases all support PIT (point-in-time) restores. To be honest, there is still a known problem in these releases, but that can be seen only when doing PIT restores REPEATEDLY. Doing PIT restores repeatedly creates a host of problems that do not exist otherwise. We call them collectively "time travel problems". Please see below for more information on these scenarios. These time travel problems will be fixed in the next major version, due out in Q1/05. To somewhat avoid the time travel problems, it helps to make a backup of the ON-Bar bootstrap file ($INFORMIXDIR/etc/ixbar.<servernum>) often, at least ever time you do a dbspace backup. Before starting a restore you would then first restore the bootstrap file that contains info about all the logical log files necessary for the desired PIT restore (i.e. was backed up closest to the desired PIT). This can minimize time travel problems. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Data Management Solutions [ Time Travel Problems: Consider the following scenario (use monospace font): ------+--------+------------+-------------+-------------> time t1 t2 t3 t4 --+-------+------------+-------| log backup l1 l2 l3 restore to PIT t2 and continue working: t2 --+-------+----+ (log restore) l1 l2 | +................----+--------> new log backup l3' Now we have 2 logs with unique id 3 backed up, l3 and l3'. It becomes clear that now the log unique id is no longer unique. A new restore (without PIT) will not be a problem, as we simply use the newest logs (i.e. l3') for restore. But again doing a PIT restore, e.g. to t3 will pose the question of which log 3 to use: l3 or l3' ? While from the picture above it is easy to see, that for a restore to t3 l3 must be used (and not l3'), this cannot be easily decided from the log unique id (as it is no longer unique). And this is exactly where the time travel problem starts as you have already travelled back in time with the previous PIT restore. Each PIT restore will add to the problem by opening a new "time line" of backed up logs. Fixing these problems needed the implementation of a robust method to keep apart the different logs that have all the same unique log id. It required changes in the format of the boots trap file, the sysutils database and in internal algorithms. Therefore this solution cannot be backported to older releases and hence will be available with the next (new) version only. Hmm. Explaining this in plain text is kind of difficult. At least I tried. I hope that it answers a question or two (and not opens up too many new questions). ] -- owner-informix-list@iiug.org wrote on 20.12.2004 21:58:26: > I have a number of customers who really need to use onbar. They need > point-in-time recovery, parallel backups, and parallel restores. I have > been trying to get information from IBM/Informix on this but am held at > arms length by a distributor who isn't answering my questions. > My questions are:- > Is there a stable 9.3 release which supports point-in-time restore? > Is there a stable 9.4 release which supports point-in-time restore? > One of my customers had need of point-in-time recently and it failed. > IBM/Informix recommended that we upgrade to 9.40.FC5 as that fixed a > problem with onbar. Unfortunately the bug that was fixed in 9.40.FC5 > is not the same scenario as my customer. It has only taken 18 days to > get a full description of the bug from IBM/Informix. > Have any of the members of this esteemed list succeeded in doing > point-in-time restores reliably? and if so with which releases? And > were any special procedures used for backing up? > regards > Malcolm sending to informix-list