Cache Hit

Hi Can anyone please tell me how to force the cache hit to be as high as possible. Reason I'm asking, we clone the database (+-200 GB) and then do a backup of the clone. Problem we are running into is that the backup is taking a bit long - 16 Hrs. We are using the following: Informix Dynamic Server Version 7.31.FC6 Onbar going to a StorageTek STL Silo using 9840 drives Legato as the storage media handler We are only getting throughput or roughly 500 Kb/s per drive! When the database is started the cache % is 0. We want to up the cache ratio in order to get the backup a bit faster. It is not the drives that are slow as we sometimes, when the database has been up for a while, get a speed of up to 20 MB/s. Please help

Improving your cache ratio will not help the archiving speed since the onarchive thread which does the actual page reading for ontape, onarchive, and onbar reads the physical disk into a small set of private buffers to avoid causing the buffer cache to thrash and affect performance for user threads. Sorry. How many chunks are defined? Is this a long existing instance that has been upgraded, over time, to 7.31FC6? You may be running into the page timestamp bug which is not fixed until the C8 maintenance release (though you can ask for a back-port patch to FC6 if you have maintenance it is a backward compatible fix. The problem is that there are pages with timestamps so old that the timestamp values are wrapping to negative so to prevent them from wrapping again and overtaking the old pages the engine, during each archive, restamps the oldest pages. Unfortunately it seems that it stops archiving to do this which lets the tape stop and have to be backed up and spun up to speed again. The patch apparently just gathers the pagenumbers that need restamping and batches the updates after the archive is complete or assigns a separate thread to do the job. Art S. Kagel Johan Edeling wrote: > > Hi > Can anyone please tell me how to force the cache hit to be as high as > possible. Reason I'm asking, we clone the database (+-200 GB) and then do > a backup of the clone. Problem we are running into is that the backup is > taking a bit long - 16 Hrs. We are using the following: > Informix Dynamic Server Version 7.31.FC6 > > Onbar going to a StorageTek STL Silo using 9840 drives > Legato as the storage media handler > We are only getting throughput or roughly 500 Kb/s per drive! > > When the database is started the cache % is 0. We want to up the cache ratio > in order to get the backup a bit faster. It is not the drives that are slow > as we sometimes, when the database has been up for a while, get a speed of > up to 20 MB/s. > > Please help

Hi Art, Been away, just got back, Have you got the release notes for UC8 yet? Any chance of a copy? Heard the timestamp patch was a daemon which updates the timestamps and was added to UC7 -hence the delay to UC7 and why UC8 followed so soon.. I'm back! David Art S. Kagel wrote in message <39F4A9F5.79A6AB95@bloomberg.net>... >Improving your cache ratio will not help the archiving speed since the >onarchive thread which does the actual page reading for ontape, onarchive, >and onbar reads the physical disk into a small set of private buffers to >avoid causing the buffer cache to thrash and affect performance for user >threads. Sorry. How many chunks are defined? Is this a long existing >instance that has been upgraded, over time, to 7.31FC6? You may be running >into the page timestamp bug which is not fixed until the C8 maintenance >release (though you can ask for a back-port patch to FC6 if you have >maintenance it is a backward compatible fix. > >The problem is that there are pages with timestamps so old that the timestamp >values are wrapping to negative so to prevent them from wrapping again and >overtaking the old pages the engine, during each archive, restamps the >oldest pages. Unfortunately it seems that it stops archiving to do this >which lets the tape stop and have to be backed up and spun up to speed >again. The patch apparently just gathers the pagenumbers that need >restamping and batches the updates after the archive is complete or assigns >a separate thread to do the job. > >Art S. Kagel > >Johan Edeling wrote: >> >> Hi >> Can anyone please tell me how to force the cache hit to be as high as >> possible. Reason I'm asking, we clone the database (+-200 GB) and then do >> a backup of the clone. Problem we are running into is that the backup is >> taking a bit long - 16 Hrs. We are using the following: >> Informix Dynamic Server Version 7.31.FC6 >> >> Onbar going to a StorageTek STL Silo using 9840 drives >> Legato as the storage media handler >> We are only getting throughput or roughly 500 Kb/s per drive! >> >> When the database is started the cache % is 0. We want to up the cache ratio >> in order to get the backup a bit faster. It is not the drives that are slow >> as we sometimes, when the database has been up for a while, get a speed of >> up to 20 MB/s. >> >> Please help

No got a patched UC6 instead. Art S. Kagel smooth1 wrote: > > Hi Art, > > Been away, just got back, > > Have you got the release notes for UC8 yet? Any chance of a copy? > > Heard the timestamp patch was a daemon which updates the > timestamps and was added to UC7 -hence the delay to UC7 > and why UC8 followed so soon.. > > I'm back! > > David > > Art S. Kagel wrote in message <39F4A9F5.79A6AB95@bloomberg.net>... > >Improving your cache ratio will not help the archiving speed since the > >onarchive thread which does the actual page reading for ontape, onarchive, > >and onbar reads the physical disk into a small set of private buffers to > >avoid causing the buffer cache to thrash and affect performance for user > >threads. Sorry. How many chunks are defined? Is this a long existing > >instance that has been upgraded, over time, to 7.31FC6? You may be running > >into the page timestamp bug which is not fixed until the C8 maintenance > >release (though you can ask for a back-port patch to FC6 if you have > >maintenance it is a backward compatible fix. > > > >The problem is that there are pages with timestamps so old that the > timestamp > >values are wrapping to negative so to prevent them from wrapping again and > >overtaking the old pages the engine, during each archive, restamps the > >oldest pages. Unfortunately it seems that it stops archiving to do this > >which lets the tape stop and have to be backed up and spun up to speed > >again. The patch apparently just gathers the pagenumbers that need > >restamping and batches the updates after the archive is complete or assigns > >a separate thread to do the job. > > > >Art S. Kagel > > > >Johan Edeling wrote: > >> > >> Hi > >> Can anyone please tell me how to force the cache hit to be as high as > >> possible. Reason I'm asking, we clone the database (+-200 GB) and then > do > >> a backup of the clone. Problem we are running into is that the backup is > >> taking a bit long - 16 Hrs. We are using the following: > >> Informix Dynamic Server Version 7.31.FC6 > >> > >> Onbar going to a StorageTek STL Silo using 9840 drives > >> Legato as the storage media handler > >> We are only getting throughput or roughly 500 Kb/s per drive! > >> > >> When the database is started the cache % is 0. We want to up the cache > ratio > >> in order to get the backup a bit faster. It is not the drives that are > slow > >> as we sometimes, when the database has been up for a while, get a speed > of > >> up to 20 MB/s. > >> > >> Please help