Backup time

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

Talk with your network folks, there is likely a lot more going on with your network than just informix :-) Talk with your backup software folks if you are using onbar handshaking with another vendors backup software, it is likely that IDS engine is not the only thing your corporation backs up.... -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of askel Sent: Thursday, June 12, 2008 8:53 PM To: informix-list@iiug.org Subject: Backup time 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Sebastian, Backup is done locally by simple shell script. All that script does is start ontape with LTAPEDEV pointing to named pipe which in turn is being read by compress utility. Last night it took 46 minutes only while night before it was four and a half hours. Packed backups are stored on dedicated disk array partition. Disk array is connected directly to the server by FC. Thanks for replying Alexander On Jun 13, 8:33 am, "Sebastian, Norma J." <NormaJean.Sebast...@tellabs.com> wrote: > Talk with your network folks, there is likely a lot more going on with > your network than just informix :-) > Talk with your backup software folks if you are using onbar handshaking > with another vendors backup software, it is likely that IDS engine is > not the only thing your corporation backs up.... > > -----Original Message----- > From: informix-list-boun...@iiug.org > > [mailto:informix-list-boun...@iiug.org] On Behalf Of askel > Sent: Thursday, June 12, 2008 8:53 PM > To: informix-l...@iiug.org > Subject: Backup time > > 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.orghttp://www.iiug.org/mailman/listinfo/informix-list > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > ============================================================

askel wrote: > Sebastian, > > Backup is done locally by simple shell script. All that script does is > start ontape with LTAPEDEV pointing to named pipe which in turn is > being read by compress utility. > Last night it took 46 minutes only while night before it was four and > a half hours. Packed backups are stored on dedicated disk array > partition. Disk array is connected directly to the server by FC. > > Thanks for replying > Alexander > > On Jun 13, 8:33 am, "Sebastian, Norma J." > <NormaJean.Sebast...@tellabs.com> wrote: >> Talk with your network folks, there is likely a lot more going on with >> your network than just informix :-) >> Talk with your backup software folks if you are using onbar handshaking >> with another vendors backup software, it is likely that IDS engine is >> not the only thing your corporation backs up.... >> >> -----Original Message----- >> From: informix-list-boun...@iiug.org >> >> [mailto:informix-list-boun...@iiug.org] On Behalf Of askel >> Sent: Thursday, June 12, 2008 8:53 PM >> To: informix-l...@iiug.org >> Subject: Backup time >> >> 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.orghttp://www.iiug.org/mailman/listinfo/informix-list >> ============================================================ >> The information contained in this message may be privileged >> and confidential and protected from disclosure. If the reader >> of this message is not the intended recipient, or an employee >> or agent responsible for delivering this message to the >> intended recipient, you are hereby notified that any reproduction, >> dissemination or distribution of this communication is strictly >> prohibited. If you have received this communication in error, >> please notify us immediately by replying to the message and >> deleting it from your computer. Thank you. Tellabs >> ============================================================ > You may want to check the tapes if you're using a tape device. If the tape is old it may be retrying the writes... But if this was the case you'd probably have a few aborted backups from time to time... Older IDS versions also suffer from a know backup algorithm issue that was known as the "very_old_page" issue (or a similar name). If you don't find any other cause you may want to open a PMR to check if this is your case. It could happen in any system, but if the frequency of the slow backups is high, then it should only happen on very systems with lot's of activity (insert/update/deletes), specially if a large portion of your data is static (it doesn't change often. Regards.

On Jun 13, 10:13 am, Fernando Nunes <domusonl...@gmail.com> wrote: > You may want to check the tapes if you're using a tape device. > If the tape is old it may be retrying the writes... But if this was the case > you'd probably have a few aborted backups from time to time... Backups are stored on disk array. > Older IDS versions also suffer from a know backup algorithm issue that was > known as the "very_old_page" issue (or a similar name). If you don't find any > other cause you may want to open a PMR to check if this is your case. It could > happen in any system, but if the frequency of the slow backups is high, then it > should only happen on very systems with lot's of activity > (insert/update/deletes), specially if a large portion of your data is static > (it doesn't change often. Backups are run at the time when there is no much activity. And I believe that activity is not much different from night to nigh. Cheers Alexander

askel wrote: > On Jun 13, 10:13 am, Fernando Nunes <domusonl...@gmail.com> wrote: >> You may want to check the tapes if you're using a tape device. >> If the tape is old it may be retrying the writes... But if this was the case >> you'd probably have a few aborted backups from time to time... > > Backups are stored on disk array. > >> Older IDS versions also suffer from a know backup algorithm issue that was >> known as the "very_old_page" issue (or a similar name). If you don't find any >> other cause you may want to open a PMR to check if this is your case. It could >> happen in any system, but if the frequency of the slow backups is high, then it >> should only happen on very systems with lot's of activity >> (insert/update/deletes), specially if a large portion of your data is static >> (it doesn't change often. > > Backups are run at the time when there is no much activity. And I > believe that activity is not much different from night to nigh. > > Cheers > Alexander The activity doesn't have to be during the backup. It's the activity that takes place in between the backups. But the issue I was talking about was already explain in more detail by others, and you also have the bug number. But apparently your version doesn't have it... Regards.

On 13/06/2008, Fernando Nunes <domusonline@gmail.com> wrote: > askel wrote: > > On Jun 13, 10:13 am, Fernando Nunes <domusonl...@gmail.com> wrote: > >> You may want to check the tapes if you're using a tape device. > >> If the tape is old it may be retrying the writes... But if this was the case > >> you'd probably have a few aborted backups from time to time... > > > > Backups are stored on disk array. > > > >> Older IDS versions also suffer from a know backup algorithm issue that was > >> known as the "very_old_page" issue (or a similar name). If you don't find any > >> other cause you may want to open a PMR to check if this is your case. It could > >> happen in any system, but if the frequency of the slow backups is high, then it > >> should only happen on very systems with lot's of activity > >> (insert/update/deletes), specially if a large portion of your data is static > >> (it doesn't change often. > > > > Backups are run at the time when there is no much activity. And I > > believe that activity is not much different from night to nigh. > > > > Cheers > > Alexander > > The activity doesn't have to be during the backup. It's the activity that takes > place in between the backups. But the issue I was talking about was already > explain in more detail by others, and you also have the bug number. But > apparently your version doesn't have it... > > Regards. > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > Following threads describe the issue in more detail, but confirm a fix by 9.4, also FC6 is the version I am running and I do not have the issue (but have hit it in the past on this database at v 7.31) http://groups.google.co.uk/group/comp.databases.informix/browse_thread/thread/ceeedee1ba1c7676/c73747f3030b0f67?hl=en&lnk=gst&q=101062#c73747f3030b0f67 http://groups.google.co.uk/group/comp.databases.informix/browse_thread/thread/4aedd4631b1e4fac/1d365d0cf20a557a?hl=en&lnk=gst&q=101062#1d365d0cf20a557a Keith