Re: Very slow onbar restore

Neil, This behavior is Informix bug 163093, fixed in 7.31.XD7, 9.30.XC7 and 9.40.XC3. Without upgrading, the only solution I know of is to manually ask for the dbspaces in dbs number order: 1. List the DBS number order of the instance with the onstat -d command 2. Make a script file of individual dbspace restore commands in the DBS number order. (Note that Informix requires critical dbspaces. Rootdbs and any dbspace that has physical logs or logical logs must be restored first): onbar -r -p rootdbs onbar -r -p llogdbs onbar -r -p plogdbs onbar -r -p dbspace5 onbar -r -p dbspace4 onbar -r -l onmode -m Contact Informix support for more information. Good luck. Brice Avila "Neil Truby" <neil.truby@ardenta.com> wrote in message news:<2i4h4kFilnidU1@uni-berlin.de>... > I've now received the following back fro the customer. > Does it strike any chords with anyone? > Sorry it's so long - executive summary: it's because we do -w (whole) > backups. > > thanks as ever > Neil > > "We do our onbar backups with the -w flag, because one of our reasons for > doing them is for disaster recovery offsite, when we will never have logs > available to do a logical restore as well. This seems to back up the > dbspaces in informix dbspace ID number; however, when you restore, it does > so in alphabetical order of dbspace name once it's taken care of the > critical dbspaces. This means that the restore is looking for files in a > different order from the one in which they were backed up to tape. > > Previously, while inefficient, this hasn't been a major issue since the > backups have continued at the same speed no matter how often the tape has > had to be repositioned. With this particular restore however, any tape > repositioning to access the next file seemed to make it potentially possible > for the restore speed to slow to a crawl where it only updates in short > bursts, or restore at a normal data rate. We saw it start fast, reposition > and go slow, reposition again and return to fast. We also saw it start slow > on a couple of occasions, although we mostly abandoned those before it got > far enough to need to do an out of order dbspace and reposition. Due to the > fact that we wanted to recover to a point in time as close as possible to > the time the database became corrupted we didn't experiment with too many > different backup tapes, but the restores we tried were on two different > tapes (one wholly on the first tape, the second partly on that and partly on > the other tape), the same thing happened on all three of the tape drives in > that robot, and the same dbspace from the same backup was observed to > restore either fast or slow, seemingly at random. There was no consistency > about what happened, other than that the speed change always seemed to come > when a tape reposition was required. Once running at a certain speed, it > would continue at that speed for as long as there were consecutive dbspaces > in restore order on the tape. > > In the end we simply let a restore attempt run through. It took just under > 30 hours, when the expected restore time would be 4-8 hours. At that, I > think we were lucky that some of the biggest dbspaces avoided getting hit by > the slow restore phenomenon. It probably made all the difference between it > finishing on Saturday night or Monday. > > Do you know of any way to persuade onbar to back up and restore in the same > order, bearing in mind that we need the backup in question to be able to > restore without the need for a logical log restore as well? It seems very > bizarre that it doesn't, but none of the various experiments I tried last > week (changing the value of BAR_MAX_BACKUP, specifying the dbspaces in the > right order in a file, etc) were very helpful. This is a shame, as if we'd > been able to restore in backup order I strongly suspect that it would have > run through with no problems, as soon as we got a restore attempt to start > at the correct speed."