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.co m...
> >
> >>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.