SQL Server 2008

Seguimiento de los cambios en la base de datos empresarial

Paul S. Randal

En resumen:

• La necesidad de realizar el seguimiento de los cambios
• Control de cambios en SQL Server 2005
• Cambiar el seguimiento de SQL Server 2008
• Cambiar la captura de datos de SQL Server 2008

Contenido

Control que cambia en SQL Server 2005
Formas más fáciles de control de cambios en SQL Server 2008
Cómo funciona de captura de datos de cambio
Cómo cambiar seguimiento funciona
Ajustar hacia arriba

Para los desarrolladores, un problema difícil de SQL Server seguimiento de qué datos han cambiado en una base de datos.Un desafío aún mayor es crear una solución sencilla que doesn’t afectan mucho al rendimiento de carga de trabajo y no es difícil de crear, implementar y administrar.Así, ¿por qué Ir a todos los problemas para realizar un seguimiento de los cambios realizados?¿Se seguimiento de los cambios realmente merece la pena todo este esfuerzo?Dos ejemplos normalmente citados son admitir actualizaciones a un almacén de datos y admitir la sincronización de heterogéneos, en ocasiones conectado sistemas.

Un almacén de datos normalmente tiene algunos representación de las tablas en la base de datos procesamiento de transacciones en línea (OLTP), pero los esquemas de tabla realmente pueden ser bastante diferentes.Esto significa que debe ser un proceso ETL (extracción, transformación, carga) que mueve datos de la base de datos OLTP al almacén de datos.

Puede considerar tres posibilidades para hacerlo.La primera es actualizar periódicamente el almacén de datos completa.Esto es claramente práctico para volúmenes grandes de datos y también significa que se actualiza para el almacén de datos no están continua.El segundo método es utilizar un esquema de partición en la base de datos OLTP para permitir que el proceso ETL funcionan únicamente con los datos que se nuevo desde el proceso ETL anterior.Este método sólo funciona para inserciones de datos, no se actualiza o elimina y requiere un mecanismo complejo para administrar la definición de límite de partición y conmutación de particiones.El tercer método es realizar el seguimiento de los cambios en los datos OLTP y sólo realizar el proceso ETL con los datos modificados.Éste es el método más eficaz en términos de volumen de datos.

Los dispositivos móviles son omnipresente en el entorno empresarial actual, lo que significa que tratar con sistemas conectados ocasionalmente es un requisito.En términos de sistemas de bases de datos, el problema es cómo actualizar de forma eficaz un almacén de datos en un dispositivo que no se conectan con frecuencia, especialmente cuando los datos de almacén sí mismo puede ser pequeño y radicalmente diferente en esquema de la base de datos principal.

Tenga en cuenta un representante de venta móvil responsable de una parte de un catálogo de productos muy grandes.Cada noche conecta su dispositivo de mano a la principal base de datos para descargar los datos más recientes, todos los cambios a esa parte del catálogo producto, simplificado para el almacenamiento en un dispositivo de mano.La transferencia de datos debe ser tan eficaz como sea posible.

Ahora, podría tener el sistema de base de datos de preparar la parte relevante completa del catálogo de productos para la descarga en el dispositivo y tiene el dispositivo descargarlo.En otras palabras, los datos se descargan cada vez que el dispositivo se conecta, incluso si no ha cambiado los datos.Esto es obviamente una solución ineficaz en su lugar.

Otro enfoque es que el sistema de base de datos realizar el seguimiento de los cambios en la parte relevante del catálogo de productos.A continuación, cuando se conecta el dispositivo de mano, pide para los datos que ha cambiado desde la última vez que conectado.En esta solución, el sistema de base de datos sólo tiene que preparar un subconjunto de los datos y la descarga es tan eficaz como sea posible.

Otro motivo para realizar el seguimiento de cambios es admitir auditoría, que es esencial en estos días.Auditoría realiza un seguimiento de los cambios realizados, así como al producirse el cambio y quién realizó el cambio.Esto realmente lleva cosas a otro nivel, con las restricciones rígidas alrededor durabilidad, seguridad y la corrección de una auditoría completa.

