Help! Ontape running very slow.

Has anyone had a problem in IDS 7.31.uc6 with level-0 ontapes taking a very long time? Our ontape backup usually takes 6-8 hours, but this one has been running for something like 16 hours. The first and second tapes completed as expected, the third and fourth have been excrutiatingly slow. The tape drive will sit idle for a minute or so then write for a second or two. The backup has been behaving this way since very early this morning, so user load doesn't seem to have much to do with it. The same problem seemed to plague a level-0 onbar which I wound up killing yesterday. Examination of Informix message log and system logs reveals nothing. A level-0 onbar failed last week because the tapes filled up. Perhaps that is the cause. It is all just speculation right now... Thanks, Ty -- Ty O'Kelly DBA tokelly@maxor.invalid.com 806-324-5521

We notices something staring in 7.30 (?) where the same thing would happen. I may be that you have what they call "VERY OLD PAGES" (?). If the last updates timestamp on a page is > X units old, the backup actually has to update this timestamp on every page where this condition is true. To see if this is happening: 1. run onstat -g act and get the threadid of the backup that is running. 2. run onstat -g stk THREADID to see what that thread is doing. If you see the words "very old" or something like that they that's it. Informix knows that they need to find a better way to do this, but I don't know if it's been fixed yet. Bill Border Agilent Technologies bill_border@agilent.com Effective, Affordable Oracle/Informix Monitor: http://dbamon.com Ty O'Kelly wrote in message <3975E243.8C815781@maxor.invalid.com>... >Has anyone had a problem in IDS 7.31.uc6 with level-0 ontapes taking a >very long time? Our ontape backup usually takes 6-8 hours, but this one >has been running for something like 16 hours. The first and second >tapes completed as expected, the third and fourth have been >excrutiatingly slow. The tape drive will sit idle for a minute or so >then write for a second or two. The backup has been behaving this way >since very early this morning, so user load doesn't seem to have much to >do with it. The same problem seemed to plague a level-0 onbar which I >wound up killing yesterday. Examination of Informix message log and >system logs reveals nothing. A level-0 onbar failed last week because >the tapes filled up. Perhaps that is the cause. It is all just >speculation right now... > >Thanks, >Ty >-- >Ty O'Kelly >DBA >tokelly@maxor.invalid.com >806-324-5521 > >

Ooops. (sorry for the misspellings in my post - it's early). :( That reminds me of a poem: I have a spelling checker. It came with my PC. It plane lee marks four my revue Miss steaks aye can knot see. Eye ran this poem threw it. Your sure real glad two no. Its very polished in its weigh, My checker tolled me sew. A checker is a blessing. It freeze yew lodes of thyme. It helps me right awl stiles two reed, And aides me when aye rime. Each frays comes posed up on my screen Eye trussed too bee a joule. The checker pours o`er every word To cheque sum spelling rule. Bee fore a veiling checkers Hour spelling mite decline, And if we`re laks oar have a laps, We wood bee maid too wine. Butt now bee cause my spelling Is checked with such grate flare, There are know faults with in my cite, Of nun eye am a wear. Now spelling does not phase me, It does knot bring a tier. My pay purrs awl due glad den With wrapped words fare as hear. To rite with care is quite a feet Of witch won should be proud, And wee mussed dew the best wee can, Sew flaws are knot aloud. Sow ewe can sea why aye dew prays Such soft wear four pea seas, And why eye brake in two averse Buy righting want too please. Bill Bill Border wrote in message <8l6713$g3q$1@nonews.col.hp.com>... > We notices something staring in 7.30 (?) where the same thing >would happen. I may be that you have what they call "VERY OLD >PAGES" (?). If the last updates timestamp on a page is > X units >old, the backup actually has to update this timestamp on every >page where this condition is true. > > To see if this is happening: >1. run onstat -g act and get the threadid of the backup that is > running. > >2. run onstat -g stk THREADID to see what that thread is doing. > > If you see the words "very old" or something like that they that's >it. Informix knows that they need to find a better way to do this, but >I don't know if it's been fixed yet. > >Bill Border >Agilent Technologies >bill_border@agilent.com >Effective, Affordable Oracle/Informix Monitor: http://dbamon.com > > > >Ty O'Kelly wrote in message <3975E243.8C815781@maxor.invalid.com>... >>Has anyone had a problem in IDS 7.31.uc6 with level-0 ontapes taking a >>very long time? Our ontape backup usually takes 6-8 hours, but this one >>has been running for something like 16 hours. The first and second >>tapes completed as expected, the third and fourth have been >>excrutiatingly slow. The tape drive will sit idle for a minute or so >>then write for a second or two. The backup has been behaving this way >>since very early this morning, so user load doesn't seem to have much to >>do with it. The same problem seemed to plague a level-0 onbar which I >>wound up killing yesterday. Examination of Informix message log and >>system logs reveals nothing. A level-0 onbar failed last week because >>the tapes filled up. Perhaps that is the cause. It is all just >>speculation right now... >> >>Thanks, >>Ty >>-- >>Ty O'Kelly >>DBA >>tokelly@maxor.invalid.com >>806-324-5521 >> >> > >

yes, it was the "very old pages" bug. the level-0 backup took about 25-26 hours, but it finally finished. god help me if it comes up again. thanks for the reply. ty -- Ty O'Kelly DBA tokelly@maxor.invalid.com 806-324-5521 Bill Border wrote: > We notices something staring in 7.30 (?) where the same thing > would happen. I may be that you have what they call "VERY OLD > PAGES" (?). If the last updates timestamp on a page is > X units > old, the backup actually has to update this timestamp on every > page where this condition is true. > > To see if this is happening: > 1. run onstat -g act and get the threadid of the backup that is > running. > > 2. run onstat -g stk THREADID to see what that thread is doing. > > If you see the words "very old" or something like that they that's > it. Informix knows that they need to find a better way to do this, but > I don't know if it's been fixed yet. > > Bill Border > Agilent Technologies > bill_border@agilent.com > Effective, Affordable Oracle/Informix Monitor: http://dbamon.com

For those interested, the workaround is to run a harmless update on the table like: update table tab1 set col1 = col1; for every table before you back it up. This may or may not be a valid workaround (depends how long it takes to update all your tables). Of course if you wanted to get real fancy you could write something that only updates one row on every used page, that would probably run faster. Ty O'Kelly (tokelly@maxor.invalid.com) wrote: : yes, it was the "very old pages" bug. the level-0 backup took about 25-26 : hours, but it finally finished. god help me if it comes up again. thanks : for the reply. : ty : -- : Ty O'Kelly : DBA : tokelly@maxor.invalid.com : 806-324-5521 : Bill Border wrote: : > We notices something staring in 7.30 (?) where the same thing : > would happen. I may be that you have what they call "VERY OLD : > PAGES" (?). If the last updates timestamp on a page is > X units : > old, the backup actually has to update this timestamp on every : > page where this condition is true. : > : > To see if this is happening: : > 1. run onstat -g act and get the threadid of the backup that is : > running. : > : > 2. run onstat -g stk THREADID to see what that thread is doing. : > : > If you see the words "very old" or something like that they that's : > it. Informix knows that they need to find a better way to do this, but : > I don't know if it's been fixed yet. : > : > Bill Border : > Agilent Technologies : > bill_border@agilent.com : > Effective, Affordable Oracle/Informix Monitor: http://dbamon.com -- Rob Wilson rwilson@ntsource.com