FW: HDR unusable with 9.40

Ajay, Thank You very much for pointing to the major reason: physical log size I took a look at the 'onstat -a' output I made on both servers when I first noticed the problem: Physical log was 78% full on Secondary. That means, that blocking checkpoint was triggered by the 75% fullness of the physical log on secondary. That is, index size exceeded 75% of the physical log size I was able to create all indexes after I considerably increased physical log size on both servers. Unfortunately, that workaround (to make physical log size at least 33.3% larger then the biggest index I'm going to build from scratch) is not acceptable for our production database: we have two 5-GB detached indexes (about 2.5 mln pages) build against 30-GB tables, and our physical log is 'just' 2GB (physical log space must be contagious, and one can't allocate larger contagious space under pre-9.40). Formally, I can try to allocate 'extended capacity' 16-GB chunk under 9.40 and dramatically increase our physical log to, say, 8 or even 16 GB... Frankly speaking, I'm not going to do that for the production system, just because I'm not sure that IDS 9.40 is fully tested with PHYSFILE>2000000 (PHYSFILE limit in pre-9.40 IDS) P.S. Initial posting 'subject' should be slightly modified: HDR is unusable with 9.40 FOR LARGE SYSTEMS ------------------------------------------ Alexey Sonkin -----Original Message----- From: ajaykg68@yahoo.com [mailto:ajaykg68@yahoo.com] The bug number for this problem is 167294. Yes. Increasing physical log is a workaround. Forcing a checkpoint on primary during index transfer can avoid this problem. -Ajay Gupta Fernando Nunes <spam@domus.online.pt> wrote in message news:<2o3iftF6hbpkU1@uni-berlin.de>... > Madison Pruet wrote: > > Could you let everyone know the bug number? > > > > > > "Ajay Gupta" <ajaykg68@yahoo.com> wrote in message > > news:26ad1e92.0408121748.c164043@posting.google.com... > > > >>Yes. This is a known bug and is fixed in later release of 9.40. > >> > >>-Ajay Gupta > >> > > Hello Ajay. > > I'm also interested in this. The description seems like a bug only > corrected in late 7.31 versions, but if it's specific to 9.40 I'm very > interested in this. > > Also if there is a tech support case it would be nice to know which is it. > > P.S.: could a bigger physical log improve the behavior? > > Kind regards, > > Fernando Nunes sending to informix-list

Alexey Sonkin wrote: > Ajay, > > Thank You very much for pointing to the major reason: > physical log size > > I took a look at the 'onstat -a' output I made on both servers > when I first noticed the problem: Physical log was 78% full on > Secondary. > > That means, that blocking checkpoint was triggered by the 75% fullness > of the physical log on secondary. That is, index size exceeded 75% of > the physical log size > > I was able to create all indexes after I considerably increased physical > log size on both servers. > > Unfortunately, that workaround (to make physical log size at least 33.3% > larger then the biggest index I'm going to build from scratch) is not > acceptable for our production database: > we have two 5-GB detached indexes (about 2.5 mln pages) build against 30-GB > tables, and our physical log is 'just' 2GB (physical log space > must be contagious, and one can't allocate larger contagious space > under pre-9.40). > > Formally, I can try to allocate 'extended capacity' 16-GB chunk under 9.40 > and dramatically increase our physical log to, say, 8 or even 16 GB... > Frankly speaking, I'm not going to do that for the production system, just > because I'm not sure that IDS 9.40 is fully tested with PHYSFILE>2000000 > (PHYSFILE limit in pre-9.40 IDS) > > P.S. Initial posting 'subject' should be slightly modified: > HDR is unusable with 9.40 FOR LARGE SYSTEMS > > ------------------------------------------ > Alexey Sonkin > > > -----Original Message----- > From: ajaykg68@yahoo.com [mailto:ajaykg68@yahoo.com] > > The bug number for this problem is 167294. > > Yes. Increasing physical log is a workaround. Forcing a checkpoint on > primary during index transfer can avoid this problem. > > -Ajay Gupta > > Fernando Nunes <spam@domus.online.pt> wrote in message > news:<2o3iftF6hbpkU1@uni-berlin.de>... > >>Madison Pruet wrote: >> >>>Could you let everyone know the bug number? >>> >>> >>>"Ajay Gupta" <ajaykg68@yahoo.com> wrote in message >>>news:26ad1e92.0408121748.c164043@posting.google.com... >>> >>> >>>>Yes. This is a known bug and is fixed in later release of 9.40. >>>> >>>>-Ajay Gupta >>>> >> >>Hello Ajay. >> >>I'm also interested in this. The description seems like a bug only >>corrected in late 7.31 versions, but if it's specific to 9.40 I'm very >>interested in this. >> >>Also if there is a tech support case it would be nice to know which is it. >> >>P.S.: could a bigger physical log improve the behavior? >> >>Kind regards, >> >>Fernando Nunes > > sending to informix-list Just a few notes: 1- It's a bug and support is fixing it 2- The physical log idea appeared after seeing the cause, and it's just a workaround which as any order workaround may or may not fit a specific situation, but should _never_ be taken as a definite solution. 3- I completely agree with you that you shouldn't use it in production 4- I'm not sure you'd need such a big physical log. It may be a bit more complex if the situation only happens due to a race condition between the primary and secondary. But I really don't know. Regards.