Ontape backup slow ...

We are sever problems since last 2,3 months while taking backup. The command that we use is ontape -s It use to take 2,3 hours but now it takes 7-9 hours. For some reason checkpoints around that time take really long time upto 4 minutes. Any clues. Prev. experiences. thanks vivek chaudhary

Without seeing a copy of your onconfig file, I would think that your DBSPACETEMP dbspaces are full or close to it (if you have any at all) or your physical log is too small. Go to http://www.informix.com/answers and download the Informix Administrator's Guide for your version of Informix and review the chapter dealing with the Onconfig parameters. You should probably look into the SQL Reference Manual as well, the chapter dealing with Environment Parameters. For sheer performance reasons, if you have at least two CPUs on your box, you should be using PSORT_NPROCS. Take care. Clifton Bean <pgcs@pgcs.com> wrote in message news:390658ee.1231058867@news.jps.net... > We are sever problems since last 2,3 months while taking backup. The > command that we use is > > ontape -s> > It use to take 2,3 hours but now it takes 7-9 hours. For some reason > checkpoints around that time take really long time upto 4 minutes. > > Any clues. Prev. experiences. > > thanks > > > vivek chaudhary

In article <0pvN4.13097$qF4.1758607@news1.rdc2.tx.home.com>, "Clifton M. Bean" <cmbean@home.com> wrote: > Without seeing a copy of your onconfig file, I would think that your > DBSPACETEMP dbspaces are full or close to it (if you have any at all) or > your physical log is too small. Go to http://www.informix.com/answers and > download the Informix Administrator's Guide for your version of Informix and > review the chapter dealing with the Onconfig parameters. You should > probably look into the SQL Reference Manual as well, the chapter dealing > with Environment Parameters. For sheer performance reasons, if you have at > least two CPUs on your box, you should be using PSORT_NPROCS. > > Take care. > Clifton Bean > > <pgcs@pgcs.com> wrote in message news:390658ee.1231058867@news.jps.net... > > We are sever problems since last 2,3 months while taking backup. The > > command that we use is > > > > ontape -s> > > > It use to take 2,3 hours but now it takes 7-9 hours. For some reason > > checkpoints around that time take really long time upto 4 minutes. > > > > Any clues. Prev. experiences. > > > > thanks > > > > > > vivek chaudhary > > .. could also be ... DESCRIPTION FOR DEFECT 101062 Product: Informix ONLINE Reported: 10/05/1998 ARCHIVE PERFORMANCE DEGRADATION WHEN MANY CALLS TO ARC_VERY_OLD_PAGE() Verified in Fixed in Platform 7.30.UC3 - UNIX Highly oltp systems that also contain a large amount of static pages, occasional archive performance severly degrades when those pages qualify as very old pages. This is because of a re-read of the pages in the archive buffer from disk to update the TS. Regards Mr Creosote -- "Just a waffer thin mint?" Sent via Deja.com http://www.deja.com/ Before you buy.

As suggestion and a surmise... First, have you changed to using lower density tapes? These will write much slower. Second, I have a feeling that the time required to do a backup depends on how much data is in the dbspace combined with some 'memory' of how full the dbspace had once been. Let's assume that you have a total storage capacity of 10MB, with 1 MB used. That might take 1 minute to backup. Store another 5 MB, and your backup might take 6 minutes. Store another 1 MB, and the backup goes up to 7 minutes. Delete the 5MB area, and the time to backup will not drop to 2 minutes. Have you loaded then deleted lots of data? In article <390658ee.1231058867@news.jps.net>, pgcs@pgcs.com writes >We are sever problems since last 2,3 months while taking backup. The >command that we use is > >ontape -s> >It use to take 2,3 hours but now it takes 7-9 hours. For some reason >checkpoints around that time take really long time upto 4 minutes. > >Any clues. Prev. experiences. > >thanks > > >vivek chaudhary Andrew Lennard andy@kontron.demon.co.uk