Backups using ontape take very long

Hello, Here is our situation. We have a client that is running on a Digital Unix Box and is running I believe version 7.22. I don't think the version matters all that much for this particular problem or the OS and tape device. Anyways previous to the last couple of weeks, backups take anywhere from 4-5 hours to complete from previous times of just over an 1/2 hour. Our databases are very large but it is strange to me why they are taking so long from before. This has just been recently the occurence. Nothing has been modified from before which is why I am at a stand point righ now. It is very odd that this is occuring. I have ran update statistics on all databases just to see if this would increase the speed of the backups. I didn't think that this would make any difference which it didn't but I guess it is always good to do one every so often! I checked extra processes running in the background, error messages etc... and nothing is out of the ordinary. Any ideas very much appreciated. Thanks in advance, Lloyd. PS. Here is exerpt from our log file. Good backups.... 12:00:14 Level 0 Archive started on rootdbs, dbs01, dbs02, dbs03, dbs04,logdbs 12:39:36 Archive on rootdbs, dbs01, dbs02, dbs03, dbs04, logdbs Completed. Bad backups.... 12:00:20 Level 0 Archive started on rootdbs, dbs01, dbs02, dbs03, dbs04,logdbs 17:21:42 Archive on rootdbs, dbs01, dbs02, dbs03, dbs04, logdbs Completed.

Don't know whether this helps or not... It's always seemed to me, and I've never checked it out by timing, that the duration of the 'level 0' is determined by the maximum amount of dbspace that has ever been used. For example, with a fictitious scenario... create a database of size (x). the backup will take (y) minutes to complete. create an additional database of size (x). the backup will now take (2y). drop one of the databases. the backup will still take (2y). Perhaps someone will correct me if that's not the case. Other than that, a suggestion would be that different tapes were being used for the backup. Lower density tapes will take longer to write, and your drive probably autodetects and doesn't tell you. In article <GsVB3.15815$m4.64344824@news.magma.ca>, Lloyd AJ Wilson <lwilson@harriscomputer.com> writes >Hello, > >Here is our situation. We have a client that is running on a Digital Unix >Box and is running I believe version 7.22. > >I don't think the version matters all that much for this particular problem >or the OS and tape device. > >Anyways previous to the last couple of weeks, backups take anywhere from 4-5 >hours to complete from previous times of just over an 1/2 hour. Our >databases are very large but it is strange to me why they are taking so long >from before. > >This has just been recently the occurence. Nothing has been modified from >before which is why I am at a stand point righ now. > >It is very odd that this is occuring. I have ran update statistics on all >databases just to see if this would increase the speed of the backups. I >didn't think that this would make any difference which it didn't but I guess >it is always good to do one every so often! > >I checked extra processes running in the background, error messages etc... >and nothing is out of the ordinary. > >Any ideas very much appreciated. > >Thanks in advance, > >Lloyd. > >PS. Here is exerpt from our log file. > >Good backups.... > >12:00:14 Level 0 Archive started on rootdbs, dbs01, dbs02, dbs03, dbs04,>logdbs >12:39:36 Archive on rootdbs, dbs01, dbs02, dbs03, dbs04, logdbs Completed.> >Bad backups.... > >12:00:20 Level 0 Archive started on rootdbs, dbs01, dbs02, dbs03, dbs04,>logdbs >17:21:42 Archive on rootdbs, dbs01, dbs02, dbs03, dbs04, logdbs Completed.> > > Andrew Lennard andy@kontron.demon.co.uk Clinical Information Systems Division Charter-Kontron Ltd Fountain Court 2 Victoria Square Victoria Street Phone: +44 (0)1727 884650 St Albans Fax: +44 (0)1727 884879 Herts AL1 3TF