Las tecnologías que se diseñaron para realizar el seguimiento de los cambios de datos de SQL Server 2008 no se han pensado para admitir auditoría; sin embargo, SQL Server 2008 ofrece una nueva característica, que se denomina auditoría de SQL Server, que se diseñó específicamente para la auditoría.Rick Byham trata la característica de auditoría de SQL Server en su artículo "SQL Server 2008: seguridad" del el abril de 2008 problema de TechNet Magazine (disponible entechnet.microsoft.com/Magazine/cc434691).

Como puede observar, existen varias razones convincentes para realizar un seguimiento de los cambios realizados en los datos.¿Por lo que la pregunta importante es, la mejor forma se hacer seguimiento?

Control que cambia en SQL Server 2005

Con SQL Server 2005 (y versiones anteriores de SQL Server) no hay una solución sencilla enlatada.Por lo que para estas plataformas, los desarrolladores han tenido que crear soluciones personalizadas para sus aplicaciones, normalmente que intervienen columnas timestamp, DML (lenguaje de manipulación de datos) desencadenadores y tablas adicionales.Estas soluciones, sin embargo, presentan una variedad de posibles problemas.Por ejemplo:

• La adición de columnas timestamp hace que el esquema de tabla para cambiar (con efectos de knock-on posibles en procedimientos almacenados y otro código).
• Un desencadenador DML implícitamente es parte de la transacción que contiene el DML que se desencadena, por lo que su tiempo de ejecución aumentará la longitud de la transacción.El más complejo un desencadenador, más tardará en ejecutar y así mayor será el efecto perjudicial en el rendimiento de carga de trabajo.Desencadenadores DML utilizados para realizar el seguimiento de los cambios necesita procesar las tablas insertadas y eliminadas para reunir todos los cambios y, a continuación, insértelos en otra tabla de seguimiento.
• La tabla de seguimiento debe administrarse de alguna manera para evitar su crecimiento fuera del control, que puede requerir que crear algo como un trabajo del agente para recortar periódicamente los datos antiguos.

Formas más fáciles de control de cambios en SQL Server 2008

SQL Server 2008 presenta dos nuevas tecnologías que facilitan el seguimiento de los cambios en datos: cambiar seguimiento y cambiar la captura de datos.Ambas características realizar un seguimiento de los datos que ha cambiado (así como utilizar la inserción, actualización o las operaciones de eliminación para realizar un seguimiento de exactamente cómo se ha cambiado los datos), y eliminan la necesidad de soluciones personalizadas.Aparte esas similitudes, los mecanismos, y qué exactamente, un seguimiento son realmente bastante diferentes.

Captura de datos de cambio utiliza un mecanismo asincrónico que realiza un seguimiento de todos los cambios que ocurren en una tabla (o un conjunto definido de columnas de la tabla), incluida la columna de valores a sí mismos.Esto está diseñado para situaciones como el proceso ETL de almacén de datos descrito anteriormente.

La figura 1 muestra datos de cambio que se va a consumir en los sectores de tiempo.El mecanismo de captura de datos de cambio extrae los datos modificados en un conjunto de tablas, con los cambios más recientes que se está en la parte superior de la tabla.El proceso ETL, a continuación, puede consultar las tablas que contiene los datos de cambio de todos los cambios realizados dentro de un período establecido.Este mecanismo permite que el proceso ETL limitar la cantidad de datos que se deben consumir en cada lote.

La figura 1 históricos cambiar los datos que se va a consumir en los sectores de tiempo (haga clic en la imagen de una vista más grande)

Cambios, por otro lado, utiliza un mecanismo sincrónico que realiza un seguimiento sólo que una fila determinada cambiado en una tabla (y, opcionalmente, la lista de columnas que ha cambiado).Esto está diseñado para solucionar estos problemas como el escenario de sistema conectadas ocasionalmente descrito anteriormente.En la figura 2 se muestra este enfoque.

