change tracking clean up

Bonjour,

Je viens de découvrir le change tracking qui pourrait m'être utile pour créer mon propre système de synchronisation.

via select from changetable on peut connaitre les lignes modifiées/supprimées, par contre je souhaiterais pouvoir supprimer des lignes de cette vue

l'option auto cleanup n'est pas géniale à mon gout, si on met trop peu de temps on risque de perdre des modifs, si on met trop long ca fait du stockage pour rien et on est obligé de gérer un numéro de version

si on disable le clean up auto il ne semble pas y avoir un moyen de le gérer manuellement à part via disable puis re enable le change tracking sur la table, et là je pense que je risque d'avoir une potentielle perte de données ...

quelqu'un aurait une idée de comment je pourrais m'en sortir ? un nom de table système où l'on peut taper dedans ?

sql server profiler ne semble pas intercepter ce qui se passe pour marquer les modifs ou les ressortir via change table, pourtant si on disable puis re enable le change tracking dans une transaction qu'on rollback tout reste bien dedans, donc ca doit taper dans des tables

merci

Pas d'option manuelle pour cleaner les données stockées les tables systèmes. Tu vas être obligé de jouer avec la tâche de cleanup de cette fonctionnalité.

Citation:

---

si on met trop peu de temps on risque de perdre des modifs, si on met trop long ca fait du stockage pour rien et on est obligé de gérer un numéro de version

---

Tu peux temporairement désactiver le cleanup en cas de problème.

++

J'ai finalement trouvé une solution

avec ceci la table me semble bien verrouillée tant que le commit n'est pas passé

Code:

---

1 2 3 4 5

begin tran alter table t disable change_tracking -- une pause ici, exécution en 2x dans management studio alter table t enable change_tracking commit tran

---

testé avec un insert et un update depuis une autre fenetre de management studio et ca attend

en fait il me manque quand même un truc, car je dois lire les données avant de disable, et entre la lecture et le disable il ne faut pas non plus qu'il y a modification sur la table

il y a un moyen de verrouiller un table ?

Il n'y a pas tant d'impact disque que ça, on ne stocke pas les données modifiées contrairement au CDC, juste la valeur de clé primaire, et quelques informations contextuelles dans la table de tracking. Je ne vois pas pourquoi tu ne veux pas laisser la rétention à 2j par défaut. C'est plutôt une question de performances, car CT est synchrone avec la transaction. Si le système est essentiellement du TP, ça risque de ralentir un peu le nombre de transaction / sec.

Citation:

---

Envoyé par dbaffaleuf

Je ne vois pas pourquoi tu ne veux pas laisser la rétention à 2j par défaut.

---

en cas de coupure d'internet ca perd des données
avec le clean up auto on est obligé de gérer le numéro de version, ca fait plus de dev

Citation:

---

Envoyé par dbaffaleuf

C'est plutôt une question de performances, car CT est synchrone avec la transaction. Si le système est essentiellement du TP, ça risque de ralentir un peu le nombre de transaction / sec.

---

TP = ?


je vais me reconcentrer sur la problématique de départ parce qu'il y a surement d'autres solutions

Citation:

---

Envoyé par Pol63

en cas de coupure d'internet ca perd des données
avec le clean up auto on est obligé de gérer le numéro de version, ca fait plus de dev

---

? Les données sont toujours présentes dans la base, l'historisation des changements dans les tables de tracking. Je ne vois pas ce qu'on perd là dedans.

Citation:

---

Envoyé par Pol63

TP = ?

---

Transactionnal Processing. Concurrence élevée et nombreuses modifications atomiques et aléatoires. Par exemple un système de réservation. De nombreuses transactions sont générées et comme le CT est synchrone, il faut attendre que la modification ait été archivée dans la table de tracking avant la fin du COMMIT; http://en.wikipedia.org/wiki/Online_...ion_processing

Citation:

---

Envoyé par dbaffaleuf

? Les données sont toujours présentes dans la base, l'historisation des changements dans les tables de tracking. Je ne vois pas ce qu'on perd là dedans.

---

si la connexion est coupée pendant plus de 2 jours le clean up va effacer des infos de mise à jour de lignes ...

Dans ce cas là ce n'est pas du CT qu'il faut, c'est du pur store & forward comme la réplication transactionnelle en mode PULL par exemple, si la synchronisation ne se fait que dans un sens. Si elle doit se faire dans les deux sens, il faut regarder la réplication merge (fusion).

en fait on cherche à synchroniser plusieurs bases
certaines sont sur sql server express, et apparemment on ne peut pas faire de réplication bidirectionnelle car express ne peut pas publier

je vais donc partir sur le change tracking je pense
il faut que je fasse quelques essais en simulation de charge pour être sûr qu'on ne peut pas perdre d'info de modif
car le principe serait dans ce genre :
- begin tran
- lecture de changetable pour voir ce qu'il y a à mettre à jour (insert into #table des clés)
- disable tracking
- enable tracking
- mise à jour entre les 2 bases via un serveur lié à partir de #table
- commit tran
j'ai vu qu'entre disable et enable pas de soucis car la transaction bloque la table source du tracking, il me reste à vérifier/trouver une solution entre insert dant #table et disable tracking

(peut etre avec une table en dur plutot pour pouvoir commiter plus tot et faire le reste après)