Sincronización desconectada

Este tema se aplica a ArcGIS for Desktop Standard y ArcGIS for Desktop Advanced exclusivamente.

Para sincronizar réplicas en un entorno desconectado, debe intercambiar los mensajes de forma manual. Esto se logra exportando un mensaje desde una réplica hasta un archivo e importando el mensaje desde el archivo hasta la réplica relativa. En sistemas desconectados, los archivos se pueden transportar en soportes (como CD o DVD) y enviarse a través de un agente de distribución (como una empresa de mensajería privada, el servicio de correos, etc.).

En cualquier momento, una réplica puede ser un remitente de datos o un receptor de datos. Un remitente de datos exporta mensajes de cambio de datos a archivos delta que contienen cambios que se van a aplicar a la réplica relativa. Un receptor de datos exporta mensajes de confirmación a archivos de confirmación para confirmar lo que se ha recibido. Para saber si una réplica es emisora o receptora de datos, puede comprobar su estado en Manager de la Réplica, en ArcMap. Consulte Un recorrido rápido por la administración de réplicas para obtener información sobre el Administrador de la Réplica.

Es importante que el receptor de datos exporte mensajes de confirmación tan a menudo como sea posible. Si no se recibe ningún mensaje de confirmación, el emisor de datos reenvía los cambios de forma predeterminada y conserva la información necesaria para reenviar los cambios hasta que se reconozcan esos cambios. Como resultado, la geodatabase del emisor de datos puede alcanzar un gran tamaño, al igual que los mensajes de cambio de datos posteriores.

Una práctica ideal, aunque no obligatoria, consiste en que el receptor de datos envíe un mensaje de confirmación después de recibir cada mensaje de cambio de datos. También es importante tener en cuenta que un mensaje de confirmación confirma todos los mensajes de cambio de datos. Por ejemplo, si una réplica recibe tres mensajes de cambio de datos e importa cada uno de ellos, puede enviar un único mensaje de confirmación que confirme los tres.

A continuación se muestra la réplica primaria enviando cambios a la réplica secundaria y recibiendo un mensaje de confirmación del elemento secundario. Aquí, el elemento primario es el remitente de datos y el elemento secundario es el receptor de datos.

En las réplicas dobles, el emisor y el receptor de datos también pueden intercambiar sus roles. El intercambio lo inicia el remitente de los datos cuando envía un último mensaje de cambio de datos que incluye instrucciones para intercambiar las funciones. Una vez que el receptor de los datos ha importado el mensaje, las funciones se intercambian y el sistema está listo para enviar los datos en la dirección opuesta.

El siguiente diagrama muestra la réplica principal enviando un mensaje de cambio de datos con instrucciones para intercambiar los roles. Cuando la réplica primaria exporta el mensaje, se convierte en el receptor de los datos. Cuando el elemento secundario recibe el mensaje, se convierte en el remitente de los datos. A continuación, la réplica secundaria envía un mensaje de cambio de datos al elemento primario.

Como se ha indicado anteriormente, las réplicas dobles usan los mensajes de cambio de datos y de confirmación y pueden intercambiar sus roles. Con las réplicas unidireccionales, sin embargo, no se pueden intercambiar los roles. En el caso de las réplicas unidireccionales de principal a secundaria, la principal es siempre el emisor de datos. En el caso de las réplicas unidireccionales de secundaria a principal, la secundaria es siempre el emisor de datos. En ambos casos, es importante que el receptor de datos envíe mensajes de confirmación. Para las réplicas checkout, el elemento secundario es siempre el remitente de los datos y no se necesita ningún mensaje de confirmación. Para obtener más información sobre los tipos de réplica, consulte Tipos de replicación.

Hasta ahora, se ha descrito un modelo básico de intercambio de mensajes en el que se intercambian mensajes entre la réplica principal y la réplica secundaria. Si continúa con este modelo, el sistema funcionará correctamente e incluso se corregirá a sí mismo si se pierden mensajes. No obstante, quizá desee considerar también los siguientes escenarios específicos de intercambio de mensajes.

Reenviar los mensajes no confirmados

El sistema permite que las réplicas reenvíen cambios de datos sin confirmación. Quizá desee hacerlo cuando, como remitente de datos, sepa o sospeche que un mensaje de cambio de datos anterior se ha perdido y debe enviarse de nuevo. Otra opción es esperar hasta la próxima vez que se envíen cambios de datos dado que, de forma predeterminada, incluirán los nuevos cambios y los cambios sin confirmación.

