MS-SQL Server 2005: Initialisation d'un abonnement de fusion avec un autre emplacement d'instantané

Question

Nous avons démarré une réplication de fusion outre-mer il y a un an et tout se passe bien jusqu'à maintenant. Mon problème est que nous avons maintenant tellement de données dans notre système que tout crash sur l'un des serveurs de l'abonné sera un désastre: réinitialiser un abonnement de manière standard prendra des jours (nos connexions sont définitivement lentes, mais déjà très chères)! Parmi les idées que j'ai suivi sont les suivantes:

1. faire une copie de la base de données originale, congeler, envoyer les fichiers par avion à l'abonné, et lancer la réplication sans instantané: c'est quelque chose qui était fait traditionnellement avec les anciennes versions de SQL, mais il semble un peu désordre pour moi: j'aurais de mettre les données de mon éditeur en mode lecture seule et arrêter tous les réplications jusqu'à ce que le fonctionnement est REMPLI .
2. faire un instantané des données, envoyer les fichiers de capture instantanée à l'étranger, les installer sur l'abonné, et indiquent le nouvel emplacement de l'instantané comme un autre emplacement dans les propriétés de réplication . Celui-ci me semble juste (pas besoin de suspendre les réplications en cours, pas de gel des données), mais, sur ce point , l'aide de Microsoft ne ... aide. Je suis sûr que certains d'entre vous ont déjà fait l'expérience d'une telle situation.

Quel était ton choix?

EDIT: bien sûr, on pourrait dire "Pourquoi ne pas essayer vos idées", mais cela prendra des heures (plusieurs instances de sql-servers, de machines virtuelles, et tout ça ...)), et je pensais que le gars qui l'a fait n'aura besoin que de 2 minutes pour expliquer son idée. Et je serais l'homme le plus heureux si quelqu'un acceptait de perdre 2 minutes de son temps pour m'épargner des heures de travail acharné ...

Answer 1

Je devais faire quelque chose de similaire à cela lors de la réplication des données de Los Angeles, en Californie vers la Chine. L'accrochage aurait pris 44 jours pour charger en utilisant des méthodes normales.

Ce que j'ai fait était de configurer la réplication SQL pour utiliser un chemin local vers l'instantané. J'ai ensuite désactivé le travail transactionnel (dans votre cas, le travail de fusion). J'ai ensuite couru le claquement. J'ai compressé les fichiers de la Californie vers la Chine. Quand ils sont arrivés en Chine, je les ai décompressés et mis dans le même dossier que celui que j'avais utilisé en Californie. J'ai alors couru le distrib.exe à partir de la ligne de commande sur le serveur en Chine. Cela a chargé les données dans la table en Chine. Une fois le composant logiciel enfichable chargé, j'ai arrêté le distributeur sur le serveur en Chine et démarré le distributeur normal sur le serveur en Californie.

Cette méthode n'a pris que 28 heures au lieu de plus d'un mois.

Si vos données prennent plus de deux jours pour arriver à destination, vous devrez modifier la publication et augmenter la quantité de données pouvant être mises en file d'attente ou l'expéditeur sera expiré et un nouvel instantané devra être pris.

Answer 2

Nous venons de traverser quelque chose comme ça, et ce n'est pas joli. Même si tous les serveurs impliqués étaient locaux, cela prenait encore beaucoup de temps. Juste pour rendre les choses plus difficiles, au moins avec SQL 2000, l'instantané échouera si la cabine compressée dépasse 4 Gig.

Le meilleur conseil que je puisse vous offrir est de vous assurer que chaque site dispose de bonnes sauvegardes. Avec cela, au moins les données n'auraient pas à être transmises manuellement à l'abonné.