Hi everyone,

Here is the configuration that we will have and so … we are thinking about Database synchronisation strategy. Well, maybe you have some advices for me

We are in release 7.1.1, and for the latest environment we have 2 serveurs. In each server we have every webMethods components and a local Database engine.

In the running service mode, some components will be “active” and some other “inactive” (Services stopped or package disabled). On the second server every components inactive will be active and every active will be inactive. That means :

Server 1 : Active → IS/TN, Broker
Server 2 : Active → Optimize, IS/PRT, MWS, Task Engine

On each serveur with have to local Database :
Server 1 : DB A (Active), DB B (Inactive)
Server 2 : DB A (Inactive), DB B (Active)
Each database have the same table schema.

The goal is : if server 1 crashed, we switch everything on server 2 and reactivate every inactive components. (Same thing if server 2 crashed).

We have SQL Server 2005.

We know that for switch procedure “inactive” Database must be synchronise with the active database on the other servers.

1/ can we copy every thin from inactive database to active database every X hour (for example)?
2/ Do we have only to copy specific table ?

Thanks for your advices

Hi Mate,

Firstly, your scheme sounds a bit strange, can you not afford any other servers here? Is there too much load if you just combine them all together into one server and use the second server as a total “cold” node? Is the justification something else other than cost?

I think the solution to your direct problem however is to investigate what tables to what. It sounds like when you run the DB installer tool you are selecting “ALL” tables. I would suggest you work out what sets of tables are being used by IS/TN on the first server and then what tables are being used by “Optimize, IS/PRT, MWS, Task Engine” on the other server. This shouldnt be too hard, the DB tool has several “PRODUCT - XXX” entries which cover these guys. Select say “PRODUCT - Integration Server” and then chose “print” instead of “create”, this will tell you what database sections it is using. From these you can work out what direct tables are being used. Once you know what tables are being used you know what to move.

Still I am concerned about your architecture, it looks like most of the stuff is on the second server. I am generally in favour of putting Optimize on its own machine, I dont like to have monitoring software running on the same hardware as the things it is monitoring, Optimize has a habit of using LOTS of CPU and FILLING up the database really quick if you dont tune it down.

I hope this helps

Louis Zezeran

Customware Asia Pacific
www.customware.net