La Figura 2 un sistema conectada ocasionalmente con datos de control de cambios (haga clic en la imagen de una vista más grande)

Ambas características presentan un aumento de E/s y registro, pero esto es cierto con soluciones personalizadas, así, el cambio de datos tiene que estar almacenado en algún lugar.Lo que estas dos características potencialmente diferente de una solución personalizada es que las tablas utilizadas para almacenar los datos del cambio deben en la misma base de datos que las tablas que se va a realizarse.Esto significa todos los datos de cambio se se incluyen en las copias de seguridad y potencialmente transmitidos por la red por trasvase de registros o la creación de reflejos de bases de datos.

En términos de desarrollo, estas dos características deberían quitar una gran cantidad de la complejidad de seguimiento de los cambios.No hay los cambios de esquema de tabla o desencadenadores necesarios para cualquier tecnología.Tanto las tecnologías tienen procesos de limpieza automática, puede configurar, cambios de orden por transacción confirmación veces y proporcionan funciones integradas para recuperar información de cambio.

Desde la perspectiva de administración, hay ventajas y desventajas para cada enfoque.Como con cualquier tecnología, hay una gran cantidad de información debe comprender antes de desarrollar e implementar las soluciones que utilizan estas características.En el resto de este artículo dará una descripción general de cada una de estas características, conmovedor en cómo funcionan y los puntos prácticos tener en cuenta antes de utilizarlos en el entorno de producción.

Cómo funciona de captura de datos de cambio

Captura de datos de cambio no hace nada como parte de las transacciones que cambiar la tabla está realizando un seguimiento.En su lugar, la inserción, actualización las operaciones de eliminación se escribe en el registro de transacciones como normal y harvested periódicamente desde el registro.Harvesting realiza un trabajo de lector SQL Agent registro, y las operaciones harvested se almacenan en una tabla independiente denominada tabla de cambio.En algún momento posterior, se puede consultar la tabla de cambio para obtener los datos de cambio utilizando uno de dos funciones.La combinación de la tabla de cambio y las dos funciones se llama a una instancia de captura.la figura 3 muestra el flujo de datos mediante la captura de datos de cambio a unidad de un almacén de datos proceso ETL.

Habilitar cambio de captura de datos es un proceso de dos fases.En primer lugar un miembro de la función fija de servidor sysadmin debe habilitar la captura de datos de cambio para la base de datos mediante sys.sp_cdc_enable_db.A continuación, un miembro de la función fija de servidor db_owner debe habilitar cambio de captura de datos en una tabla específica con sys.sp_cdc_enable_table.Estos requisitos de seguridad se deben a la posibilidad de uso de disco alto si la captura de datos de cambio está mal configurado.Tiene sentido perfecta que un propietario de la tabla no se puede habilitar la característica y sorprenderle un administrador de base de datos con el uso de disco adicional.

Cuando cambio captura de datos está habilitada para una base de datos, algunos elementos se agregan a la base de datos, incluido un esquema nuevo (denominado cdc), algunas tablas de metadatos y un desencadenador para capturar los eventos de lenguaje de definición de datos (DDL).(Una función que CREO que es interesante es que puede obtener una lista de los cambios DDL en una tabla.)

Habilitar cambio de captura de datos crea también la instancia de captura de la tabla, el cambio de la tabla y a dos funciones para devolver cambiar datos.El nombre de la tabla de cambio es el mismo que la instancia de captura, con _CT anexado.La primera función siempre se crea y es el se utilizó para devolver cambiar datos de la tabla de cambio.La segunda función se crea si se especifica la opción para permitir el cambio neto.Esto significa en que se devuelve sólo el resultado final de todos los cambios capturados vez de todo el intermedio cambios que devuelve la primera función.Los nombres de función dos son, respectivamente, fn_cdc_get_all_changes_ y fn_cdc_get_net_changes_, con el nombre de instancia captura anexado.Tenga en cuenta que (como la característica de seguimiento de cambios) Esta funcionalidad requiere la tabla para tener una clave principal o otro índice único.

