Info: Archive bug on pre-5.05

I've put quite a lot of head-scratching into this problem and figure that it it's worth sharing... Online 5 fails to back up "Old Pages" (pages that havn't been updated for a while) This is supposed to be fixed in Online 5.05, but the fix is UNTESTED. Ok. Now what on earth is an "Old Page"? The current working model of *my* understanding old pages is as follows: >(much of this understanding is as a result of reading bug 12115) >The timestamp is a 32 bit integer. For convenience, we will consider >it as a signed integer, but the principle is the same if it is unsigned. >Consider the pages of the database sorted by timestamp: > >-2gb -1gb -0.5gb 0 1gb 1.1gb 2gb > +---------------+-------+----+------------------+---------+----------------+ > |aaaaaaaaaaaaaaa|bbbbbbb|cccc|dddddddddddddddddd|eeeeeeeee|ffffffffffffffff| > +---------------+-------+----+------------------+---------+----------------+ > minstamp maxstamp sh_stamp > >An on-line archive is started at timestamp=1gb. >During the time taken to do the archive, other system activity increments the >timestamp to 1.1gb > >Everything from -1gb to +1gb (bcd) is put on the tape, without hesitation. > >Everything stamped between 1gb and 1.1gb (e) is rejected as being newer than >the archive time The before-images from the physical log are archived >instead. > >Any pages which in area (af) are "very old pages". These are given a new >timestamp. (ie: updated, to make them new) The before image is written >to the log NOT archived due to the 18027 bug. > >Taking the model a little further, if we start the *next* archive at +1.5gb, >minstamp will be -0.5gb. Since any old pages in (af) were given new >timestamps during the last archive (and thus, there are *no* old pages >in (af)), the only "Very Old Pages" will be these with timestamps in the >range (b). I understand that the bug crept in during optimisation to avoid writing the same page to an archive twice. If you have old pages (ie: you have written more than 2GB of page updates), you will hit this bug. There are two proposed solutions: 1) Take 2 quiescent archives. The first one makes sure that all the pages are updated to new timestamps. The second one should be a good archive (provided that you don't go on-line or run a tbcheck to increment the archive in the mean time). By strange coincidence, our customer was already doing this (2 backups, one handy, on-site and one shipped safely off-site). When we tried the restore, it didn't work (and is still under investigation) 2) Move to online 5.05 or later. We don't have much confidence in this either, as Informix have not produced a test-case to prove their fix. A possible test scenario *may* be create a database, take it off-line, and fiddle with the time-stamp (which is stored in the checkpoint page) before bringing it back on-line Of course, it's only the big, important sites that roll their timestamps :-) Andrew