I completely agree with you,
this has to be considered as a bug.

Checkpoints in a HDR system must be asynchronous/independents between
servers.

Please let us know the results of the opened case.

Regards


----- Original Message -----
From: "Fernando Nunes" <spam@domus.online.pt>
To: <informix-list@iiug.org>
Sent: Wednesday, May 19, 2004 6:40 PM
Subject: Re: Extremly long checkpoints: How to find the reason and solve the


> Francisco Roldan wrote:
> > HDR Systems are not optimized for having the secondary server for
> > DSS . Sounds logic because HDR is oriented for High Availability
Systems,
> > => OLTP Systems. In that time the company wanted the primary server
> > for the Production System, and the Secondary Server for up to date
Reports
> > .
> > I learned this by the hard way ....
> > I hope this message helps people who are evaluating HDR .
> >
>
> I've been working in an environment where customer uses secondary mainly
> for data extraction (DSS queries and jobs and extraction for DW).
>
> There were and still are problems regarding HDR which can cause the
> situation you mentioned. Some are related to heavy load on the secondary
> and one is (I think) caused by a (as of recently) known bug, related to
> critical sections and checkpoint holding on secondary.
>
> This situations MUST be considered as BUGS and not as "design
> orientation". We currently have an open case, under investigation by IBM
> technical support.
>
> I'd also like to point one fact: Around 9.30.UC1 there was a version
> which forced the same ONCONFIG parameters on primary and secondary for
> things like BUFFERS, CPUVPs etc. This would inhibit a configuration
> where the resources were different between primary and secondary. This
> was eventually considered a bug and corrected. This clearly states that
> you can use the secondary for different purposes then the primary.
>
> The normal and desirable behaviour, in case secondary as too much work
> is to stop replication and eventually recover. DRPINGTIMEOUT has also
> this objective.
> Of course that, if you intend your HDR environment to be mainly a
> stand-by database, you won't want this to happen, but in that case you
> shouldn't load the secondary too much...
>
> Regards,
>
> Fernando Nunes
>
>


sending to informix-list

Francisco Roldan wrote:

> I completely agree with you,
> this has to be considered as a bug.
>
> Checkpoints in a HDR system must be asynchronous/independents between
> servers.

Not quite. They also mark the consistency point between the two servers.
And the logging mode of the databases also influence the synchronism
between the two servers. Buffered vs unbuffered logging makes a difference.

All this is by design. We can argument that it should be different...

Regards.