Cuando está trabajando con la primera tabla de la base de datos para que el cambio de captura de datos habilitada, se pueden crear dos trabajos del Agente SQL: el trabajo de captura y el trabajo de limpieza.Digo "se puede crear" porque el trabajo de captura es la misma que la utiliza para harvesting transacciones en la replicación transaccional.Si ya está configurada la replicación transaccional, a continuación, se crearán únicamente el trabajo de limpieza y el trabajo de lector existentes de registro también se utilizará como el trabajo de captura.Esto se buena debe tener dos trabajos de lector registro llevaría muy rápidamente a problemas de contención con el registro y, por tanto, problemas de rendimiento.En cualquier caso, se debe ejecutar el agente SQL si desea utilizar la captura de datos de cambio.

La lógica en el lector del registro copes automáticamente con las tablas que se está habilitada y deshabilitada para cambio datos capturan y altera lo que es harvested desde el registro de transacciones en consecuencia.Un punto importante tener en cuenta aquí es que una vez que captura de datos de cambio está habilitado, se el registro de transacciones comporta al igual que con la replicación transaccional, no se puede se trunca el registro hasta que el lector de registro ha procesado.Esto significa que una operación punto de control, incluso en el modo de recuperación SIMPLE, no truncar el registro a menos que ya se ha procesado por el lector del registro.

También, si el modelo de recuperación BULK_LOGGED se utiliza para reducir el registro, cambiar datos captura forzará todo completamente se convierten en sesión, excepto para las operaciones de crear o colocar y reconstrucción de índices.Cuidado si nunca se ha experimentado tal comportamiento, con que esto podría provocar transacción problemas de tamaño del registro, especialmente si se cambian los valores predeterminados de captura de trabajo para el registro no se procesa como con frecuencia.

De forma predeterminada, se el trabajo de captura ejecuta continuamente, detección el registro de cada cinco segundos y procesar un máximo de 500 transacciones desde el registro.También forma predeterminada, el trabajo de limpieza ejecuta todos los días a las 2 A.M.y quita todos los cambie las entradas de datos más de tres días de las tablas de cambio.Puede cambiar esta configuración mediante el procedimiento sys.sp_cdc_change_job y, a continuación, cambios no tendrán efecto hasta que reinicie los trabajos utilizando sys.sp_cdc_stop_job y sys.sp_cdc_start_job.

Aunque el proceso de lector de registro normalmente tendrá un impacto mínimo en el rendimiento del sistema, es posible en cargados mucho sistemas OLTP con mucho al modificar los datos que la adición de un solo proceso de lector de registro puede causar conflicto en el registro de transacciones.La contención real podría deberse a que los cabezales de disco tener que avanzar y retroceder entre el punto en el que se está escribiendo el registro de para las transacciones y el punto en el que se se lee por el proceso de lector del registro.En este caso, puede ser necesario cambiar la frecuencia en el que las ejecuciones de trabajo de captura para garantizar el rendimiento de OLTP no sufren.Sin embargo, esto, crea un espacio en disco clásico frente a rendimiento comercial de desactivar, seguirá creciendo hasta que lo procesa el trabajo de captura el registro.

El problema mismo se produce si se cambian las limpieza trabajo frecuencia o cambiar datos períodos de retención, seguirán creciendo hasta que se limpiar los datos de cambiar las tablas de cambio.Esto conduce a una consideración de diseño completo de qué se hace seguimiento y cuánto se conserva.Aspectos importantes que tener en cuenta aquí se incluyen:

