Utilisation de Sql Server Change Data Capture avec un schéma qui change fréquemment

Nous envisageons d'activer Sql Server Change Data Capture pour un nouveau sous-système que nous construisons.

Ce n'est pas vraiment parce que nous en avons besoin, mais nous sommes poussés à avoir une traçabilité complète de l'historique, et CDC résoudrait bien cette exigence avec un minimum d'effort sur nos pièces.

Nous suivons un processus de développement agile, ce qui signifie dans ce cas que nous apportons fréquemment des modifications au schéma de la base de données, par exemple en ajoutant de nouvelles colonnes, en déplaçant des données vers d'autres colonnes, etc.

Nous avons fait un petit test où nous avons créé une table, activé CDC pour cette table, puis ajouté une nouvelle colonne à la table. Les modifications apportées à la nouvelle colonne ne sont pas enregistrées dans la table CDC.

Existe-t-il un mécanisme pour mettre à jour la table CDC vers le nouveau schéma, et existe-t-il des meilleures pratiques sur la façon dont vous traitez les données capturées lors de la migration du schéma de base de données?

Nous avons également récemment commencé à étudier les CDC. Je ne suis pas un expert en la matière, mais je pense avoir des réponses à vos questions.

Pour la plupart, CDC vous aidera à atteindre votre objectif d'une histoire complètement traçable, mais je ne pense pas que cela vous y mènera jusqu'au bout.

Tout d'abord:

nous apportons fréquemment des modifications au schéma de la base de données ... Existe-t-il un mécanisme pour mettre à jour la table CDC vers le nouveau schéma

Et c'est là que je pense que CDC vous fera défaut. La documentation MSDN sous la section «Comprendre les frais généraux de suivi des modifications» est assez claire qu'elle ne suivra pas les modifications de schéma pour vous. Par exemple, avec Alter Table Add Column:

Si une nouvelle colonne est ajoutée à la table de suivi des modifications, l'ajout de la colonne n'est pas suivi. Seules les mises à jour et les modifications apportées à la nouvelle colonne sont suivies.

Drop Column est un peu plus complexe.

Cependant, vous devez utiliser des scripts DB pour modifier votre schéma afin que vous n'ayez pas nécessairement à compter sur CDC ici. Cela vous permet d'avoir une cohérence entre vos schémas d'assurance qualité et de production. Et le changement de QA doit être effectué par script afin que les mêmes changements exacts puissent être appliqués à Prod. Il ne devrait pas être trop difficile d'extraire les modifications de schéma de ces scripts. Cela peut signifier que la dimension "temps" de votre historique dépendra de la version au lieu du temps réel, mais le résultat final sera le même.

Si vous n'en avez pas déjà un, créez une table pour suivre la version de votre schéma de base de données. Et puis placez cette table de version de schéma de base de données sous CDC afin que vous puissiez aligner les modifications macroscopiques sur le schéma par rapport aux modifications microscopiques dans une table particulière.

À ma connaissance, vous devriez toujours voir les données ajoutées aux nouvelles colonnes, même si CDC n'affiche pas la modification du schéma. Et la migration des données de table en table devrait également être récupérée par CDC.

Existe-t-il des meilleures pratiques pour gérer les données capturées lors de la migration du schéma de base de données?

Traitez-le comme vous traitez un audit. Vous devez comprendre ce que vous examinez, pourquoi vous l'examinez et combien de temps vous devez conserver ces informations. La portée et la rétention sont les deux plus grands bugaboos quand il s'agit d'une tâche comme celle-ci.

Les outils de reporting de CDC sont naturellement austères, vous devez donc connaître le contexte des changements. Il est trop facile de dire " tout suivre !" et se retrouver avec rien qui est utilisable en conséquence. De même, vous pourriez doubler la taille de votre base de données en conservant une copie de chaque modification. Sur une table de désabonnement élevée avec de nombreux insertions et suppressions, vous vous retrouverez avec une croissance astronomique. Ce n'est pas mauvais en soi, mais vous devez prévoir un budget pour cette croissance et avoir un moyen d'examiner toutes les données générées.

Cela vous ramène donc à comprendre pourquoi vous êtes poussé à avoir une traçabilité complète. Il y a certainement des raisons valables à cette exigence. Mais vous ne pourrez pas structurer votre audit efficace de la base de données tant que vous ne saurez pas pourquoi vous devez satisfaire à cette exigence.

Vous pouvez suivre l'ajout de colonnes avec des déclencheurs 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 > [ ; ] }

Vous pouvez utiliser le groupe d'événements DDL_TABLE_EVENTS pour déclencher pour CREATE, DROP ou ALTER d'une table.

Cependant, vous voudrez peut-être jeter un œil à SQL Server Audit , si vous utilisez l'entreprise> 2008, car il peut "combine toutes les capacités d'audit dans une spécification d'audit". Ce lien msdn contient un article détaillé à ce sujet: 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 ]}

Ensuite, vous créez des spécifications de serveur ou de base de données.

Simple-Talk a un excellent article sur la capture de données modifiées et un guide très détaillé sur CDC ainsi que la documentation MSDN explique les différentes méthodes en fonction des exigences. Mais ils peuvent tous deux vous aider avec vos besoins spécifiques.