Uso de SQL Server Change Data Capture con un esquema que cambia con frecuencia

Estamos buscando habilitar Sql Server Change Data Capture para un nuevo subsistema que estamos construyendo.

No es realmente porque lo necesitemos, sino que estamos siendo presionados por tener una trazabilidad completa del historial, y los CDC resolverían muy bien este requisito con el mínimo esfuerzo de nuestras partes.

Estamos siguiendo un proceso de desarrollo ágil, que en este caso significa que frecuentemente hacemos cambios en el esquema de la base de datos, por ejemplo, agregando nuevas columnas, moviendo datos a otras columnas, etc.

Hicimos una pequeña prueba en la que creamos una tabla, habilitamos CDC para esa tabla y luego agregamos una nueva columna a la tabla. Los cambios en la nueva columna no están registrados en la tabla CDC.

¿Existe un mecanismo para actualizar la tabla CDC al nuevo esquema, y ​​existen algunas prácticas recomendadas sobre cómo manejar los datos capturados al migrar el esquema de la base de datos?

También hemos comenzado recientemente a buscar en los CDC. No soy un experto en el tema, pero creo que tengo algunas respuestas para sus preguntas.

En su mayor parte, los CDC lo ayudarán a lograr su objetivo de una historia completamente rastreable, pero no creo que lo lleve hasta allí.

Antes que nada:

con frecuencia hacemos cambios en el esquema de la base de datos ... ¿Existe un mecanismo para actualizar la tabla CDC al nuevo esquema?

Y aquí es donde creo que los CDC te fallarán. La documentación de MSDN en la sección "Descripción de los gastos generales de seguimiento de cambios" es bastante clara de que no hará un seguimiento de los cambios de esquema por usted. Por ejemplo, con Alter Table Add Column:

Si se agrega una nueva columna a la tabla de seguimiento de cambios, no se realiza un seguimiento de la adición de la columna. Solo se rastrean las actualizaciones y los cambios que se realizan en la nueva columna.

Drop Column Es un poco más complejo.

Sin embargo, debe usar scripts de base de datos para alterar su esquema, por lo que no necesariamente tiene que depender de los CDC aquí. Eso le permite tener consistencia entre sus esquemas de control de calidad y producción. Y el cambio al control de calidad debe realizarse mediante un script para que los mismos cambios exactos se puedan aplicar a Prod. No debería ser demasiado difícil extraer los cambios de esquema de esos scripts. Esto puede significar que la dimensión "tiempo" de su historial dependerá de la versión en lugar del tiempo real, pero el resultado final será el mismo.

Si aún no tiene una, cree una tabla para rastrear la versión del esquema de su base de datos. Y luego coloque esa tabla de versión del esquema de la base de datos en CDC para que pueda alinear los cambios macroscópicos al esquema con los cambios microscópicos dentro de una tabla en particular.

Según tengo entendido, aún debería ver los datos agregados a las nuevas columnas, independientemente de que CDC no muestre el cambio de esquema. Y los CDC también deberían recoger la migración de datos de una tabla a otra.

¿Existen algunas prácticas recomendadas para tratar los datos capturados al migrar el esquema de la base de datos?

Trátelo como trataría una auditoría. Debe comprender qué es lo que está examinando, por qué lo está examinando y cuánto tiempo debe mantener esa información. El alcance y la retención son los dos mayores problemas cuando se trata de una tarea como esta.

Las herramientas de informes de los CDC son comprensiblemente austeras, por lo que debe conocer el contexto de los cambios. Es muy fácil decir "¡rastrea todo !" y terminan con nada que sea utilizable como resultado. Del mismo modo, podría duplicar el tamaño de su base de datos manteniendo una copia de cada cambio. En una mesa de alta rotación con muchas inserciones y eliminaciones, terminará con un crecimiento astronómico. Eso no es malo en sí mismo, pero debe presupuestar ese crecimiento y tener un medio para examinar todos los datos que se generan.

Entonces, esto lo lleva a comprender por qué lo empujan a tener una trazabilidad completa. Ciertamente hay razones válidas para ese requisito. Pero no podrá estructurar su auditoría efectiva de la base de datos hasta que sepa por qué debe cumplir ese requisito.

Puede realizar un seguimiento de la adición de columnas con desencadenadores DDL.

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] |
EXTERNAL NAME < method specifier > [ ; ] }

Puede usar el grupo de eventos DDL_TABLE_EVENTS para activar CREATE, DROP o ALTER de una tabla.

Sin embargo, es posible que desee echar un vistazo a SQL Server Audit , si está utilizando Enterprise> 2008, ya que puede "combinar todas las capacidades de auditoría en una especificación de auditoría". Este enlace msdn tiene un artículo detallado al respecto: http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx .

CREATE SERVER AUDIT audit_name
TO { [ FILE (<file_options> [, ...n]) ] |
APPLICATION_LOG | SECURITY_LOG }
[ WITH ( <audit_options> [, ...n] ) ] }[ ; ]

<file_options>::=
{FILEPATH = 'os_file_path'
[, MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[, MAX_ROLLOVER_FILES = integer ]
[, RESERVE_DISK_SPACE = { ON | OFF } ] }

<audit_options>::=
{ [ QUEUE_DELAY = integer ]
[, ON_FAILURE = { CONTINUE | SHUTDOWN } ]
[, AUDIT_GUID = uniqueidentifier ]}

Luego crea las especificaciones del servidor o la base de datos.

Simple-Talk tiene un excelente artículo sobre la captura de datos de cambios y una guía muy completa sobre los CDC, así como la documentación de MSDN explica los diversos métodos según los requisitos. Pero ambos pueden ayudarlo con sus requisitos específicos.