• La lista de columna necesaria para la instancia de la captura.Cuando se capturan más columnas, más datos de cambio se inserta en las tablas de cambio.
• Cantidad de espacio en disco utilizado por las tablas de cambio.
• La frecuencia en el que el proceso se ejecuta que consume los datos de cambio.Tenga en cuenta que los datos no se eliminará si no se ha usado todavía.
• La frecuencia que se ejecuta el proceso de limpieza, puede haber, de modo muy cambiar datos generados que el proceso de limpieza que elimina sólo puede ejecutarse en el fin de semana, por ejemplo, ya que en caso contrario, genera demasiado registro de transacciones.

Captura de datos de cambio puede establecerse hacia arriba para realizar sólo el seguimiento de todos los cambios a una tabla o para realizar un seguimiento de un subconjunto de las columnas de una tabla.Utilizar un subconjunto puede ser útil si algunas de las columnas no importantes son columnas de gran varchar o columnas de objetos grandes binario (BLOB) (como texto, imagen o XML); de lo contrario, el espacio utilizado por la tabla de cambio puede crecer resultar difíciles de administrar muy rápidamente.

Dado el mayor potencial de uso de espacio en disco, la ubicación de grupo de archivos de la tabla de cambio se puede establecer cuando está habilitado Cambiar captura de datos.Esto permite facilitar la administración del espacio de disco subyacente y significa que todos los datos de cambio potencialmente pueden almacenarse en un volumen con un nivel RAID menos costoso que la base de datos principal.Además, aunque la configuración de trabajo de limpieza se aplica a todas las instancias de captura, una instancia de captura individual puede por separado limpiar en cualquier momento si el espacio en disco se convierte en un problema.Puede supervisar fácilmente uso de espacio de disco mediante sp_spaceused en las tablas de captura.

La fila real que se escriben en la tabla de cambio contiene metadatos acerca de la transacción (el número de secuencia de registro de confirmación o LSN), así como el orden de la transacción que se realizado el cambio, lo que la operación se, una máscara de bits de los cuales se han cambiado columnas, y los valores de columna reales.

Los cambios DDL son sin restricciones mientras captura de datos de cambios está habilitado.Sin embargo, pueden tener algún efecto en los datos de cambio recopilados si las columnas se agregan o eliminan.Si se interrumpe una columna de marcas, todas las entradas más de la instancia de captura tendrá NULL para esa columna.Si se agrega una columna, se omitirá por la instancia de captura.Es decir, la forma de la instancia de la captura se establece cuando se crea.

Si los cambios de columna se requieren, es posible crear otra instancia de captura de una tabla (a un máximo de instancias de captura dos por tabla) y permitir que los consumidores de los datos de cambio migrar el nuevo esquema de tabla.Pero debe tener cuidado al realizar esto porque dos instancias de captura de una tabla seguimiento significan dos veces la cantidad de espacio en disco, las operaciones de E/s y registro.

Sin entrar en demasiados detalles, se recuperan los cambios de las tablas de cambio mediante las funciones que he descrito.Las funciones de realizar un inicio LSN y finalizar LSN y no existe proporcionadas otras funciones que permiten convertir un tiempo normal en un LSN.Al recuperar las actualizaciones, puede incluso especificar si desea ver el antes y después de valores o sólo la antes.Hay un screencast de me mediante la captura de datos de cambio está disponible enwww.technetmagazine.com/Video.

Cómo cambiar seguimiento funciona

Como he ha mencionado, control de cambios es un proceso sincrónico y es mucho menos compleja que cambiar la captura de datos.Forma parte de la transacción que realiza un cambio en una fila de una tabla que está realizando un seguimiento, y el hecho de que la fila ha cambiado seguimiento se realiza en una tabla independiente.La tabla es lo que denomina una tabla interna y no hay ningún control sobre su nombre o donde está almacenado.No considerar esto un problema cuando deberían haber mucho menos datos en esta tabla de en una tabla cambio utilizada para la captura de datos de cambio.Pero puede seguir haber problemas de espacio de disco, como explicaré en un momento.

