Realizar copias de seguridad y restaurar una base de datos

Como haría con cualquier base de datos de producción, debe crear copias de seguridad regulares de una base de datos involucrada en una sincronización. A la hora de restaurar una base de datos desde una copia de seguridad, deben tenerse en cuenta dos consideraciones principales:

• Puede que los cambios efectuados en la base de datos después de la restauración no se hayan propagado a los clientes o a otros elementos del mismo nivel. Esto se debe a los valores timestamp que se usan al seleccionar los cambios de una base de datos.

  Por ejemplo, durante la sincronización del cliente y el servidor, Sync Framework recupera de la base de datos servidor un valor de delimitador nuevo y lo almacena en la base de datos cliente. Este valor se utiliza como límite superior para el conjunto de cambios actual que se va a sincronizar. Para obtener más información, vea Seguimiento de cambios en la base de datos servidor. Después de restaurar la base de datos servidor, el valor almacenado en la base de datos cliente podría estar adelantado lógicamente con respecto al valor que devuelve la base de datos servidor.

• En escenarios de carga y bidireccionales, los clientes u otros elementos del mismo nivel podrían tener cambios que la base de datos recién restaurada no tenga.

En los ejemplos de este tema se usa la sincronización de cliente y servidor como ejemplo. Se aplican principios similares a la sincronización punto a punto y se describen consideraciones de escenarios punto a punto. La base de datos servidor es el punto remoto. La base de datos cliente es el punto local. Para obtener información sobre cómo se realizan copias de seguridad y se restauran las bases de datos de SQL Server que se sincronizan utilizando SqlSyncProvider, vea Realizar copias de seguridad y restauración de una base de datos (SQL Server).

Base de datos servidor

Para comprender el modo en que la base de datos cliente puede ir por delante lógicamente de la base de datos servidor, tenga en cuenta cómo se realiza el seguimiento de las actualizaciones en la tabla Sales.Customer de la base de datos de ejemplo Sync Framework. En la columna UpdateTimestamp se almacena un valor timestamp y el comando del nuevo delimitador devuelve un valor de la función MIN_ACTIVE_ROWVERSION de SQL Server. Por motivos de claridad, en el ejemplo se usan enteros en lugar de valores hexadecimales:

1. Antes de restaurar la base de datos, MIN_ACTIVE_ROWVERSION devuelve un valor de 31. Este valor se almacenó en la base de datos cliente como último delimitador recibido.

2. Después de restaurar la base de datos, MIN_ACTIVE_ROWVERSION devuelve el valor 19.

3. Se realizan actualizaciones de modo que el valor timestamp de la columna UpdateTimestamp llega a 32.

4. Se produce la sincronización y MIN_ACTIVE_ROWVERSION devuelve el valor 32. Se descarga la última actualización de Sales.Customer porque 32 es mayor que el valor del último delimitador recibido, 31. Las actualizaciones entre 19 y 31 no se reconocen como cambios.

Cualquier esquema de seguimiento que use un reloj lógico como marca de tiempo puede tener este problema de cambios no reconocidos. Los esquemas de seguimiento que usen un tipo de datos basado en la fecha y la hora no son propensos a este problema, puesto que el reloj avanza con independencia del estado de la base de datos. En la sincronización punto a punto, para el seguimiento de cambios se requiere una marca de tiempo.

Para resolver el problema que presenta la marca de tiempo, puede seguir uno de los métodos siguientes:

• Ponga la marca de tiempo del servidor en el punto donde estaba antes de la operación de restauración. En el ejemplo anterior, podría realizar actualizaciones ficticias en una tabla distinta hasta que MIN_ACTIVE_ROWVERSION devuelva 31.

  Éste es el enfoque recomendado para la sincronización punto a punto.

• Almacene el delimitador de cada cliente en el servidor. En el ejemplo anterior, el último delimitador recibido de la copia de seguridad sería 19. Por lo tanto, las actualizaciones posteriores se reconocerían y todos los cambios comprendidos entre 19 y 32 se descargarían. Sync Framework no proporciona compatibilidad integrada con esta funcionalidad, pero puede crear un sistema en el servidor de la siguiente manera:

  1. Cree una tabla en la base de datos servidor con una fila para cada cliente. La tabla incluiría una columna con el identificador generado por Sync Framework para cada cliente y una columna con el delimitador del cliente. Durante la sincronización, la aplicación actualizaría esta columna con un nuevo valor de delimitador.

  2. Cambie los comandos de sincronización para que seleccionen el valor de delimitador más bajo para el cliente que se está sincronizando. Este valor podría ser el valor almacenado en la base de datos cliente o el almacenado en la base de datos servidor. Después de una operación de restauración de base de datos, el valor menor debe ser el de la base de datos servidor. Si se produce un error después de escribir un valor en la tabla del servidor, pero antes de que se apliquen los cambios al cliente, el valor de la base de datos cliente será inferior. Si la sincronización procede como se esperaba, los valores deben ser iguales. Un comando de inserción se podría escribir como sigue:

     SELECT CustomerId, CustomerName, SalesPerson, CustomerType
     FROM Sales.Customer
     WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id)
     OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor
     AND InsertId <> @sync_client_id
     

Bases de datos cliente

Después de restaurar la base de datos servidor a la hora actual en lo que respecta a los metadatos de sincronización, seguirán faltando en la base de datos los cambios efectuados en los clientes desde la realización de la copia seguridad. Para que un cliente responda adecuadamente, éste debe saber que se restauró la base de datos servidor. Puede usar una tabla de seguimiento del lado del servidor que indique si se produjo una restauración desde la última vez que un cliente realizó una sincronización. Durante cada sesión de sincronización, la aplicación cliente primero debe comprobar esta tabla para determinar si puede realizar la sincronización con normalidad o si debe ejecutar código especial para trabajar con la base de datos restaurada.

Una vez que una aplicación cliente reconoce que se ha restaurado la base de datos servidor, la aplicación puede hacer que converjan las bases de datos cliente y servidor. Hay varias maneras de lograrlo, incluidas las siguientes:

• Reinicializar la base de datos cliente quitando todas las tablas y después realizando la sincronización con el servidor. Esta es la manera más fácil, pero se pierden todos los cambios realizados en el cliente.

  La reinicialización es el enfoque recomendado para la sincronización punto a punto. Para obtener información sobre la inicialización de bases de datos del mismo nivel, vea "Inicializar una base de datos servidor" en Configurar y ejecutar la sincronización de colaboración (no SQL Server).

• Reinicializar la base de datos cliente después de crear una copia de las tablas del cliente. Una aplicación podría seguir pasos como los siguientes:

  1. Identificar que se ha restaurado la base de datos servidor.

  2. Hacer una copia de todas las tablas de la base de datos cliente y después quitar las tablas originales.

  3. Sincronizar con el servidor para descargar nuevos esquemas y datos.

  4. Comparar las filas de las tablas nuevas con las copias realizadas.

  5. Identificar cualquier diferencia existente entre los dos conjuntos de tablas y aplicar a las tablas nuevas cualquier cambio que sea necesario.

  6. Sincronizar nuevamente para cargar los cambios que se aplicaron a las tablas nuevas.

Vea también

Conceptos

Consideraciones sobre el diseño y la implementación de aplicaciones