Case study: A failure of Always On but a success of DBTwin AA Cluster

Case study: A failure of Always On but a success of DBTwin AA Cluster

We have an ERP customer who used Always On before purchasing our DBTwin Active-active Database Cluster, only to find that the performance decreased significantly after using Always On.

I know the reason. Let me explain it to you. It's like this:

Firstly, the ERP code often frequently creates table xxx_temp, followed by insert, update, delete, select, which heavily use this table xxx_temp. Finally, drop table xxx_temp is used, and

there is often no drop table, resulting in a large number of 'temporary' formal tables (called temporary tables by the customer, which is obviously different from the those starting with #

specified by SQL SERVER). According to our operational records, the number of such newly created temporary tables can reach over 120000 per day.

Secondly, Always On is something that synchronizes everything, so all these 'temporary tables' that should not be synchronized are strictly synchronized to the its secondary node.

Thirdly, the customer has chosen the Always On synchronour commit mode for data reliability.

When these three factors are combined, the performance will definitely be much slower than running standalone. However, our DBTwin AA cluster will never synchronize these kind of false

temporary tables, so there is no such kind of significant performance degradation. On the contrary, due to the automatic load balancing, automatic blocking process killing, guaranteed zero

data loss, simple and easy maintanence and so on, our DBTwin AA cluster runs very smoothly and performs well, and the customer is quite satisfied.

website: https://www.zhetides.com