Ventajas y Desventajas de Change Tracking

Hace algunas semanas un cliente me preguntó por opciones para auditar una situación específica. Decidí probar  si Change Tracking, una de las nuevas funcionalidades de SQL Server 2008, podía cumplir con sus necesidades. La conclusión es que Change Tracking no es una solución de Auditoría y por lo tanto hay que evitar usarla con ese propósito. En SQL Server 2008 existen otras opciones que pueden permitir tener un registro de los cambios a la información de las tablas, dependiendo de tus necesidades puedes evaluar alguna de las siguientes opciones:

-        Auditorías de SQL (Nueva en SQL 2008)

-        C2 Audit Mode (disponible desde SQL 2000)

-        SQL Traces (Disponibles desde SQL 2000)

-        Change Tracking (Nueva en SQL 2008)

-        Change Data Capture (Nueva en SQL 2008)

-        Código personalizado (triggers, columnas adicionales en las tablas, código adicional en los sp’s, etc.)

-        Herramientas de terceros

En éste caso decidimos probar Change Tracking. Change Tracking permite generar un registro cada vez que ocurre un cambio en un registro o columna. Para aprender cómo implementarlo referirse a https://msdn.microsoft.com/en-us/library/cc280462.aspx. Aquí me voy a enfocar en explicar las ventajas y limitantes que he encontrado hasta el momento en esta funcionalidad.

Ventajas

-        Fácil y rápida de implementar.

• No requiere cambios en la aplicación (a menos que se quiera agregar un contexto al cambio)
• Solo requiere configurar la BD, tablas y periodo de retención.

-        La implementación tiene mejor performance que la mayoría de las otras opciones porque es más granular y ligera.

-        Permite identificar cuantos cambios ha tenido el registro y no solo el último cambio.

-        Puedes agregar contexto a cada DML de modo que éste contexto se almacene como parte del registro de cambio (requiere cambio en el código para agregar el contexto)

-        Puedes identificar las columnas que cambiaron si lo configuraste para llevar el registro a nivel de columna.

-        No bloquea el log de transacciones por lo que la depuración automática en el Recovery Model Simple no se ve afectado como con otras opciones.

-        Es útil para identificar que registros y/o columnas han cambiado y necesitan moverse o actualizarse en el Data Warehouse.

-        Automáticamente se depura la información anterior a cierto tiempo configurado. No necesitas preocuparte por ésta depuración.

 

Desventajas

-        No registra la fecha y hora del cambio

-        No registra el usuario o login que hizo el cambio.

-        No guarda los datos modificados, solo registra el hecho de que hubo un cambio.

-        Dependiendo de la cantidad de cambios va a agregar algo de overhead, pero la gran mayoría de las veces no será significativo.

-        Debido a que la operación es síncrona agregará un poco de tiempo a cada transacción, la cantidad de tiempo dependerá de la cantidad de cambios sobre objetos con Change Tracking habilitado que se hagan dentro de la transacción.

 

“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”

Este material tambien lo podras acceder en https://blogs.technet.com/b/sql_pfe_latam/