Can ER replicate complex transaction effectively?

I have some complex transactions to be replicated by ER (Enterprise Replicate).Complex transaction mean that many insert and update with complex where clause in one transaction. We find ER replicate complex transaction very slowly and the database server run very slowly too compare to the case without ER. who know how to solve this problem? who know the cause of this problem? who face the same problem? please help me or tell me the similar case. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.

You did not state which level of informix that you are using, but I'm guessing that you are not on 7.31. I'm also guessing that the transaction has in excess of 10,000 rows that are being updated. In pre 7.31 versions there was a problem with a phase of the collection of data on the source instance. This phase is called "grouper compression". This phase is done because we have to match the original before image of the row with the final after image. This must be done to maintain local delete tables as well as to determine if an update needs to be changed to a delete/insert when the primary key is changed. This is necessary for conflict resolution. In pre-7.31 versions grouper compression could take several hours if the number of updates in the transaction was large. I've see situations where a 100,000 row update could take over a day to process. We modified the compression algorthim in 7.31/9.2 and now this phase for a 100,000 row update transaction usually takes less than 30 secs to get through grouper compression. Unfortunatly, this change can not be backported to pre-7.31 code. The only solution is to break the transaction into smaller pieces or to move to 7.31 You can determine if this is what is happening by running "onstat -g grp E" and seeing if any of the grouper evaluators are in the compression phase for an extended period of time. There are still some issues with large transactions. For instance, the transaction must be transmitted to the targets as a unit. That means that if you have any problems with the network, then the entire transaction must be re-transmitted. Also, if you have a long running transaction you will not be able to apply any data on the target until the transaction completes on the source. By breaking the program into smaller units, you will be able to apply changes made by the program on the targets while the original program is still running on the source. This can speed up the total replication process. This does mean that you will need to build in some form of "restart" into the application, but it does provide the ability to get data applied on the targets faster. fuexplorer@my-deja.com wrote: > I have some complex transactions to be replicated by ER (Enterprise > Replicate).Complex transaction mean that many insert and update with complex > where clause in one transaction. We find ER replicate complex transaction > very slowly and the database server run very slowly too compare to the case > without ER. who know how to solve this problem? who know the cause of this > problem? who face the same problem? please help me or tell me the similar > case. > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.