Disponible avec une licence Standard ou Advanced.
La réplication de géodatabase repose sur le versionnement. Lors de la création de réplica, les versions des géodatabases source et cible sont définies en tant que versions de réplica. Les modifications apportées à ces versions de réplica sont échangées au cours de la synchronisation. Les versions de réplica étant liées, vous pouvez les considérer comme un moyen d’étendre l’arborescence des versions pour couvrir plusieurs géodatabases.
La version par défaut ou toute version nommée peut être utilisée en tant que version du réplica parent ou du réplica enfant. Par ailleurs, une même version de réplica peut être partagée par plusieurs réplicas. Pour savoir comment définir la version de réplica sur le parent ou l'enfant, reportez-vous à la rubrique Création d'un réplica d’extraction.
Le diagramme ci-dessous représente les versions des réplicas monodirectionnels et bidirectionnels. Pour la réplication bidirectionnelle, le réplica parent utilise la version nommée RV1 en tant que version de réplica. Dans la réplication monodirectionnelle, le réplica parent utilise la version nommée RV2 en tant que version de réplica dans les deux exemples.
Pour les deux réplicas enfants hébergés dans des géodatabases d’entreprise, la version par défaut est la version de réplica. Outre leur utilisation pour la réplication, les versions de réplica ne diffèrent aucunement des autres versions, telles que les versions V1 et V2 illustrées ci-après. Les géodatabases de type fichier et personnelle ne prenant pas en charge le versionnement, aucune version de réplica n’est créée dans l'enfant de la deuxième réplication, illustrée à droite.
La réplication d’extraction/insertion est capable de répliquer des données versionnées ou des données non versionnées. Le réplica enfant peut être hébergé dans une géodatabase personnelle, fichier ou d’entreprise.
Lorsqu’un réplica enfant est hébergé sur une géodatabase d’entreprise, une version nommée est créée pour faciliter la mise à jour et faire office de version de réplica sur le réplica enfant. Le nom de la version de réplica enfant est configuré pour être identique au nom du réplica Pour mettre à jour les données du réplica enfant, connectez-vous à la géodatabase d’entreprise et utilisez la boîte de dialogue Change Versions (Changer de version) pour remplacer la version par celle du réplica enfant. Une fois que vous êtes connecté à la version de réplica enfant, vous pouvez commencer une session de mise à jour. Les mises à jour doivent être effectuées dans la version de réplica enfant pour synchroniser les mises à jour avec le réplica parent.
La réplication d’extraction/insertion permet également aux géodatabases personnelles ou fichier d’héberger des réplicas enfants. Ces types de géodatabase ne prenant pas en charge le versionnement, aucune version de réplica n’est créée pour l’enfant. C’est également le cas lors de l’extraction de données non versionnées. Dans ces scénarios, une logique supplémentaire est utilisée pour définir les modifications à envoyer au cours de la synchronisation.
Le diagramme ci-dessous illustre deux exemples de réplicas d’extraction avec leurs versions de réplica. Un réplica parent utilise la version RV1 en tant que version de réplica, tandis que l’autre utilise la version RV2 comme version de réplica. Un réplica enfant est hébergé par une géodatabase fichier (ou une géodatabase personnelle), tandis que l’autre est hébergé par une géodatabase d’entreprise. Pour la géodatabase d’entreprise hébergeant le réplica enfant, RV2 a été créée automatiquement et définie comme version de réplica au cours de la création. Le nom de cette version de réplica, RV2, provient du nom de la version de réplica dans le parent utilisé pour la créer.
Utilisation de l’archivage pour le suivi des modifications de réplica
Pour la réplication monodirectionnelle uniquement, vous pouvez utiliser l’archivage à la place du versionnement afin de suivre les modifications du réplica. Dans ce cas, la géodatabase parent doit être une géodatabase d’entreprise faisant référence à la version par défaut. Ce mode de gestion de la réplication offre l’avantage de séparer les processus de réconciliation, de réinjection et de compression du processus de synchronisation.
Lorsque vous utilisez le versionnement pour le suivi des modifications, des versions de système sont créées. Ces versions de système obligent à effectuer régulièrement des synchronisations pour que la compression soit efficace. Lorsque vous utilisez l’archivage pour le suivi des modifications de réplica, aucune version de système n’est créée. Par conséquent, les processus de réconciliation, de réinjection et de compression ne sont pas affectés ; les gestions de la version et de la réplication sont donc indépendantes. Cette situation permet également une meilleure flexibilité de la planification de synchronisation. Pour utiliser l’archivage pour le suivi des modifications de réplica, les données source doivent être inscrites comme versionnées dans la géodatabase d’entreprise et la version de réplica source doit être la version par défaut.
Le diagramme ci-dessous présente une réplication parent vers enfant monodirectionnelle à l’aide de l’archivage entre des géodatabases d’entreprise, où la version par défaut est utilisée comme version de réplica à la fois pour les réplicas parent et enfant dans la géodatabase d’entreprise. Les géodatabases de type fichier et personnelle ne prenant pas en charge le versionnement, aucune version de réplica n’est créée dans la géodatabase fichier ou personnelle enfant.
Vous pouvez également utiliser la réplication monodirectionnelle enfant vers parent lorsque les deux géodatabases sont des géodatabases d’entreprise. Dans ce cas, la version du réplica enfant doit être la version par défaut.
