none
Change Tracking - Auto Cleanup RRS feed

  • Domanda

  • Salve,

    sto sperimentando la funzionalità di Change Tracking su SQL Server 2012; ho notato che, nonostante io imposti un periodo di CHANGE_RETENTION pari ad 1 GIORNO, le CHANGETABLE relative alle tabelle su cui ho abilitato il Change Tracking non si "puliscono" rispettando il periodo di tempo che ho indicato.

    Ho letto che il processo di AUTO_CLEANUP avviene in maniera asincrona e che quindi può accadere che non avvenga esattamente dopo il periodo di 1 GIORNO indicato in fase di abilitazione, ma non mi aspettavo che durasse molto più di un giorno!

    Qualcuno ha dei suggerimenti in merito a questa questione? Perchè per ora, l'unica soluzione che ho trovato è quella di disabiltiare e riattivare il Change Tracking "manualmente" per forzare il reset...

    Grazie per l'attenzione

    venerdì 23 dicembre 2016 23:49

Risposte

  • Ciao,

    su SQL Server 2008 era presente un bug che impediva la cancellazione dei dati trascorso il tempo indicato come retention, trovi i dettagli nella KB 973696.

    Su SQL Server 2012 il problema non dovrebbe esserci, ma se non l'hai già fatto ti consiglio di installare l'ultimo Service Pack (SP3) rilasciato per SQL Server 2012.. giusto per essere sicuri :)

    Fammi sapere se il problema si risolve dopo l'installazione dell'SP3.

    L'impostazione di CHANGE_RETENTION è più un suggerimento che un comando, e quindi può accadere che la pulizia dei dati non avvenga esattamente dopo il periodo.. però se hai impostato una RETENTION di 1 giorno non dovresti trovare dati molto più vecchi di un giorno.

    Se hai installato l'SP3 di SQL Server 2012 ed il problema rimane, una soluzione "tampone" può essere quella di utilizzare la stored procedure sys.sp_flush_commit_table_on_demand che permette di "pulire" manualmente i dati raccolti da Change Tracking, qui trovi un po' di informazioni.

    Ciao


    Sergio Govoni

    Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn 

    domenica 25 dicembre 2016 22:15
    Moderatore

Tutte le risposte

  • Ciao,

    su SQL Server 2008 era presente un bug che impediva la cancellazione dei dati trascorso il tempo indicato come retention, trovi i dettagli nella KB 973696.

    Su SQL Server 2012 il problema non dovrebbe esserci, ma se non l'hai già fatto ti consiglio di installare l'ultimo Service Pack (SP3) rilasciato per SQL Server 2012.. giusto per essere sicuri :)

    Fammi sapere se il problema si risolve dopo l'installazione dell'SP3.

    L'impostazione di CHANGE_RETENTION è più un suggerimento che un comando, e quindi può accadere che la pulizia dei dati non avvenga esattamente dopo il periodo.. però se hai impostato una RETENTION di 1 giorno non dovresti trovare dati molto più vecchi di un giorno.

    Se hai installato l'SP3 di SQL Server 2012 ed il problema rimane, una soluzione "tampone" può essere quella di utilizzare la stored procedure sys.sp_flush_commit_table_on_demand che permette di "pulire" manualmente i dati raccolti da Change Tracking, qui trovi un po' di informazioni.

    Ciao


    Sergio Govoni

    Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn 

    domenica 25 dicembre 2016 22:15
    Moderatore
  • Ciao,

    grazie per il tuo prezioso supporto!

    Nei prossimi giorni proverò ancora a monitorare se effettivamente ci sono grosse irregolarità nel processo di autocleanup ed in caso dovessero capitare, proverò con l'utilizzo della stored procedure che mi hai suggerito.

    Ti terrò aggiornato.

    Ciao

    lunedì 26 dicembre 2016 11:56
  • Ciao,

    ho provato a tenere monitorato in questi giorni la funzionalità di autoclean e sembra andare con una certa regolarità...(tenendo in considerazione il fatto che è sempre e rimarrà un qualcosa di asincrono).

    Tuttavia la sp di cui parlavi (sys.sp_flush_commit_table_on_demand) non "pulisce" il contenuto delle CHANGETABLE (dove ci sono gli effettivi record con tracciate le operazioni di U,I,D)....ed ho letto che solamente da SQL Server 2014 è stata raffinata con una versione che dovrebbe sormontare questo problema...

    Grazie ancora per l'interesse!

    giovedì 29 dicembre 2016 12:15
  • Ciao,

    grazie per il feedback.

    La stored procedure sp_flush_commit_table_on_demand "pulisce" la tabella di sistema sys.syscommittab che in alcune versioni di SQL Server può rimanere sporca, qui c'è l'articolo della KB 2446860.

    In questo momento non ho un'istanza SQL Server 2014 su cui verificare.. ma controllerò se è cambiata :)

    Ciao


    Sergio Govoni

    Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn 

    venerdì 30 dicembre 2016 00:04
    Moderatore