Disponible con una licencia Standard o Advanced.
La replicación de geodatabases se genera encima del control de versiones. Durante la creación de réplicas, las versiones de las geodatabase de origen y objetivo se establecen como versiones de réplica. Los cambios en estas versiones de réplica se intercambian durante la sincronización. Puesto que las versiones de réplica están vinculadas, puede pensar en ellas como una manera de extender la jerarquía de versiones para que abarque varias geodatabases.
La versión predeterminada, o cualquier versión con nombre, se puede utilizar como versión de réplica para la réplica primaria o secundaria. Varias réplicas pueden compartir también la misma versión de réplica. Vea Crear una réplica para ver cómo establecer la versión de réplica en el elemento primario o el secundario.
El siguiente diagrama muestra las versiones de réplica para réplicas unidireccionales y bidireccionales. Para la replicación bidireccional, la réplica primaria utiliza la versión denominada RV1 como versión de réplica. La réplica primaria de los ejemplos de replicación unidireccional utiliza la versión denominada RV2 como versión de réplica para ambos ejemplos.
Para ambas réplicas secundarias alojadas en geodatabases de ArcSDE, la versión predeterminada es la versión de réplica. Aparte del hecho de que se utilizan para la replicación, las versiones de réplica no son diferentes de otras versiones tales como las versiones V1 y V2 que se muestran a continuación.
Dado que los tipos de geodatabase de archivos y personales no admiten el control de versiones, no se crea ninguna versión de réplica para el elemento secundario de la segunda replicación unidireccional, que se muestra a la derecha.
La replicación checkout es capaz de replicar tanto datos versionados como datos no versionados. Para las réplicas checkout que implican datos versionados, se crea una nueva versión con nombre para que sirva como versión de réplica en el elemento secundario.
La replicación checkout/check-in también permite que las geodatabases personales o de archivos alojen réplicas secundarias. Puesto que estos tipos de geodatabase no admiten el control de versiones, no se crea ninguna versión de réplica para el elemento secundario. Éste es también el caso cuando se desprotegen datos no versionados. Para estos escenarios, se utiliza lógica adicional para determinar los cambios que se envían durante la sincronización.
El siguiente diagrama muestra dos ejemplos de réplicas checkout y sus versiones de réplica. Una réplica primaria utiliza la versión RV1 como la versión de réplica, que la otra utiliza la versión RV2 como la versión de réplica. Una réplica secundaria está alojada en una geodatabase de archivos (también podría ser una geodatabase personal), y la otra en una geodatabase de ArcSDE. Para la geodatabase de ArcSDE que aloja la réplica secundaria, RV2 se creó y se estableció automáticamente como la versión de réplica durante la creación. El nombre RV2 para esta versión de réplica se tomó del nombre de la versión de réplica del elemento primario utilizado para crearla.
Para las réplicas checkout, durante la creación se agrega una versión de sincronización a la geodatabase de la réplica primaria. La versión de sincronización es un elemento secundario de la versión de réplica pero no se muestra arriba, puesto que solo se utiliza durante la sincronización. Vea Sincronización y control de versiones para obtener más información.
Utilizar el archivado para realizar el seguimiento de los cambios de la réplica
En el caso de la replicación unidireccional, puede decidir utilizar el archivado en lugar del control de versiones para realizar el seguimiento de los cambios de la réplica. Si se desea utilizar esta opción, la versión de réplica de origen debe ser la versión DEFAULT.
La ventaja de administrar la replicación de esta manera es que mantiene los procesos de conciliación y compresión separados del proceso de sincronización. Cuando se utiliza el control de versiones para realizar el seguimiento de los cambios, se crean versiones del sistema. Debido a estas versiones del sistema, es necesario sincronizar periódicamente para lograr una compresión efectiva.
Cuando se utiliza el archivado para realizar el seguimiento de los cambios de la réplica, no se crea ninguna versión del sistema. Por consiguiente, los procesos de conciliación y compresión no se ven afectados, haciendo independientes la administración de versiones y la administración de la replicación. Esto también permite que el programa de sincronización sea más flexible.
Dado que el archivado exige que los datos estén versionados, la réplica de origen debe estar en una geodatabase de ArcSDE. La versión de réplica de origen también debe ser la versión DEFAULT.
En el diagrama siguiente, se muestra una replicación unidireccional de elemento primario a elemento secundario entre geodatabases de ArcSDE donde se utiliza la versión DEFAULT como versión de réplica tanto para el elemento primario como para el elemento secundario. Dado que las geodatabases de archivos y personales no admiten el control de versiones, no se crea ninguna versión de réplica en el elemento secundario de la otra réplica unidireccional, que se muestra en el diagrama.
La replicación unidireccional de elemento secundario a elemento primario también se puede utilizar cuando ambas geodatabases son geodatabases de ArcSDE. La versión de la réplica secundaria debe ser DEFAULT en este caso.
