Quand utiliser CDC pour suivre l'historique?

26

SQL Server Change Data Capture est une fonctionnalité qui lit les données historiques des journaux de transactions SQL Server et les stocke dans une table spéciale.

Grâce à l'utilisation de fonctions de valeur de table spéciales (TVF), il permet ensuite à l'utilisateur d'interroger ces données, ce qui permet soit d'obtenir toutes les modifications sur une table spécifique, soit uniquement les modifications nettes résultant des modifications dans un délai spécifique.

CDC a certains avantages

  • Il peut être configuré pour suivre uniquement certaines tables ou colonnes.
  • Il est capable de gérer les changements de modèle dans une certaine mesure.
  • Il n'affecte pas les performances aussi fortement que les déclencheurs car il fonctionne avec les journaux de transactions.
  • Il est facilement activé / désactivé et ne nécessite pas de colonnes supplémentaires sur la table qui doivent être suivies.

Il présente également certains inconvénients:

J'ai beaucoup lu sur CDC et même si je sais maintenant comment l'utiliser, je ne sais toujours pas si c'est le bon outil pour moi.

  1. Pour quelles tâches / scénarios le CDC est-il le bon outil? (par exemple, permettre aux utilisateurs de restaurer un objet de données à un certain moment? Audit? Affichage de l'historique complet des données?)
  2. Quand devriez-vous plutôt ne pas utiliser CDC, mais recourir à une solution basée sur un déclencheur personnalisé?
  3. Est-il acceptable d'utiliser CDC dans une base de données opérationnelle et d'utiliser les données CDC dans une application opérationnelle? (par exemple, le montrer à l'utilisateur final) Ou est-ce clairement une mauvaise utilisation de cette fonctionnalité?

J'entends souvent que CDC est un outil d'audit, mais n'est-ce pas à cela que sert SQL Server Audit ? S'agit-il de deux outils différents pour la même tâche? Ou le CDC peut-il être utilisé à d'autres fins?

Mon scénario actuel est que l'on me demande de construire un cadre de données fiable qui est censé être la base de plusieurs applications futures. Les exigences exactes sont floues, mais la première est qu'il devrait être en mesure de suivre l'historique des données et de restaurer les entrées plus anciennes ainsi que toutes les données associées d'autres tables. J'évalue actuellement le CDC en option, mais je ne sais pas si c'est la voie à suivre, car je ne trouve pas vraiment de cas d'utilisation recommandés.

Bien que j'apprécie les conseils pour mon scénario spécifique, les réponses devraient donner des conseils généraux sur le moment ou le moment de ne pas utiliser Change Data Capture.

sql-server change-data-capture data-versioning magnétique
la source
1
Idéalement, un «cadre» ne prendrait pas ce genre de décision; il serait laissé à des projets individuels. Mais comme on vous demande de le faire, je voudrais au moins faire remarquer à quiconque vous donne ces exigences: il existe différentes façons d'accomplir cela, et le meilleur choix dépend fortement de l'utilisation et des besoins exacts. Demandez-leur s'ils peuvent vous apporter des éclaircissements qui pourraient vous aider à décider (par exemple, si les performances ou la flexibilité sont plus importantes). Une autre option à considérer est de développer les deux options dans le cadre du «cadre» et de laisser les vrais projets choisir lequel activer.
jpmc26
@ jpmc26, le cadre peut être nécessaire pour empêcher chaque projet de passer du temps à décider ce genre de question.
Ian Ringrose
@IanRingrose Ce que je veux dire, c'est qu'essayer de prendre cette décision sans tenir compte des besoins spécifiques d'un projet causera, à long terme, plus de problèmes qu'il n'en résout (et donc en réalité plus coûteux que de passer ce temps). Il s'agit d'une décision qui ne peut pas être prise efficacement dans un cas général. Les spécificités du projet doivent être prises en compte. En utilisant une décision globale, vous passerez du temps à utiliser la solution choisie et à faire des hypothèses autour d'elle uniquement pour que ces hypothèses soient violées lorsqu'il est découvert que ce n'était pas une solution appropriée. Ensuite, le système devra être repensé.
jpmc26
1
@ jpmc26 Je pourrais en fait aller avec la solution que vous avez proposée, au cas où je trouverais un moyen de la retirer: développer à la fois un suivi de l'historique basé sur déclencheur et basé sur CDC, commutable et derrière une interface commune. Les applications peuvent alors choisir l'une ou l'autre, en fonction de leurs besoins, mais n'ont pas à se soucier de l'implémenter elles-mêmes. Bien sûr, je voudrais toujours obtenir une bonne réponse à ma question ci-dessus, car si le CDC n'est pas conçu pour ce type de tâche de toute façon (par exemple, car il n'est utile que pour l'audit), je pourrais me sauver la peine et toujours utiliser des déclencheurs .
Magnattic
"Si l'agent n'est pas en cours d'exécution ou se bloque, aucun historique n'est suivi" - mais s'il était redémarré, aucune modification ne serait perdue, non?
Andy Joiner

Réponses:

12

Premièrement,

La capture de données modifiées n'est disponible que sur les éditions Enterprise, Developer et Evaluation de SQL Server.

Cela peut donc décider pour vous si l'un de vos clients n'aura pas les éditions d'entreprise, ou si vous ne savez pas encore que vous utiliserez les éditions d'entreprise. (Comme la spécification inclut "plusieurs applications futures", cela peut être un vrai problème pour vous)

Contrairement aux déclencheurs, ce n'est pas en temps réel, c'est à la fois un avantage et un inconvénient. L'utilisation de déclencheurs ralentit toujours une mise à jour.

J'ai travaillé sur un système lorsque nous avons utilisé des déclencheurs (générés par CodeSmith), ainsi que le suivi de toutes les modifications apportées aux enregistrements, nous avons également lié les modifications ensemble à une table «historique» qui comprenait le module de l'application qui a effectué la modification, et l'élément d'interface utilisateur que l'utilisateur a utilisé pour effectuer la modification.

Cependant, il est préférable de résoudre ce problème au niveau de l'application, en écrivant toutes les mises à jour dans une file d'attente de messages qui est ensuite relue pour créer une base de données à tout moment donné, voir Temporal Patterns sur le blog Martin Flowler pour un bon aperçu des options.

Ian Ringrose
la source
Le lien est une lecture très intéressante, merci pour cela. Pourtant, résoudre ce problème au niveau de l'application n'est pas une option dans mon cas. Le cadre que je construis est censé faire la plupart du travail, y compris le suivi de l'historique, pour les applications basées sur celui-ci. Les applications travaillent ensuite avec une interface commune pour stocker / récupérer les données, afin qu'elles n'aient pas à se soucier de la façon dont les données sont stockées. Je suis conscient que cette tâche est loin d'être anodine.
Magnattic
De plus, je ne considère pas actuellement Enterprise Edition ou ne pas être un facteur décisif dans notre cas. Les futures applications dont je parle seront très probablement toutes construites et hébergées par nous.
Magnattic
@atticae, Votre framework ne doit pas être limité à la base de données, il peut inclure du code qui s'exécute en dehors de la base de données.
Ian Ringrose
Bien sûr, cela ne se limite pas à la base de données. (Je ne dirais pas que c'est un cadre dans ce cas.) Je vois ce que vous entendez maintenant par "niveau d'application" et j'utilise actuellement une variante du modèle de propriété temporelle dont votre lien parle. Le framework que je construis fournit cette interface aux applications qui l'utilisent. Pourtant, cela fait partie du côté interface, et rien de tout cela ne répond vraiment à mes questions décrites ci-dessus.
Magnattic
Merci encore pour votre réponse. C'est probablement le facteur décisif pour la plupart des gens, donc je pense que c'est une bonne réponse et probablement aider les futurs visiteurs à décider de ne pas utiliser CDC. Cependant, je pense que cela ne répond pas vraiment à la plupart de mes questions, donc je vais devoir donner la prime à stacylaray qui était le seul à essayer de répondre à toutes les questions que j'avais. (Bien que j'espérais une réponse un peu plus élaborée.)
magnattic
12

Voici une série en 9 parties très bien écrite qui passe en revue les différentes façons d'auditer les modifications des données SQL Server. Les parties 3, 4 et 5 se concentrent sur les CDC. Cela vaut la peine de lire tous les articles, car cela répondra à vos questions, comme les différents scénarios où les fonctionnalités seraient appropriées et les frais généraux. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

brynn
la source
1
Après avoir parcouru l'article, je ne suis toujours pas beaucoup plus intelligent. Comme la plupart des articles, il explique en détail comment utiliser CDC et comment il se compare au suivi des modifications. Cela ne répond pas vraiment à mes questions ci-dessus.
Magnattic
9

Pour quelles tâches / scénarios le CDC est-il le bon outil? (par exemple, permettre aux utilisateurs de restaurer un objet de données à un certain moment?

Peut-être que ça dépend.

Audit?

Oui.

Afficher l'historique complet des données?)

Oui.

Quand devriez-vous plutôt ne pas utiliser CDC, mais recourir à une solution basée sur un déclencheur personnalisé?

Lorsque les données du tableau des modifications ne répondent pas à vos besoins.

Est-il acceptable d'utiliser CDC dans une base de données opérationnelle et d'utiliser les données CDC dans une application opérationnelle? (par exemple, le montrer à l'utilisateur final)

Oui.

Ou est-ce clairement une mauvaise utilisation de cette fonctionnalité?

Non, ce n'est pas une mauvaise utilisation de cette fonctionnalité.

J'entends souvent que CDC est un outil d'audit, mais n'est-ce pas à cela que sert SQL Server Audit?

Oui.

S'agit-il de deux outils différents pour la même tâche?

Non.

Ou le CDC peut-il être utilisé à d'autres fins?

Le CDC peut être utilisé pour d'autres choses.

Il y a le suivi des modifications et la capture des données modifiées. Les deux ont leurs racines dans la réplication.

Le suivi des modifications permet de fournir les modifications nettes à une table. Un exemple d'utilisation serait une synchronisation d'appareils portables.

CDC, d'autre part, garde une trace de chaque petit changement, une histoire. On peut utiliser cet historique pour mettre à jour un entrepôt de données au lieu de copier en bloc des données, ou on peut utiliser cet historique comme données lui-même et générer des rapports à partir de celui-ci. La table de changement n'est pas masquée ni n'a un schéma bizarre ou quelque chose. Vous pouvez l'interroger et utiliser les données comme vous le souhaitez. Gardez à l'esprit ... ce n'est pas en temps réel, comme l'a dit Ian. Les données proviennent du journal des transactions, alors prenez-en soin comme vous le feriez avec la réplication, la mise en miroir ou l'envoi de journaux. Dans l'ensemble, ce sera plus rapide que les déclencheurs. Vous devrez utiliser Snapshot Isolation, qui a des frais généraux, et vous devrez penser à la récupération après sinistre.

stacylaray
la source
2

Un point de correction. À un moment donné, la capture des données modifiées n'était disponible que dans les versions répertoriées ci-dessus. Cependant, la capture des données modifiées est devenue disponible dans l'édition standard à partir de 2016 SP1. Ainsi, de nombreux articles écrits avant 2016 SP1 donnent l'impression que CDC est hors de portée pour ceux d'entre nous qui utilisent l'édition Standard. Ce n'est plus le cas. Le document Microsoft décrivant le CDC disponible est dans le lien ci-dessous.

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

Robert Sievers
la source