Re: Extremly long checkpoints: How to find the reason and solve the

I don't have the DSS Query right now, as a matter a fact , I don't even work on the same company where I had that problem. In that time, the decision was to migrate to Enterprise Replication because of this problem and primary because of the replication granularity flexibility allowed by ER. For the record :

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