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

Question

Nous avons commencé une réplication de fusion à l'étranger il y a 1 an et tout va bien jusqu'à maintenant. Mon problème est que nous avons maintenant tellement de données dans notre système que toute panne sur l'un des serveurs de l'abonné sera un désastre: la réinitialisation d'un abonnement en mode standard prendra des jours (nos connexions sont vraiment lentes, mais déjà très très chères)! Parmi les idées que j'ai suivies figurent les suivantes:

1. faire une copie de l'original base de données, geler, envoyer les fichiers par avion jusqu'à l'abonné, et lancer la réplication sans instantané: c'est quelque chose qui était fait traditionnellement avec les plus âgés versions de SQL, mais ça sonne peu désordonné avec moi: j'aurais mettre les données de mon éditeur dans mode lecture seule et tout arrêter réplications jusqu'à l'opération est terminé.
2. faire un instantané des données, envoyer les fichiers d'instantanés à l'étranger, installez-les sur l'abonné, et indiquer le nouvel emplacement de l'instantané comme un endroit alternatif dans le propriétés de réplication. Celui-là Cela me semble juste (pas besoin de suspendre les réplications en cours, pas de gel des données), mais Point, Microsoft aide pas ... aide.

Je suis sûr que certains d’entre vous ont déjà vécu une telle situation. Quel a été votre choix?

EDIT: bien sûr, on pourrait dire "Pourquoi ne pas simplement essayer vos idées", mais cela prendra des heures (plusieurs instances de SQL Server, de machines virtuelles, etc.) ... ), 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 accepte de perdre 2 minutes de son temps pour m'épargner des heures de travail acharné ...

Answer 1

Je devais faire quelque chose de semblable à celui-ci lors de la réplication de données de Los Angeles, CA en Chine. Le chargement aurait pris 44 jours à l'aide de 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é le fichier et transféré par FTP les fichiers de la Californie à la Chine. Quand ils sont arrivés en Chine, je les ai décompressés et placés dans le même dossier que celui utilisé en Californie.

J'ai ensuite exécuté le fichier 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 environ au lieu de plus d'un mois.

Si vos données mettent plus de deux jours à atteindre leur destination, vous devrez modifier la publication et augmenter la quantité de données pouvant être mises en file d'attente, sinon l'abonné sera expiré et un nouvel instantané doivent être pris.

Answer 2

Nous venons de vivre quelque chose comme ça, et ce n’est pas beau. Même si tous les serveurs impliqués étaient locaux, cela a quand même pris beaucoup de temps.

Pour rendre les choses plus difficiles, du moins avec SQL 2000, l'instantané échouera si la cabine compressée dépasse 4 Go.

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