En el siguiente diagrama se muestra un caso en el que se deben reenviar cambios de datos sin confirmación. Aquí, el elemento primario envía un mensaje de cambio de datos y cambia del remitente al receptor. El mensaje, sin embargo, se pierde y deja a la réplica principal y a la secundaria como receptores de datos. Para resolver este problema, el receptor de datos que acaba de cambiar de función dispone de la opción de reexportación de mensajes sin confirmación. En este caso, permite que el elemento primario reenvíe el mensaje de intercambio de funciones al elemento secundario.

Confirmar cambios después de intercambiar las funciones

Después de intercambiar los roles en una réplica bidireccional, el emisor de los datos tiene la opción de exportar un mensaje de confirmación para confirmar el mensaje de intercambio de roles. Otra opción es enviar un mensaje de cambio de datos, dado que confirmará implícitamente este mensaje. No obstante, si no pretende enviar un mensaje de cambio de datos en un futuro cercano, es recomendable que envíe un mensaje de confirmación.

En el siguiente diagrama, la réplica principal envía un mensaje de cambio de datos que intercambia los roles. Cuando el elemento secundario recibe el mensaje, se convierte en remitente de datos pero, dado que acaba de cambiar, el sistema aún le permite enviar un mensaje de confirmación.

Intercambiar funciones sin enviar cambios de datos

Es posible enviar un mensaje de cambio de datos con instrucciones para intercambiar las funciones pero sin ningún cambio de datos. Quizá desee hacerlo si, como remitente de los datos, necesita recibir cambios del receptor de los datos pero no está listo para enviar cambios de datos. Consulte Exportar un mensaje de cambio de datos para obtener más información sobre cómo enviar un mensaje para intercambiar roles sin enviar ningún dato.

Omitir el archivo del mensaje de confirmación

Al enviar cambios de datos, de forma predeterminada se envían todos los nuevos cambios de datos y los cambios de datos sin confirmación. Los nuevos cambios son las inserciones, actualizaciones y eliminaciones aplicadas a la versión de réplica desde que se exportó el último mensaje de cambio de datos. Los cambios de datos sin confirmación incluyen cambios exportados previamente para los que no se ha recibido confirmación. Si ha enviado varios mensajes de cambio de datos sobre los que no ha recibido confirmación, los archivos de cambio de datos pueden alcanzar un gran tamaño.

La mejor solución consiste en que el receptor de datos envíe un archivo de mensaje de confirmación. Sin embargo, según el sistema de comunicaciones, puede que esto no sea siempre posible. Por ejemplo, si las réplicas están desconectadas y para enviar un archivo de confirmación se necesitan soportes de envío para intercambiar archivos, tal vez sea preferible enviar un mensaje de correo electrónico a la persona encargada de la réplica emisora de datos para indicarle que ha recibido e importado los cambios de datos.

Tenga en cuenta, sin embargo, que omitir el archivo de mensaje de confirmación complica la administración de la sincronización.

• Importar mensajes de confirmación es la única manera de que el sistema suprima las versiones del sistema necesarias para reenviar cambios a una réplica. La falta de coherencia entre las versiones del sistema puede impedir la compresión con el tiempo, hacer que aumente el tamaño de la geodatabase del emisor y ralentizar el rendimiento de la geodatabase. Por esta razón, sigue siendo importante usar los mensajes de confirmación aunque sea de forma periódica.
• Si se omite el archivo de mensaje de confirmación, se necesita una mayor intervención manual por parte tanto de la persona encarga de la réplica emisora de datos como de la persona encargada de la réplica receptora de datos.

  Puede utilizar el administrador de réplicas para determinar qué cambios ha enviado y ha recibido una réplica. Para evitar enviar un mensaje de cambio de datos innecesariamente grande, el emisor de datos debe desmarcar la opción Incluir cambios de datos desconocidos la próxima vez que envíe cambios de datos.

• Cuando se omite el uso del archivo de mensaje de confirmación, el flujo de trabajo de sincronización es más propenso a sufrir errores.

  El receptor de datos solo puede importar los nuevos cambios si los anteriores se han importado. Si el sistema detecta que no se han importado otros cambios enviados previamente, aparecerá un mensaje de error y el conjunto de cambios actual no podrá importarse. Si se envían varios mensajes de cambio de datos a la vez, deben importarse en el orden correcto. El sistema mostrará un mensaje de error si trata de importar en un orden incorrecto.

  Cuando se producen errores, se ofrecen mensajes de error. Sin embargo, si utiliza un sistema automatizado, no podrá estar presente para ver los errores. En este caso, puede utilizar el registro de actividad de la réplica para detectar si se han producido errores durante la sincronización. El registro también proporciona instrucciones sobre cómo efectuar la recuperación cuando sea necesario.