WARNING Backup
A user on IDS 11.50.FC3 (AIX 6.1) asked why the message log repeatedly warned "Next backup of DBspace X must be level-0 backup." Fernando Nunes and Art Kagel explained it's not an error: Informix uses a 32-bit page timestamp to decide which pages belong in level-1/2 backups, and when that timestamp wraps (typically because too long has passed since the last level-0), modified pages could look older than the level-0 baseline, risking an unusable incremental. Taking a level-0 archive resets the baseline and clears the warning. A side discussion with IBM's John Miller clarified that modern versions use bitmaps rather than restamping very old pages, so the old "very slow backup" problem no longer applies.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi to ALL Hi to ALL In our company we are using "IBM Informix Dynamic Server Version 11.50.FC3" on AIX platform "6.1.0.0" The last few days I get a WARNING in the message log to perform a Level 0 backup. 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 backup. 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 backup. 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 backup. 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup Why is this happening ????? Regards Description: Description: CoopLogo1Description: Description: CoopLogo1 Cooperative Computer Society (S.E.M) Ltd 1306 Nicosia P.O.B. 25037 CY Tel: +357 22 673 901 Fax: +357 22 672 774 Achilleas Achilleos Official A OS and Databases Management <mailto:AchilleasAchilleos@semltd.com.cy> AchilleasAchilleos@semltd.com.cy --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw)
It's a long history.... Basically Informix uses the timestamp to see which pages need to be put in a L1 or L2 backup. Assuming the L0 was taken when the timestamp was 1000000 every page with a timestamp bigger than this must be put in L1/L2. But the timestamp is just a 32 bit number and can wrap around. It should not wrap around too quickly, but let's assume you spend too much time between L0s. The 32 bit could wrap around and become 500000. This would mean that the all the pages "stamped" would look older than the L0 timestamp, and as such they would not be elected to be put in an L1/L2. This would mean a corrupted backup. So, much before this happens, the engine warns you that the next backup has to be an L0. In some cases the timestamp can jump too quickly. I remember very old bugs (7.31) that could cause this... If your last L0 backup is not very old, you may want to check with tech support to see if something similar may be happening on your system. Also note that last time I checked, the L0 would "stamp" what we would call "very old pages", so that there is no risk of the situation above. If you run regular L0 and if you simply don't use L1 and L2 then just ignore the message. If you use L1 and L2 pay attention to it. I would assume the engine would not accept to run an L1/L2 after that message appears, but honestly I'd have to check if that happens. But some of the backup experts can easily check this. This issue was famous around late 7.31 and some 9.4 versions. I haven't faced any issues with this since V10. At the time it got known as the "very slow backup" problem, because the "very old timestamp pages stamping" was a terribly slow process than once in a while would turn a 1H backup into a 7/8H ones... Regards. On Fri, Sep 7, 2012 at 6:04 AM, Achilleas Achilleos < AchilleasAchilleos@semltd.com.cy> wrote: > Hi to ALL > > Hi to ALL > > In our company we are using "IBM Informix Dynamic Server Version 11.50.FC3" > > on AIX platform "6.1.0.0" > > The last few days I get a WARNING in the message log to perform a Level 0 > backup. > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup > > Why is this happening ????? > > Regards > > Description: Description: CoopLogo1Description: Description: CoopLogo1 > > Cooperative Computer Society (S.E.M) Ltd > > 1306 Nicosia > > P.O.B. 25037 CY > > Tel: +357 22 673 901 > > Fax: +357 22 672 774 > > Achilleas Achilleos > > Official A > > OS and Databases Management > > <mailto:AchilleasAchilleos@semltd.com.cy> AchilleasAchilleos@semltd.com.cy > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --00235452f64ced5f3604c91853e9
Because the timestamps on those dbspaces have wrapped making it impossible to determine the difference between very old pages and those that have been modified since the last level 0 archive. Taking a level 0 archive will reset the base timestamp for level 1 & level 2 archives and will cause the very old pages to have their timestamps updated. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Sep 7, 2012 at 1:04 AM, Achilleas Achilleos < AchilleasAchilleos@semltd.com.cy> wrote: > Hi to ALL > > Hi to ALL > > In our company we are using "IBM Informix Dynamic Server Version 11.50.FC3" > > on AIX platform "6.1.0.0" > > The last few days I get a WARNING in the message log to perform a Level 0 > backup. > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 backup. > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup > > Why is this happening ????? > > Regards > > Description: Description: CoopLogo1Description: Description: CoopLogo1 > > Cooperative Computer Society (S.E.M) Ltd > > 1306 Nicosia > > P.O.B. 25037 CY > > Tel: +357 22 673 901 > > Fax: +357 22 672 774 > > Achilleas Achilleos > > Official A > > OS and Databases Management > > <mailto:AchilleasAchilleos@semltd.com.cy> AchilleasAchilleos@semltd.com.cy > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f502ff8b95c5304c919d070
Just a note, Fernando. IB that the last issue you noted, slow backups caused by very old pages, was finally fixed around the 9.40/10.00 versions at some point. The archives no longer stop to update very old pages' timestamps rather IB that a background thread in the engine itself is launched to do that when an archive encounters a very old page. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Sep 7, 2012 at 4:23 AM, Fernando Nunes <domusonline@gmail.com>wrote: > It's a long history.... > Basically Informix uses the timestamp to see which pages need to be put in > a L1 or L2 backup. > Assuming the L0 was taken when the timestamp was 1000000 every page with a > timestamp bigger than this must be put in L1/L2. > But the timestamp is just a 32 bit number and can wrap around. It should > not wrap around too quickly, but let's assume you spend too much time > between L0s. > The 32 bit could wrap around and become 500000. This would mean that the > all the pages "stamped" would look older than the L0 timestamp, and as such > they would not be elected to be put in an L1/L2. This would mean a > corrupted backup. > > So, much before this happens, the engine warns you that the next backup has > to be an L0. > > In some cases the timestamp can jump too quickly. I remember very old bugs > (7.31) that could cause this... If your last L0 backup is not very old, you > may want to check with tech support to see if something similar may be > happening on your system. > > Also note that last time I checked, the L0 would "stamp" what we would call > "very old pages", so that there is no risk of the situation above. > If you run regular L0 and if you simply don't use L1 and L2 then just > ignore the message. If you use L1 and L2 pay attention to it. > I would assume the engine would not accept to run an L1/L2 after that > message appears, but honestly I'd have to check if that happens. But some > of the backup experts can easily check this. > > This issue was famous around late 7.31 and some 9.4 versions. I haven't > faced any issues with this since V10. At the time it got known as the "very > slow backup" problem, because the "very old timestamp pages stamping" was a > terribly slow process than once in a while would turn a 1H backup into a > 7/8H ones... > > Regards. > > On Fri, Sep 7, 2012 at 6:04 AM, Achilleas Achilleos < > AchilleasAchilleos@semltd.com.cy> wrote: > > > Hi to ALL > > > > Hi to ALL > > > > In our company we are using "IBM Informix Dynamic Server Version > 11.50.FC3" > > > > on AIX platform "6.1.0.0" > > > > The last few days I get a WARNING in the message log to perform a Level 0 > > backup. > > > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 backup. > > > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 backup. > > > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 backup. > > > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup > > > > Why is this happening ????? > > > > Regards > > > > Description: Description: CoopLogo1Description: Description: CoopLogo1 > > > > Cooperative Computer Society (S.E.M) Ltd > > > > 1306 Nicosia > > > > P.O.B. 25037 CY > > > > Tel: +357 22 673 901 > > > > Fax: +357 22 672 774 > > > > Achilleas Achilleos > > > > Official A > > > > OS and Databases Management > > > > <mailto:AchilleasAchilleos@semltd.com.cy> > AchilleasAchilleos@semltd.com.cy > > > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > --00235452f64ced5f3604c91853e9 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec5186d68a2860a04c919ea4f
Probably... I just remember personal stories with 7.31 and that this wa a famous issue. I'd like to see this completely changed in a way that would avoid complete data scans in L1 an L2... Maybe using a bitmap or extending the existing ones... But I imagine that given the sensitivity of this code it's not likely to happen soon... On Sep 7, 2012 11:18 AM, "Art Kagel" <art.kagel@gmail.com> wrote: > Just a note, Fernando. IB that the last issue you noted, slow backups > caused by very old pages, was finally fixed around the 9.40/10.00 versions > at some point. The archives no longer stop to update very old pages' > timestamps rather IB that a background thread in the engine itself is > launched to do that when an archive encounters a very old page. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated nor > those of the entities themselves. > > On Fri, Sep 7, 2012 at 4:23 AM, Fernando Nunes <domusonline@gmail.com > >wrote: > > > It's a long history.... > > Basically Informix uses the timestamp to see which pages need to be put > in > > a L1 or L2 backup. > > Assuming the L0 was taken when the timestamp was 1000000 every page with > a > > timestamp bigger than this must be put in L1/L2. > > But the timestamp is just a 32 bit number and can wrap around. It should > > not wrap around too quickly, but let's assume you spend too much time > > between L0s. > > The 32 bit could wrap around and become 500000. This would mean that the > > all the pages "stamped" would look older than the L0 timestamp, and as > such > > they would not be elected to be put in an L1/L2. This would mean a > > corrupted backup. > > > > So, much before this happens, the engine warns you that the next backup > has > > to be an L0. > > > > In some cases the timestamp can jump too quickly. I remember very old > bugs > > (7.31) that could cause this... If your last L0 backup is not very old, > you > > may want to check with tech support to see if something similar may be > > happening on your system. > > > > Also note that last time I checked, the L0 would "stamp" what we would > call > > "very old pages", so that there is no risk of the situation above. > > If you run regular L0 and if you simply don't use L1 and L2 then just > > ignore the message. If you use L1 and L2 pay attention to it. > > I would assume the engine would not accept to run an L1/L2 after that > > message appears, but honestly I'd have to check if that happens. But some > > of the backup experts can easily check this. > > > > This issue was famous around late 7.31 and some 9.4 versions. I haven't > > faced any issues with this since V10. At the time it got known as the > "very > > slow backup" problem, because the "very old timestamp pages stamping" > was a > > terribly slow process than once in a while would turn a 1H backup into a > > 7/8H ones... > > > > Regards. > > > > On Fri, Sep 7, 2012 at 6:04 AM, Achilleas Achilleos < > > AchilleasAchilleos@semltd.com.cy> wrote: > > > > > Hi to ALL > > > > > > Hi to ALL > > > > > > In our company we are using "IBM Informix Dynamic Server Version > > 11.50.FC3" > > > > > > on AIX platform "6.1.0.0" > > > > > > The last few days I get a WARNING in the message log to perform a > Level 0 > > > backup. > > > > > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 > backup. > > > > > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 > backup. > > > > > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 > backup. > > > > > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup > > > > > > Why is this happening ????? > > > > > > Regards > > > > > > Description: Description: CoopLogo1Description: Description: CoopLogo1 > > > > > > Cooperative Computer Society (S.E.M) Ltd > > > > > > 1306 Nicosia > > > > > > P.O.B. 25037 CY > > > > > > Tel: +357 22 673 901 > > > > > > Fax: +357 22 672 774 > > > > > > Achilleas Achilleos > > > > > > Official A > > > > > > OS and Databases Management > > > > > > <mailto:AchilleasAchilleos@semltd.com.cy> > > AchilleasAchilleos@semltd.com.cy > > > > > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > -- > > Fernando Nunes > > Portugal > > > > http://informix-technology.blogspot.com > > My email works... but I don't check it frequently... > > > > --00235452f64ced5f3604c91853e9 > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --bcaec5186d68a2860a04c919ea4f > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --00248c768d86e3362904c92c5012
Many many years ago when we changed the backup method from requiring the update to very old pages to using bitmaps. These bitmaps are used to ensure the correct version of the page is acquired and there is no background thread used to update these stamps at all. If the pagestamp becomes old, we do not care for level 0 archives. Informix does not update very old pages at all. John F. Miller III STSM, Embedability Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 09/08/2012 01:14:47 AM: > From: "Fernando Nunes" <domusonline@gmail.com> > To: ids@iiug.org > Date: 09/08/2012 01:15 AM > Subject: Re: WARNING Backup [28266] > Sent by: ids-bounces@iiug.org > > Probably... I just remember personal stories with 7.31 and that this wa a > famous issue. I'd like to see this completely changed in a way that would > avoid complete data scans in L1 an L2... Maybe using a bitmap or extending > the existing ones... But I imagine that given the sensitivity of this code > it's not likely to happen soon... > On Sep 7, 2012 11:18 AM, "Art Kagel" <art.kagel@gmail.com> wrote: > > > Just a note, Fernando. IB that the last issue you noted, slow backups > > caused by very old pages, was finally fixed around the 9.40/10.00 versions > > at some point. The archives no longer stop to update very old pages' > > timestamps rather IB that a background thread in the engine itself is > > launched to do that when an archive encounters a very old page. > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > other organization with which I am associated either explicitly, > > implicitly, or by inference. Neither do those opinions reflect those of > > other individuals affiliated with any entity with which I am affiliated nor > > those of the entities themselves. > > > > On Fri, Sep 7, 2012 at 4:23 AM, Fernando Nunes <domusonline@gmail.com > > >wrote: > > > > > It's a long history.... > > > Basically Informix uses the timestamp to see which pages need to be put > > in > > > a L1 or L2 backup. > > > Assuming the L0 was taken when the timestamp was 1000000 every page with > > a > > > timestamp bigger than this must be put in L1/L2. > > > But the timestamp is just a 32 bit number and can wrap around. It should > > > not wrap around too quickly, but let's assume you spend too much time > > > between L0s. > > > The 32 bit could wrap around and become 500000. This would mean that the > > > all the pages "stamped" would look older than the L0 timestamp, and as > > such > > > they would not be elected to be put in an L1/L2. This would mean a > > > corrupted backup. > > > > > > So, much before this happens, the engine warns you that the next backup > > has > > > to be an L0. > > > > > > In some cases the timestamp can jump too quickly. I remember very old > > bugs > > > (7.31) that could cause this... If your last L0 backup is not very old, > > you > > > may want to check with tech support to see if something similar may be > > > happening on your system. > > > > > > Also note that last time I checked, the L0 would "stamp" what we would > > call > > > "very old pages", so that there is no risk of the situation above. > > > If you run regular L0 and if you simply don't use L1 and L2 then just > > > ignore the message. If you use L1 and L2 pay attention to it. > > > I would assume the engine would not accept to run an L1/L2 after that > > > message appears, but honestly I'd have to check if that happens.But some > > > of the backup experts can easily check this. > > > > > > This issue was famous around late 7.31 and some 9.4 versions. I haven't > > > faced any issues with this since V10. At the time it got known as the > > "very > > > slow backup" problem, because the "very old timestamp pages stamping" > > was a > > > terribly slow process than once in a while would turn a 1H backup into a > > > 7/8H ones... > > > > > > Regards. > > > > > > On Fri, Sep 7, 2012 at 6:04 AM, Achilleas Achilleos < > > > AchilleasAchilleos@semltd.com.cy> wrote: > > > > > > > Hi to ALL > > > > > > > > Hi to ALL > > > > > > > > In our company we are using "IBM Informix Dynamic Server Version > > > 11.50.FC3" > > > > > > > > on AIX platform "6.1.0.0" > > > > > > > > The last few days I get a WARNING in the message log to perform a > > Level 0 > > > > backup. > > > > > > > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 > > backup. > > > > > > > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 > > backup. > > > > > > > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 > > backup. > > > > > > > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 backup > > > > > > > > Why is this happening ????? > > > > > > > > Regards > > > > > > > > Description: Description: CoopLogo1Description: Description: CoopLogo1 > > > > > > > > Cooperative Computer Society (S.E.M) Ltd > > > > > > > > 1306 Nicosia > > > > > > > > P.O.B. 25037 CY > > > > > > > > Tel: +357 22 673 901 > > > > > > > > Fax: +357 22 672 774 > > > > > > > > Achilleas Achilleos > > > > > > > > Official A > > > > > > > > OS and Databases Management > > > > > > > > <mailto:AchilleasAchilleos@semltd.com.cy> > > > AchilleasAchilleos@semltd.com.cy > > > > > > > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > -- > > > Fernando Nunes > > > Portugal > > > > > > http://informix-technology.blogspot.com > > > My email works... but I don't check it frequently... > > > > > > --00235452f64ced5f3604c91853e9 > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --bcaec5186d68a2860a04c919ea4f > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --00248c768d86e3362904c92c5012 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
I think I'll need some clarification about this... I'll do some investigation and then come back... Thanks! On Sat, Sep 8, 2012 at 4:04 PM, John Miller iii <miller3@us.ibm.com> wrote: > Many many years ago when we changed the backup method from requiring the > update to very old pages to using bitmaps. These bitmaps are used to ensure > the correct version of the page is acquired and there is no background > thread > used to update these stamps at all. If the pagestamp becomes old, we do > not care for level 0 archives. Informix does not update very old pages at > all. > > John F. Miller III > STSM, Embedability Architect > miller3@us.ibm.com > 503-578-5645 > IBM Informix Dynamic Server (IDS) > > ids-bounces@iiug.org wrote on 09/08/2012 01:14:47 AM: > > > From: "Fernando Nunes" <domusonline@gmail.com> > > To: ids@iiug.org > > Date: 09/08/2012 01:15 AM > > Subject: Re: WARNING Backup [28266] > > Sent by: ids-bounces@iiug.org > > > > Probably... I just remember personal stories with 7.31 and that this wa a > > > famous issue. I'd like to see this completely changed in a way that would > > > avoid complete data scans in L1 an L2... Maybe using a bitmap or > extending > > the existing ones... But I imagine that given the sensitivity of this > code > > it's not likely to happen soon... > > On Sep 7, 2012 11:18 AM, "Art Kagel" <art.kagel@gmail.com> wrote: > > > > > Just a note, Fernando. IB that the last issue you noted, slow backups > > > caused by very old pages, was finally fixed around the 9.40/10.00 > versions > > > at some point. The archives no longer stop to update very old pages' > > > timestamps rather IB that a background thread in the engine itself is > > > launched to do that when an archive encounters a very old page. > > > > > > Art > > > > > > Art S. Kagel > > > Advanced DataTools (www.advancedatatools.com) > > > Blog: http://informix-myview.blogspot.com/ > > > > > > Disclaimer: Please keep in mind that my own opinions are my own > opinions > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor > any > > > other organization with which I am associated either explicitly, > > > implicitly, or by inference. Neither do those opinions reflect those of > > > > other individuals affiliated with any entity with which I am affiliated > nor > > > those of the entities themselves. > > > > > > On Fri, Sep 7, 2012 at 4:23 AM, Fernando Nunes <domusonline@gmail.com > > > >wrote: > > > > > > > It's a long history.... > > > > Basically Informix uses the timestamp to see which pages need to be > put > > > in > > > > a L1 or L2 backup. > > > > Assuming the L0 was taken when the timestamp was 1000000 every page > with > > > a > > > > timestamp bigger than this must be put in L1/L2. > > > > But the timestamp is just a 32 bit number and can wrap around. It > should > > > > not wrap around too quickly, but let's assume you spend too much time > > > > > between L0s. > > > > The 32 bit could wrap around and become 500000. This would mean that > the > > > > all the pages "stamped" would look older than the L0 timestamp, and > as > > > such > > > > they would not be elected to be put in an L1/L2. This would mean a > > > > corrupted backup. > > > > > > > > So, much before this happens, the engine warns you that the next > backup > > > has > > > > to be an L0. > > > > > > > > In some cases the timestamp can jump too quickly. I remember very old > > > > bugs > > > > (7.31) that could cause this... If your last L0 backup is not very > old, > > > you > > > > may want to check with tech support to see if something similar may > be > > > > happening on your system. > > > > > > > > Also note that last time I checked, the L0 would "stamp" what we > would > > > call > > > > "very old pages", so that there is no risk of the situation above. > > > > If you run regular L0 and if you simply don't use L1 and L2 then just > > > > > ignore the message. If you use L1 and L2 pay attention to it. > > > > I would assume the engine would not accept to run an L1/L2 after that > > > > > message appears, but honestly I'd have to check if that happens.But > some > > > > of the backup experts can easily check this. > > > > > > > > This issue was famous around late 7.31 and some 9.4 versions. I > haven't > > > > faced any issues with this since V10. At the time it got known as the > > > > "very > > > > slow backup" problem, because the "very old timestamp pages stamping" > > > > was a > > > > terribly slow process than once in a while would turn a 1H backup > into a > > > > 7/8H ones... > > > > > > > > Regards. > > > > > > > > On Fri, Sep 7, 2012 at 6:04 AM, Achilleas Achilleos < > > > > AchilleasAchilleos@semltd.com.cy> wrote: > > > > > > > > > Hi to ALL > > > > > > > > > > Hi to ALL > > > > > > > > > > In our company we are using "IBM Informix Dynamic Server Version > > > > 11.50.FC3" > > > > > > > > > > on AIX platform "6.1.0.0" > > > > > > > > > > The last few days I get a WARNING in the message log to perform a > > > Level 0 > > > > > backup. > > > > > > > > > > 12:20:32 WARNING: Next backup of DBspace aabbdbs must be level-0 > > > backup. > > > > > > > > > > 12:20:32 WARNING: Next backup of DBspace bbccdbs must be level-0 > > > backup. > > > > > > > > > > 12:20:32 WARNING: Next backup of DBspace ccdddbs must be level-0 > > > backup. > > > > > > > > > > 12:20:32 WARNING: Next backup of DBspace ddeedbs must be level-0 > backup > > > > > > > > > > Why is this happening ????? > > > > > > > > > > Regards > > > > > > > > > > Description: Description: CoopLogo1Description: Description: > CoopLogo1 > > > > > > > > > > Cooperative Computer Society (S.E.M) Ltd > > > > > > > > > > 1306 Nicosia > > > > > > > > > > P.O.B. 25037 CY > > > > > > > > > > Tel: +357 22 673 901 > > > > > > > > > > Fax: +357 22 672 774 > > > > > > > > > > Achilleas Achilleos > > > > > > > > > > Official A > > > > > > > > > > OS and Databases Management > > > > > > > > > > <mailto:AchilleasAchilleos@semltd.com.cy> > > > > AchilleasAchilleos@semltd.com.cy > > > > > > > > > > --Boundary_(ID_IlhOsBjRmsjJe2x63UQiGw) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > > > > > > -- > > > > Fernando Nunes > > > > Portugal > > > > > > > > http://informix-technology.blogspot.com > > > > My email works... but I don't check it frequently... > > > > > > > > --00235452f64ced5f3604c91853e9 > > > > > > > > > > > > > > > > > > > > > > > > > > > *******************************************************************************@@