¿Cuándo usar CDC para rastrear el historial?

26

SQL Server Change Data Capture es una característica que lee datos históricos de los registros de transacciones de SQL Server y los almacena en una tabla especial.

Mediante el uso de funciones especiales de valores de tabla (TVF), permite al usuario consultar estos datos, lo que permite obtener todos los cambios en una tabla específica o solo los cambios netos que resultaron de los cambios dentro de un tiempo específico.

CDC tiene ciertas ventajas

Se puede configurar para rastrear solo ciertas tablas o columnas.
Es capaz de manejar cambios de modelo hasta cierto punto.
No afecta el rendimiento tanto como los desencadenantes porque funciona con los registros de transacciones.
Se habilita / deshabilita fácilmente y no requiere columnas adicionales en la tabla que se deban rastrear.

También tiene algunas desventajas:

La cantidad de datos del historial puede llegar a ser enorme rápidamente.
No puede rastrear quién realizó los cambios (al menos no para las eliminaciones).
Los datos del historial tardan un poco en ponerse al día, ya que se basan en los registros de transacciones.
Depende del Agente SQL Server. Si el Agente no se está ejecutando o se bloquea, no se realiza un seguimiento del historial.

He leído bastante sobre CDC y aunque ahora sé cómo usarlo, todavía no estoy seguro de si es la herramienta adecuada para mí.

¿Para qué tareas / escenarios es CDC la herramienta adecuada? (p. ej. ¿Permitir a los usuarios restaurar un objeto de datos en un momento determinado? ¿Auditoría? ¿Mostrar el historial completo de datos?)
¿Cuándo debería preferir no usar CDC, sino recurrir a una solución personalizada basada en disparadores?
¿Está bien usar CDC en una base de datos operativa y hacer uso de los datos de CDC dentro de una aplicación operativa? (por ejemplo, mostrándolo al usuario final) ¿ O es claramente un mal uso de esta función?

Comúnmente escucho que CDC es una herramienta de auditoría, pero ¿no es eso para lo que sirve SQL Server Audit ? ¿Son ambas herramientas diferentes para la misma tarea? ¿O pueden los CDC usarse para otras cosas?

Mi escenario actual es que me piden que construya un marco de datos confiable que se supone que es la base para múltiples aplicaciones futuras. Los requisitos exactos son borrosos, pero uno es que debería poder rastrear el historial de datos y restaurar las entradas más antiguas junto con todos los datos relacionados de otras tablas. Estoy evaluando los CDC en este momento como una opción, pero no estoy seguro si este es el camino a seguir, porque realmente no puedo encontrar ningún caso de uso recomendado.

Si bien agradezco los consejos para mi escenario específico, las respuestas deberían dar consejos generales sobre cuándo o cuándo no usar Change Data Capture.

sql-server change-data-capture data-versioning

— magnético
fuente

1

Idealmente, un "marco" no tomaría este tipo de decisión; se dejaría a proyectos individuales. Pero dado que se le pide que haga esto, al menos le diría a quien le dé estos requisitos: hay diferentes formas de lograr esto, y la mejor opción depende en gran medida del uso y las necesidades exactas. Pregúnteles si pueden darle alguna aclaración que pueda ayudarlo a decidir (como si el rendimiento o la flexibilidad son más importantes). Otra opción a considerar es desarrollar ambas opciones como parte del "marco" y dejar que los proyectos reales elijan cuál habilitar.

— jpmc26

@ jpmc26, el marco puede ser necesario para detener el tiempo de cada proyecto para decidir este tipo de preguntas

— Ian Ringrose

@IanRingrose Mi punto es que tratar de tomar esa decisión sin considerar las necesidades específicas de un proyecto, a la larga, causará más problemas de los que resuelve (y por lo tanto, será más costoso que gastar ese tiempo). Esta es una decisión que no se puede tomar efectivamente en un caso general. Se deben considerar los detalles del proyecto . Usando una decisión general, se dedicará tiempo a usar la solución elegida y hacer suposiciones a su alrededor solo para que esas suposiciones sean violadas cuando se descubra que no era una solución adecuada. Entonces el sistema deberá ser rediseñado.

— jpmc26

1

@ jpmc26 De hecho, podría ir con la solución que propusiste, en caso de que encuentre una manera de lograrlo: Desarrollando un seguimiento de historial basado en disparador y CDC, conmutable y detrás de una interfaz común. Las aplicaciones pueden elegir una u otra, según sus requisitos, pero no tienen que preocuparse por implementarlas ellos mismos. Por supuesto, todavía me gustaría obtener una buena respuesta a mi pregunta anterior, porque de todos modos si los CDC no están preparados para este tipo de tarea (por ejemplo, porque solo es bueno para la auditoría), podría ahorrarme el problema y usar siempre desencadenantes .

— magnético

"Si el Agente no se está ejecutando o falla, no se está rastreando el historial", pero si se reiniciara, no se perderían los cambios, ¿verdad?

— Andy Joiner

12

En primer lugar,

La captura de datos modificados solo está disponible en las ediciones Enterprise, Developer y Evaluation de SQL Server.

Así que eso puede decidir por usted si alguno de sus clientes no tendrá las ediciones empresariales, o si aún no sabe que usará las ediciones empresariales. (Como la especificación incluye "múltiples aplicaciones futuras", esto puede ser un problema real para usted)

A diferencia de los disparadores, no es en tiempo real, esto es tanto una ventaja como una desventaja. El uso de disparadores siempre ralentiza una actualización.

