Stockage de certaines données SQL Server hors ligne

Question

Je commence à concevoir un nouveau système de gestion de données de test de laboratoire avec plusieurs (environ 30) stations de test.

Le système doit pouvoir collecter des données hors ligne en cas de panne de réseau. Chaque station conserverait une copie à jour, en lecture seule, des structures de test (spécifications, types d'entités, règles métier/flux de travail, etc.), mais pas des données de test. Les données de test réelles seraient stockées localement si le serveur était introuvable.

Il devrait y avoir une sorte de synchronisation pour se préparer à une panne de réseau. La synchronisation tirerait les structures de test mises à jour. Une autre synchronisation pousserait les données de test non sauvegardées.

Comment me conseillez-vous d'atteindre cet objectif? Des mises en garde?

Idées/Pensées:

1. Installez SQL Server sur chaque machine et écrire des scripts pour synchroniser le serveur et les clients (semble coûteux et surpuissant).
2. Enregistrez la copie locale des données dans des fichiers de données brutes définis par l'application avec des scripts de synchronisation.
3. Y at-il quelque chose de construit dans SQL Server pour permettre aux clients de collecter des données hors ligne?
4. Sauvegardez toutes les données localement, puis cliquez sur un bouton "Transférer" pour transférer les données sur le réseau.

Environnement: MS SQL Server en cours d'exécution sur Windows Server 2008

Answer 1

Utilisez les instances SQL Express locales et transmettez les données via Service Broker. Voir High Volume Contiguos Real Time Audit and ETL pour une explication pourquoi c'est mieux que la réplication de plusieurs points de vue, y compris le prix, la performance et la fiabilité. Avec la réplication, vous auriez besoin d'une licence supérieure à SQL Express sur tous les nœuds périphériques (Express ne pouvant être abonné que dans une topologie de réplication). L'utilisation de SSB pour pousser les données permet d'avoir des instances SQL Express à la périphérie et ne nécessite qu'un serveur central sous licence non-express. Cela signifie que vous pouvez facilement déployer la solution sur des dizaines de stations de travail sans vous soucier des coûts de licence SQL Server.

Un autre avantage est la performance et le débit. SSB a été conçu pour gérer des centaines et des milliers de pairs en communication et a été conçu avec un contrôle de flux hiérarchique sophistiqué capable de traiter des tentatives pour des milliers de destinations en présence de défaillances réseau (je le sais car j'étais membre de la SSB) équipe). La réplication par comparaison utilise le protocole TDS pour l'échange de données, s'appuie sur des jobs SQL Agent et gère les pannes de réseau de manière simpliste, ce qui peut entraîner la répétition de plusieurs cycles lors de nouvelles tentatives. Dans l'ensemble, SSB peut gérer de grands déploiements (je connais des déploiements de +1500 serveurs, et MySpace est devenu public avec leur deployment of +500 servers qui repose sur SSB pour échanger les données.) Globalement, à grande échelle, SSB surpasse la réplication à tout point de vue.

Je voudrais également faire valoir qu'une solution basée sur la messagerie plutôt que sur la copie de lignes de table est plus appropriée pour la description du problème: pousser les résultats vers le serveur central.

L'inconvénient (et n'est pas mineur) est la courbe d'apprentissage abrupte requise pour déployer initialement la SSB. Le savoir-faire existe mais il est difficile à trouver, et SSB ne dispose pas des outils perfectionnés tels que Replication Monitor qui rendent le déploiement d'une simple topologie de réplication simple. D'autre part, SSB a un grand avantage lors de la mise à niveau des déploiements, comme 2005/2008/2008R2 versions are perfectly compatible.

Answer 2

Ma première pensée serait merge replication avec des copies locales (SQL Server Compact) de la base de données.

Answer 3

Il semble que la réplication SQL Server soit la solution que vous souhaitez extraire. La réplication de fusion permettra aux stations de test locales de recevoir la copie des données du serveur et de renvoyer les données collectées pendant les interruptions du réseau.