Re: Backup time

9.40xC6 may indeed be old enough that it still suffers from the very old page problem. I would open a case with IBM if you still have support, as they will be able to determine if this is the problem. Art On Fri, Jun 13, 2008 at 9:26 AM, Alexander <dummy666@mail.ru> wrote: > Hello Art, > > Thank you for replying. We are using IDS 9.40.FC6. Last night it took 46 > minutes only and sometimes it is even faster. Night before last it took > about four and a half hours. Backup is being done by simple shell script > that runs ontape with LTAPEDEV pointing to named pipe that is read by > compress utility. The same method is used to backup logical logs between > level 0 backups. > > Sincerely > Alexander Kulakov > > Art Kagel wrote: > > Page modify timestamp wrapping. If the timestamp that's written to any > modified page wraps past 2^31-1 back to zero and then catches up to the > timestamp on the oldest existing page, the database has to do extra work at > archive time to make sure that archives do not get confused by updating > pages with old timestamps to have a 'newer' one that's still older than the > start of the previous archive. This code was rewritten in later 7.31 and > 9.40 versions and in IDS 10.00 and later. If you have an earlier release of > 9.40 (posting the exact version is always helpful) you should upgrade. > > Art > > On Thu, Jun 12, 2008 at 9:53 PM, askel <dummy666@mail.ru> wrote: > >> Hello All, >> >> We are using IDS 9.40 on top of Sparc Solaris 9. There is level 0 >> backup run every night. I'm just wondering why sometimes the backup >> takes couple hours and sometimes it is up to fifteen hours long. >> Database is not large (packed level 0 archive is about 10 Gb) and it >> doesn't seem to be related to amount of changes done to data. >> Dedicated disk array partition is used for backups. And I believe the >> database usage is about the same at the time we schedule backups. >> >> Well, long backups seems to slow down access to database, although not >> drastically. What could possibly affect backup speed if database load >> and amount of data is not much different from day to day? >> >> Thanks >> _______________________________________________ >> Informix-list mailing list >> Informix-list@iiug.org >> http://www.iiug.org/mailman/listinfo/informix-list >> > > > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Oninit, the IIUG, nor any other > organization with which I am associated either explicitly or implicitly. > Neither do those opinions reflect those of other individuals affiliated with > any entity with which I am affiliated nor those of the entities themselves. > > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Art, Unfortunately our support contract expired and we could not renew it because of version. We were asked to upgrade Informix to at least version 10 in order to have it supported but that doesn't make much sense for us since all we need is to keep current software running until the end of the year when new version that is not using Informix is deployed. Sincerely Alexander It is not a show-stopper but I hoped that there is simple solution to that. Thank you all for trying to help. On Jun 13, 10:21 am, "Art Kagel" <art.ka...@gmail.com> wrote: > 9.40xC6 may indeed be old enough that it still suffers from the very old > page problem. I would open a case with IBM if you still have support, as > they will be able to determine if this is the problem. > > Art > > > > On Fri, Jun 13, 2008 at 9:26 AM, Alexander <dummy...@mail.ru> wrote: > > Hello Art, > > > Thank you for replying. We are using IDS 9.40.FC6. Last night it took 46 > > minutes only and sometimes it is even faster. Night before last it took > > about four and a half hours. Backup is being done by simple shell script > > that runs ontape with LTAPEDEV pointing to named pipe that is read by > > compress utility. The same method is used to backup logical logs between > > level 0 backups. > > > Sincerely > > Alexander Kulakov > > > Art Kagel wrote: > > > Page modify timestamp wrapping. If the timestamp that's written to any > > modified page wraps past 2^31-1 back to zero and then catches up to the > > timestamp on the oldest existing page, the database has to do extra work at > > archive time to make sure that archives do not get confused by updating > > pages with old timestamps to have a 'newer' one that's still older than the > > start of the previous archive. This code was rewritten in later 7.31 and > > 9.40 versions and in IDS 10.00 and later. If you have an earlier release of > > 9.40 (posting the exact version is always helpful) you should upgrade. > > > Art > > > On Thu, Jun 12, 2008 at 9:53 PM, askel <dummy...@mail.ru> wrote: > > >> Hello All, > > >> We are using IDS 9.40 on top of Sparc Solaris 9. There is level 0 > >> backup run every night. I'm just wondering why sometimes the backup > >> takes couple hours and sometimes it is up to fifteen hours long. > >> Database is not large (packed level 0 archive is about 10 Gb) and it > >> doesn't seem to be related to amount of changes done to data. > >> Dedicated disk array partition is used for backups. And I believe the > >> database usage is about the same at the time we schedule backups. > > >> Well, long backups seems to slow down access to database, although not > >> drastically. What could possibly affect backup speed if database load > >> and amount of data is not much different from day to day? > > >> Thanks > >> _______________________________________________ > >> Informix-list mailing list > >> Informix-l...@iiug.org > >>http://www.iiug.org/mailman/listinfo/informix-list > > > -- > > Art S. Kagel > > Oninit (www.oninit.com) > > IIUG Board of Directors (a...@iiug.org) > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on my employer, Oninit, the IIUG, nor any other > > organization with which I am associated either explicitly or implicitly. > > Neither do those opinions reflect those of other individuals affiliated with > > any entity with which I am affiliated nor those of the entities themselves. > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (a...@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do those > opinions reflect those of other individuals affiliated with any entity with > which I am affiliated nor those of the entities themselves.