El hecho de que el control de cambios se realiza sincrónicamente significa que hay realizado dentro de cada transacción que cambia la tabla que está realizando un seguimiento de procesamiento adicional.El efecto en el rendimiento es similar a la que cuando un índice no agrupado existe en la tabla y debe actualizarse con cada cambio en la tabla.También se realiza un seguimiento de transacciones a sí mismos cuando que confirmen una fila de la tabla sys.syscommittab interno.

Control de cambios está habilitado y deshabilitado utilizando normal ALTER DATABASE sintaxis ALTER TABLE y sigue el mismo modelo que captura de datos de cambio, donde debe habilitarse en el nivel base de datos antes el nivel de tabla.La secuencia de operaciones tendría este aspecto:

ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON
  (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
GO
USE AdventureWorks2000;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
  WITH (TRACK_COLUMNS_UPDATED = ON);
GO

Los permisos necesarios para habilitar cambiar seguimiento en la base de datos y los niveles de la tabla también son diferentes de los para habilitar la captura de datos de cambio: db_owner y el propietario de la tabla, respectivamente. Cuando el control de cambios está habilitado en el nivel de base de datos, se puede establecer el período de retención, así como si datos cambios se automáticamente limpian. El período de retención predeterminado es 2 días, con un máximo de 90 días y un mínimo de un minuto.

Limpieza automática también está activado de forma predeterminada. Al realizar cambios en esta configuración, necesita evaluar los pros y contras mismos como se analizó con captura de datos de cambio, básicamente disco espacio y rendimiento con respecto a necesidades de aplicaciones.

De forma predeterminada, lo que se captura para cada fila es sólo que cambiado. Para ello, realizar una nota de la clave principal de la fila que ha cambiado (lo que significa que control en una tabla de cambios requiere que tenga una clave principal), junto con un número de versión (una vez que una base de datos está habilitado para realizar un seguimiento de cambio, un número de versión se incluyeron, lo que permite orden de las operaciones) y el tipo de operación que ha realizado el cambio. Opcionalmente, también puede registrar las columnas que cambiado; esto requiere 4 bytes por columna modificado.

Supervisión de espacio de disco es ligeramente diferente con cambio de seguimiento, ya que los datos de cambio se almacena en tablas internas. Para buscar los nombres de las tablas internas utilizadas, utilice simplemente la vista de catálogo de sistema de sys.internal_tables:

SELECT [name] FROM sys.internal_tables
  WHERE [internal_type_desc] = 'CHANGE_TRACKING';
GO

A continuación, pase el nombre en sp_spaceused para ver cuánto espacio en disco se está utilizando.

A diferencia de con captura de datos de cambio, cuando está habilitado el seguimiento de cambios, existen restricciones en el DDL que pueden realizarse en una tabla que está realizando un seguimiento. La restricción más notable es que la clave principal no puede modificarse de ninguna manera. La otra restricción merece la pena llamada fuera aquí es que un modificador de TABLE ALTER no funcionará si cualquier tabla implicada tiene control de cambios habilitada. Esto se probablemente debido al hecho de que no tiene sentido para iniciar automáticamente o quitar control de cambios para una partición que se cambia fuera de un cambio realiza un seguimiento, tabla con particiones o una tabla de marcas de cambio que se cambia a una tabla con particiones, respectivamente.

Los cambios se recuperan de las tablas de cambio internos mediante una nueva función CHANGE­TABLES (cambios …). Éste toma el nombre de la tabla de marcas de cambio más el número de versión desde el momento anterior utilizó y devuelve información sobre todas las filas que han cambiado desde ese momento anterior. Existen diversas funciones para buscar la versión válida más antigua y actual. La aplicación, a continuación, puede utilizar la información que se devuelve al consultar la tabla se cambios que realiza un seguimiento para obtener los valores de columna reales. Esto, por supuesto, es un proceso consta de varios pasos, que obtener la versión actual, utilizar esa versión de control de cambios de consulta y, a continuación, consultar las tablas reales de los datos columna correspondiente a esa versión.

En un sistema constantemente cambiante, es posible obtener resultados incoherentes o son incorrectos a menos que algún tipo de vista invariable de la versión, cambiar datos, y se mantienen datos de columna reales. Para ello, puede utilizar el aislamiento de instantánea y ajustar el proceso de múltiples pasos en una transacción explícita. Esto buenos pero tiene inconvenientes potenciales. Aislamiento de instantánea puede afectar al rendimiento carga de trabajo, y afecta al rendimiento y uso del espacio de tempdb. Se puede obtener más información detallada sobre esto en technet.microsoft.com/library/cc280358.

Ajustar hacia arriba

la figura 4 proporciona una comparación de al lado de datos de seguimiento y cambio de cambio para que pueda hacerse una idea mejor de las diferencias principales que le preocupan los administradores de bases de datos. Puede ver de la tabla que captura de datos de cambio es mucho peso heavier de control de cambios. Se requiere más atención al decidir qué debe realizar un seguimiento debido a la posibilidad de crecimiento rápido en el tamaño de la tabla seguimiento de si a que, por ejemplo, la tabla que se realiza un seguimiento contiene BLOB columnas o filas muy amplia. Hay también la posibilidad de transacción problemas de administración del registro, como el registro no se truncará hasta que el lector de registro ha harvested registros del registro de.

La figura 4 comparación entre cambiar seguimiento y cambiar la captura de datos

Control de cambios no es sin sus propios requisitos, sin embargo. Por ejemplo, una clave principal es necesaria, y es muy recomendable que utilice el aislamiento de instantánea cuando está habilitado el control de cambios. Aislamiento de instantánea propio puede agregar una sobrecarga de carga de trabajo significativo y requiere mucho más una administración de tempdb cuidadosa.

Hay un problema más que los desarrolladores y administradores de bases de datos deben resistir: recuperación de desastres. Aunque esto explicar detalladamente está fuera del alcance de este artículo, el tema de recuperación ante desastres es demasiado importante no menos mencionar aquí.

Ambas características reproducir bien con BACKUP y RESTORE. El problema resulta cuando una base de datos Obtiene restaurado y básicamente, se toma volver en tiempo. ¿Cómo debe comportar la aplicación o sistema general? Soluciones personalizadas diseñadas para realizar el seguimiento de los cambios también enfrentan a este problema, y todavía necesita tener en cuenta al utilizar SQL Server 2008.

Como siempre, asegúrese de que de lectura a través de todo el (documentación disponible technet.microsoft.com/library/bb418491) y las notas del producto existentes antes ha embarcado en un proyecto de diseño e implementación que incluye las nuevas características para realizar un seguimiento de los cambios realizados. Deberá primero averiguar si los posibles problemas no tratan aquí pueden aplicar a la. También debe obtener detalles sobre el nuevo Service Pack de supervisión y las vistas de administración dinámicas (DMV).

En general estas nuevas características son un gran avance a través de métodos anteriores para realizar el seguimiento de los cambios de datos. Ahora que ya existen, puede estar seguro de los desarrolladores desea usarlos en soluciones que administran.

Hay problemas de administración que tener en cuenta y de configuración importante, y espero que este artículo ha proporcionado una introducción sólida de las tecnologías para que pueda prever y preparar algunos de los problemas que he tratado. Si dispone de los comentarios sobre este artículo o preguntas, continuar y eliminar me una línea en Paul@SQLskills.com.

S. Paul Randal es el director de administración de SQLskills.comy un MVP de SQL Server. Trabajado en el equipo de motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Paul escribió DBCC CHECKDB y reparar para SQL Server 2005 y era responsable del motor de almacenamiento principal durante el desarrollo de SQL Server 2008. Paul es un experto en recuperación ante desastres, una alta disponibilidad y mantenimiento de la base de datos y un moderador habitual en conferencias de todo el mundo. Blogs en SQLskills.com/blogs/paul.