Seguimiento de cambios y restauración de datos
Las aplicaciones que requieren sincronización deben considerar el caso en el que una base de datos que tiene el seguimiento de cambios habilitado revierta a una versión anterior de los datos. Esta situación se puede producir al restaurar una base de datos a partir de una copia de seguridad, cuando se produce una conmutación por causa de error a un espejo de la base de datos asincrónico, o cuando se produce un error al utilizar trasvase de registros. El siguiente escenario muestra el problema:
La tabla T1 está sometida a seguimiento de cambios y la versión válida mínima para la tabla es 50.
Una aplicación cliente sincroniza datos en la versión 100 y obtiene información sobre todos los cambios realizados entre las versiones 50 y 100.
Se realizan cambios adicionales en la tabla T1 después de la versión 100.
En la versión 120, se produce un error y el administrador de bases de datos restaura la base de datos con pérdida de datos. Tras la operación de restauración, la tabla contiene los datos hasta la versión 70 y la versión sincronizada mínima todavía es 50.
Esto significa que el almacén de datos sincronizado tiene datos que ya no existen en el almacén de datos primario.
T1 se actualiza un buen número de veces. Ello hace que la versión actual llegue a la 130.
La aplicación cliente sincroniza de nuevo y proporciona una última versión sincronizada de 100. El cliente da por bueno este número porque 100 es mayor que 50.
El cliente obtiene los cambios entre la versión 100 y 130. En este punto, el cliente no es consciente de que los cambios entre 70 y 100 no son los mismos que antes. Los datos en el cliente y en el servidor no están sincronizados.
Tenga en cuenta que si la base de datos se recuperara en un punto posterior a la versión 100, no habría ningún problema con la sincronización. El cliente y servidor sincronizarían correctamente los datos durante el intervalo de sincronización siguiente.
El seguimiento de cambios no permite recuperarse de una pérdida de datos. Sin embargo, hay dos opciones para detectar estos tipos de problemas de sincronización:
Almacene un Id. de versión de la base de datos en el servidor y actualice este valor cada vez que una base de datos se recupere o por el contrario pierda datos. Cada aplicación cliente almacenaría el Id. y cada cliente tendría que validar este Id. cuando sincronice datos. Si se produce una pérdida de datos, los Id. no coincidirán y los clientes se reinicializarían. Una desventaja es que si la pérdida de datos no hubiera cruzado el último límite sincronizado, el cliente podría hacer una reinicialización innecesaria.
Cuando un cliente consulte cambios, registre el último número de versión de sincronización para cada cliente en el servidor. Si hay un problema con los datos, los números de última versión sincronizada no coincidirán. Esto indica que se requiere una reinicialización.
Vea también