A technology machine uses SQL Server Express to collect the data like temperature… The database is updated say every several second (i.e. low trafic). The machine and its SQL Server must work independently on anything. Sometimes the technology computer (i.e. SQL Server) is switched-off with the machine.
The central SQL Server Standard Edition should collect the data form many machines like the above.
What scenario would you recommend?
- The machine sends each new row of a table when it is created (i.e. each several seconds one row).
- The machine activates the process of sending the data say each hour, and sends all the rows with the newly collected data.
- Any other approach?
If I understand the Service Broker idea well, there will be a single name of the request message type, a single name of the reply message type, a single name of contract. The related databases on the SQL machines will each have one message queue, and the related service.
I am very new to Service Broker. The tutorial examples show how to send messages as XML fragments. Is it the real world way to send the rows of the table? How can I reliably convert the result of a SELECT command to the XML fragment and back?
Thanks, Petr
Attention: The related question Service Broker — how to extract the rows from the XML message? was created.
I also recommend sending as the the database is updated, one message per row inserted (one message per statement, from a trigger as JAnis suggests, also works fine if your INSERT statements do not insert huge number of rows in a single statement).
The reason why is better to send many small messages rather than one big message is that processing one XML payload on the RECEIVE is less efficient than processing many small XML payloads.
I’ve seen similar deployments to what you’re trying to do, see High Volume Contigous Real Time Audit And ETL. I aslo recommend you read Reusing Conversations.
Service Broker will handle very well the Express instance going on and off or being disconnected for long periods. It will simply retain the messages sent and deliver them once connectivity is restored. You just have to make sure the 10GB max database size limit of Express is enough to retain messages for as long as needed, until connectivity is back.
What Service Broker will handle poorly is if the Express appears as different DNS names every time it connect back (think a laptop that connects from home, from office and from Starbucks). Service Broker uses database routing to send acks from central server to your Express instance and the routing require a static DNS. Also is important that the Express instance is reachable from the central server (ie. is not behind Network Address Translation). For a mobile instance (the laptop mentioned before) both the dynamic name and the fact that most time will connect from behind NAT will cause problems. Using a VPN can address the issues, but is cumbersome.