Re: incremental onbars

On May 29, 12:55 pm, "Campbell, John (GE Money)" <John.Campbe...@ge.com> wrote: > 9.40.FC5, Solaris 9. It seems to be my station in life to inherit > things. When I inherited this db, we were running on some flavor of > 7.31. Someone else designed the onbar backup and currently we run 1 > level 0 a week. It is running muti-threaded and takes 6 to 8 hours to > run. I was told that the incremental onbar takes the same amount of > time and, therefore, is not beneficial. I would imagine that it still > needs to read all of the dbspaces but it should not write out nearly as > much. Does a level1 or level2 actually take as long as the level0 to > run? > > Several years ago we tried unsuccessfully to back up and restore a > single dbspace. Usually, the backup seemed to run fine. The restore > had two outcomes: the logs were rolled forward repeating the event that > corrupted it or the dbspace would not come online and remained in an > inconsistent state. We contacted informix support and were told that a > dbspace backup was not supported. > > What I wanted to do was put specific tables in their own dbspaces and > backup these dbspace groups at differing times. I would have a group of > dbspacese to backup daily, another group to backup weekly...etc. I > would then do a warm restore on a particular dbspace group as needed. I > thought the onbar manual said this was supported but could never get the > restore to work or get any help from support so we gave up. Anyone out > there doing anything similar? So far, all the onbar is used for here is > level 0 backup and restore. > > It looks like, at long last, I may get to upgrade to 10. ( I would > prefer 11 but I'll take what I can get). I'm hoping to move to Solaris > 10 with IDS10 this year. I would really like the table-level restore > capability. Anyone using it on Solaris 10? Does it work nicely? > > thx in advance for the info Have you looked into external backups with version 10? If you are running your database on a san you could possibly block the database take a san snapshot (This should be almost instantaneous). Then unblock the database. The iiug website has an article about backups from the 2006 informix user conference in Tampa. It also has info on performance tuning of backups. I wonder if you are running into a bug on the incremental backup. I believe that there was a bug that caused the incremental backups to run slow because of the page update time.

My experience of incremental onbars tends to bear out John's observations. It can take a long time to do an onbar backup and it doesn't seem to make any difference which level is used. Only last week I was investigating one of my systems that used onbar. On some days the onbar only took 1.5 hours, but on other days the same level-0 onbar took over 7 hours. I was fortunate to have access to some AIX statistics and I discovered that on the days when the onbar took less time it was because the same amount of disk reads took place in a shorter time. Further investigating showed that the same disk were a lot more busy for a much shorter period when the backup worked quickly. And yet further investigation showed that the onbar was slower when the SAN was busy and dependent on network traffic. In our case the storage manager is being accessed over the network so we have a network latency factor. My conclusion is that we would be much better off using ontape. But from tests I ran some years ago it was apparent that ontape didn't run much faster when doing a level 1 than when doing a level-0. And the difference in speed was down to the amount of data being written to the tape. In general I think the major advantage of an incremental backup is when the volume of data is too big for the media. Just my two pennorth Malcolm -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of bozon Sent: 29 May 2008 20:52 To: informix-list@iiug.org Subject: Re: incremental onbars On May 29, 12:55 pm, "Campbell, John (GE Money)" <John.Campbe...@ge.com> wrote: > 9.40.FC5, Solaris 9. It seems to be my station in life to inherit > things. When I inherited this db, we were running on some flavor of > 7.31. Someone else designed the onbar backup and currently we run 1 > level 0 a week. It is running muti-threaded and takes 6 to 8 hours to > run. I was told that the incremental onbar takes the same amount of > time and, therefore, is not beneficial. I would imagine that it still > needs to read all of the dbspaces but it should not write out nearly as > much. Does a level1 or level2 actually take as long as the level0 to > run? > > Several years ago we tried unsuccessfully to back up and restore a > single dbspace. Usually, the backup seemed to run fine. The restore > had two outcomes: the logs were rolled forward repeating the event that > corrupted it or the dbspace would not come online and remained in an > inconsistent state. We contacted informix support and were told that a > dbspace backup was not supported. > > What I wanted to do was put specific tables in their own dbspaces and > backup these dbspace groups at differing times. I would have a group of > dbspacese to backup daily, another group to backup weekly...etc. I > would then do a warm restore on a particular dbspace group as needed. I > thought the onbar manual said this was supported but could never get the > restore to work or get any help from support so we gave up. Anyone out > there doing anything similar? So far, all the onbar is used for here is > level 0 backup and restore. > > It looks like, at long last, I may get to upgrade to 10. ( I would > prefer 11 but I'll take what I can get). I'm hoping to move to Solaris > 10 with IDS10 this year. I would really like the table-level restore > capability. Anyone using it on Solaris 10? Does it work nicely? > > thx in advance for the info Have you looked into external backups with version 10? If you are running your database on a san you could possibly block the database take a san snapshot (This should be almost instantaneous). Then unblock the database. The iiug website has an article about backups from the 2006 informix user conference in Tampa. It also has info on performance tuning of backups. I wonder if you are running into a bug on the incremental backup. I believe that there was a bug that caused the incremental backups to run slow because of the page update time. _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list

