sql server 2008 r2 - for - Evitar bucles de actualización para múltiples bases de datos usando CDC
bucle for en sql server 2008 ejemplos (1)
Tenemos varios sistemas heredados en los que no podemos realizar cambios; sin embargo, queremos comenzar a tomar cambios de datos de estos sistemas y aplicarlos automáticamente a otros sistemas.
Estamos pensando en alguna forma de bus de servicio (sin tecnología específica escogida) sentado en el medio, y un conjunto de adaptadores de bus (uno por aplicación heredada) para traducir entre conceptos específicos de la base de datos y mensajes de actualización generales.
Un área que he estado viendo es usar Change Data Capture (CDC) para monitorear la actividad de actualización en las bases de datos heredadas, y usar esa información para construir mensajes apropiados. Sin embargo, me preocupa: cómo podría, como consumidor de información CDC, distinguir los cambios aplicados por la aplicación frente a los cambios aplicados por el adaptador de bus al recibir los mensajes, porque de lo contrario, la primera actualización que se distribuya por el bus ser redistribuido por cada receptor cuando aplican ese cambio a su propio sistema.
Si estaba implementando CDC "pobres" CDC, es decir, desencadenantes, entonces esos desencadenantes se ejecutan dentro del contexto / transacción / conexión de las declaraciones DML originales, por lo que podría diseñarlos para ignorar a un usuario en particular (el usuario aplica las actualizaciones del bus ), o establecer y detectar una propiedad de sesión para ignorar ciertas actualizaciones similares.
¿Algunas ideas?
Si entiendo su pregunta correctamente, está tratando de definir una estructura de enrutamiento de mensajes que funcione con un diseño que ya ha seleccionado (utilizando un bus de servicio empresarial ) y una implementación de mensajes que puede usar para transferir datos de sus sistemas heredados que solo los puertos de reenvío cambian a sus sistemas más nuevos.
La dificultad es que está tratando de aplicar cambios de tal manera que ellos mismos no generen un mensaje CDC de los clientes que reciben el paquete de datos de sus sistemas heredados. De hecho, todo lo que le preocupa es que sus sistemas más nuevos consuman los datos y no propaguen los mensajes a su bus, creando diafonía innecesaria que pueda potenciar, sobrecargando su infraestructura.
El secreto es cómo las funciones CDC de MSSQL concilian los cambios a medida que se propagan a través de la red. Específicamente, tenga en cuenta esta advertencia:
Todos los cambios se registran en términos de LSN o Número de secuencia de registro. SQL identifica claramente cada operación de DML a través de un Número de secuencia de registro. Cualquier modificación comprometida en cualquier tabla se registra en el registro de transacciones de la base de datos con un LSN específico proporcionado por SQL Server. Los valores de __ $ operationcolumn son: 1 = eliminar, 2 = insertar, 3 = actualizar (valores antes de la actualización), 4 = actualizar (valores después de la actualización).
cdc.fn_cdc_get_net_changes_dbo_Employee nos proporciona todos los registros netos que caen entre el LSN que proporcionamos en la función. Tenemos tres registros devueltos por la función net_change; hubo una eliminación, un inserto y dos actualizaciones, pero en el mismo registro. En el caso del registro actualizado, simplemente muestra el valor neto cambiado después de que se completen ambas actualizaciones.
Para obtener todos los cambios, ejecute cdc.fn_cdc_get_all_changes_dbo_Employee; hay opciones para pasar ''ALL'' o ''ALL UPDATE OLD''. La opción "TODOS" proporciona todos los cambios, pero para las actualizaciones, proporciona los valores actualizados. Por lo tanto, encontramos dos registros de actualizaciones. Tenemos un registro que muestra la primera actualización cuando Jason se actualizó a Nichole, y un registro cuando Nichole se actualizó a EMMA.
Si bien esta documentación es algo escueta y difícil de entender, parece que los cambios se registran y concilian en orden LSN. El sistema debe descartar los cambios en competencia, lo que permite que su modelo de coherencia funcione de manera efectiva.
Tenga en cuenta también:
CDC está deshabilitado de forma predeterminada y debe estar habilitado en el nivel de la base de datos seguido de habilitar en la tabla.
La opción B se vuelve obvia: instituya CDC en sus sistemas heredados, luego use su bus de servicio para traducir estos cambios en actualizaciones que no estén vinculadas a CDC (usando, por ejemplo, declaraciones de actualizaciones de transacciones sin procesar). Esto debería permitir el flujo de datos de un solo sentido que busca desde el diseño de su sistema.
Para métodos adicionales de reconciliación de cambios, considere los conceptos planteados por este artículo de Wikipedia sobre "consistencia eventual" . La mejor de las suertes con su sistema de mensajes de la base de datos interna.