Trabajé en un sistema cuando usamos activadores (generados por CodeSmith), además de rastrear todos los cambios en los registros, también vinculamos los cambios a una tabla de "historial" que incluía el módulo de la aplicación que realizó el cambio, y el elemento de la IU que el usuario utilizó para realizar el cambio.

Sin embargo, es mejor que resuelva esto a nivel de aplicación, por ejemplo, escribiendo todas las actualizaciones en una cola de mensajes que luego se reproduce para crear una base de datos en cualquier momento dado, consulte Patrones temporales en el blog Martin Flowler para obtener una buena descripción de las opciones.

— Ian Ringrose
fuente

El enlace es una lectura muy interesante, gracias por eso. Aún así, resolver esto a nivel de aplicación no es una opción en mi caso. Se supone que el marco que estoy construyendo hace la mayor parte del trabajo, incluido el seguimiento del historial, para las aplicaciones basadas en él. Luego, las aplicaciones trabajan con una interfaz común para almacenar / recuperar datos, de modo que no tengan que preocuparse por cómo se almacenan los datos. Soy consciente de que esta tarea está lejos de ser trivial.

— magnético

Además, actualmente no estoy considerando Enterprise Edition o no ser un factor decisivo en nuestro caso. Las futuras aplicaciones de las que estoy hablando probablemente serán construidas y alojadas por nosotros.

— magnético

@atticae, su marco no tiene que estar limitado a la base de datos, puede incluir código que se ejecuta fuera de la base de datos.

— Ian Ringrose

No se limita a la base de datos, por supuesto. (No lo llamaría un marco en este caso). Veo lo que quiere decir ahora con "nivel de aplicación" y actualmente estoy usando una variación del patrón de Propiedad Temporal del que habla su enlace. El marco que construyo proporciona esta interfaz a las aplicaciones que lo usan. Aún así, eso es parte del lado de la interfaz, y nada de esto realmente responde a mis preguntas descritas anteriormente.

— magnético

Gracias de nuevo por su respuesta. Este es probablemente el factor decisivo para la mayoría de las personas, por lo que creo que es una buena respuesta y probablemente ayude a los futuros visitantes a decidir no usar los CDC. Sin embargo, siento que en realidad no responde a la mayoría de mis preguntas, por lo que tendré que dar la recompensa a Stacylaray, que fue el único que intentó responder a todas las preguntas que tenía. (Aunque esperaba una respuesta un poco más elaborada.)

— magnético

12

Aquí hay una serie de 9 partes muy bien escrita que revisa las diferentes formas de auditar los cambios de datos de SQL Server. Las partes 3, 4 y 5 se centran en los CDC. Vale la pena leer todos los artículos porque esto responderá a sus preguntas, como los diferentes escenarios donde las características serían apropiadas y generales. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

— Brynn
fuente

1

Después de leer el artículo, todavía no soy mucho más inteligente. Como en la mayoría de los artículos, se detalla cómo usar CDC y cómo se compara con Change Tracking. Sin embargo, eso realmente no responde a mis preguntas anteriores.

— magnético

9

¿Para qué tareas / escenarios es CDC la herramienta adecuada? (por ejemplo, ¿Permitir a los usuarios restaurar un objeto de datos en un determinado momento?

Tal vez, depende.

¿Revisión de cuentas?

Sí.

¿Mostrando el historial completo de datos?)

Sí.

¿Cuándo debería preferir no usar CDC, sino recurrir a una solución personalizada basada en disparadores?

Cuando los datos en la tabla de cambios no satisfacen sus necesidades.

¿Está bien usar CDC en una base de datos operativa y hacer uso de los datos de CDC dentro de una aplicación operativa? (por ejemplo, mostrándolo al usuario final)

Sí.

¿O es claramente un mal uso de esta función?

No, no es un mal uso de esta función.

Comúnmente escucho que CDC es una herramienta de auditoría, pero ¿no es para eso que sirve SQL Server Audit?

Sí.

¿Son ambas herramientas diferentes para la misma tarea?

No.

¿O pueden los CDC usarse para otras cosas?

Los CDC pueden usarse para otras cosas.

Hay seguimiento de cambios y hay captura de datos de cambio. Ambos tienen sus raíces en la replicación.

El seguimiento de cambios proporciona una manera de proporcionar los cambios netos a una tabla. Un ejemplo de uso sería una sincronización de dispositivo portátil.

Los CDC, por otro lado, realizan un seguimiento de cada pequeño cambio, una historia. Uno puede usar ese historial para actualizar un almacén de datos en lugar de una copia masiva de datos, o uno puede usar ese historial como datos en sí y generar informes a partir de él. La tabla de cambios no está oculta ni tiene un esquema extraño o algo así. Puede consultarlo y usar los datos como quiera. Solo ten en cuenta ... que no es en tiempo real, como dijo Ian. Los datos provienen del registro de transacciones, así que cuídelo como lo haría con la replicación, la duplicación o el envío de registros. En general, será más rápido que los disparadores. Deberá usar el aislamiento de instantáneas, que tiene gastos generales, y tendrá que pensar en la recuperación de desastres.

— Stacylaray
fuente

2

Un punto de corrección. En un momento, la captura de datos modificados solo estaba disponible en las versiones mencionadas anteriormente. Sin embargo, la captura de datos de cambio estuvo disponible en la edición estándar a partir de 2016 SP1. Por lo tanto, muchos artículos escritos antes de 2016 SP1 hacen que parezca que los CDC están fuera del alcance de aquellos de nosotros que usamos la edición Standard. Este ya no es el caso. El documento de Microsoft que describe los CDC disponibles se encuentra en el siguiente enlace.

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

— Robert Sievers
fuente