On Jun 2, 4:24 pm, "malcolm.iiug" <mali...@btopenworld.com> wrote: > My experience of incremental onbars tends to bear out John's observations. > It can take a long time to do an onbar backup and it doesn't seem to make > any difference which level is used. > Only last week I was investigating one of my systems that used onbar. On > some days the onbar only took 1.5 hours, but on other days the same level-0 > onbar took over 7 hours. I was fortunate to have access to some AIX > statistics and I discovered that on the days when the onbar took less time > it was because the same amount of disk reads took place in a shorter time. > Further investigating showed that the same disk were a lot more busy for a > much shorter period when the backup worked quickly. > And yet further investigation showed that the onbar was slower when the SAN > was busy and dependent on network traffic. In our case the storage manager > is being accessed over the network so we have a network latency factor. > > My conclusion is that we would be much better off using ontape. But from > tests I ran some years ago it was apparent that ontape didn't run much > faster when doing a level 1 than when doing a level-0. And the difference > in speed was down to the amount of data being written to the tape. > > In general I think the major advantage of an incremental backup is when the > volume of data is too big for the media. > > Just my two pennorth > > Malcolm > > -----Original Message----- > From: informix-list-boun...@iiug.org [mailto:informix-list-boun...@iiug.org] > > On Behalf Of bozon > Sent: 29 May 2008 20:52 > To: informix-l...@iiug.org > Subject: Re: incremental onbars > > On May 29, 12:55 pm, "Campbell, John (GE Money)" > <John.Campbe...@ge.com> wrote: > > 9.40.FC5, Solaris 9. It seems to be my station in life to inherit > > things. When I inherited this db, we were running on some flavor of > > 7.31. Someone else designed the onbar backup and currently we run 1 > > level 0 a week. It is running muti-threaded and takes 6 to 8 hours to > > run. I was told that the incremental onbar takes the same amount of > > time and, therefore, is not beneficial. I would imagine that it still > > needs to read all of the dbspaces but it should not write out nearly as > > much. Does a level1 or level2 actually take as long as the level0 to > > run? > > > Several years ago we tried unsuccessfully to back up and restore a > > single dbspace. Usually, the backup seemed to run fine. The restore > > had two outcomes: the logs were rolled forward repeating the event that > > corrupted it or the dbspace would not come online and remained in an > > inconsistent state. We contacted informix support and were told that a > > dbspace backup was not supported. > > > What I wanted to do was put specific tables in their own dbspaces and > > backup these dbspace groups at differing times. I would have a group of > > dbspacese to backup daily, another group to backup weekly...etc. I > > would then do a warm restore on a particular dbspace group as needed. I > > thought the onbar manual said this was supported but could never get the > > restore to work or get any help from support so we gave up. Anyone out > > there doing anything similar? So far, all the onbar is used for here is > > level 0 backup and restore. > > > It looks like, at long last, I may get to upgrade to 10. ( I would > > prefer 11 but I'll take what I can get). I'm hoping to move to Solaris > > 10 with IDS10 this year. I would really like the table-level restore > > capability. Anyone using it on Solaris 10? Does it work nicely? > > > thx in advance for the info > > Have you looked into external backups with version 10? If you are > running your database on a san you could possibly block the database > take a san snapshot (This should be almost instantaneous). Then > unblock the database. The iiug website has an article about backups > from the 2006 informix user conference in Tampa. It also has info on > performance tuning of backups. > > I wonder if you are running into a bug on the incremental backup. I > believe that there was a bug that caused the incremental backups to > run slow because of the page update time. > _______________________________________________ > Informix-list mailing list > Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list Interesting, I know in my experience backups take longer when the database is being updated heavily while the backup is taken. I found out this is because any pages that are changed that haven't been backed up yet have their before images saved in the tempdbs space. You then end up reading twice because when the backup reads a modified page it will note that the page timestamp is more recent than the backup. This causes it to get the before image from the tempdbs to ensure that the backup is consistent with the check point that is forced when the backup is started. Could this be the cause of the time variances that you are seeing? Also, check ajay's presentation on backups at the 2006 Informix user group conference. It can be found on the iiug website.