Question

Nous avons donc commencé à explorer l'utilisation de la capture de données de changement sur l'une de nos bases de données de production. Nous aimerions connaître le DateTime de chaque changement. Lecture Procédures pas à pas et tutoriels etc il semble que l'approche standard consiste à utiliser le LSN pour se rapporter à la cdc.lsn_time_mapping Table du système. Cette approche fonctionne mais n'est pas très simple ni interprète lorsque l'on parle de centaines de milliers de changements par jour.

Dans un environnement de test, j'ai effectué l'ajustement suivant aux tables de voie de changement. J'ai émis un ALTER TABLE instruction pour ajouter une colonne à la fin appelée [__ChangeDateTime] et a fait sa valeur par défaut GetDate(). L'approche semble fonctionner, le suivi des changements fonctionne toujours normalement, les DateTime sont capturés. Mais se moquer des tables de système me rend un peu nerveux.

Si ce n'est pas un Champ système que Microsoft a ajouté depuis le début Ils doivent avoir leurs raisons. Puisqu'ils ont plutôt opté pour l'approche LSN à cdc.lsn_time_mapping, je me prépare pour des problèmes en créant mon propre hack de cette façon?

METTRE À JOUR:

Découvert lors des tests que getDate () parfois n'est pas assez précis pour nos besoins - plusieurs changements partageant en même temps. Recommande d'utiliser sysdateTime () et DateTime2 Pour déplacer la valeur vers la nanoseconde. Option pour 2008+ seulement évidemment.

Pas de solution correcte

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top