SQL Server

Descripción registro y recuperación de SQL Server

Paul S. Randal

En resumen:

• Funcionen de registro y la recuperación de SQL Server
• Cómo funciona el registro de transacciones y lo necesita saber acerca de administración
• Modelos de recuperación y su efecto en el registro

Contenido

¿Qué es el registro?
¿Qué es la recuperación?
El registro de transacciones
Modelos de recuperación
Ajustar hacia arriba

Algunas de las partes comprendidas de SQL Server son su registro y los mecanismos de recuperación.El hecho de que el registro de transacciones existe y puede causar problemas si no administra correctamente parece confound los muchos "involuntarias administradores." ¿Por qué es posible para el registro de transacciones crecer ilimitado?¿Por qué a veces tarda tanto para que la base de datos ponerse en conexión después de un bloqueo del sistema?¿Por qué no se puede registro se desactivar completamente?No se puede ¿por qué recuperar la base de datos correctamente?Sólo ¿cuál es el registro de transacciones y por qué hay?

Estos son todas las preguntas que ver varias veces en los foros de SQL Server y los grupos de noticias, de manera que en este artículo desee ofrecer una visión general del sistema de recuperación y registro y explique por qué trata dicha parte integral del motor de almacenamiento de SQL Server.Explicará la arquitectura del registro de transacciones y cómo los modelos de recuperación tres disponibles para una base de datos pueden cambiar el comportamiento del registro de transacciones y el propio proceso de registro.En el camino, también le proporcionan algunos vínculos a recursos de prácticas recomendadas de administración de registro de transacciones de cobertura.

¿Qué es el registro?

Registro y la recuperación no son conceptos que son exclusivos de SQL Server, todos los sistemas de administración de bases de datos relacionales comerciales (RDBMS) deben tener que admita las propiedades ACID varias de las transacciones.ACID significa atomicidad, coherencia, aislamiento y durabilidad, que son las propiedades fundamentales de un sistema de procesamiento de transacciones (como un RDBMS).Puede obtener más información sobre este en elSección de propiedades de ACID de la biblioteca de MSDN.

Vídeo

Paul Randal muestra la importancia de administrar el registro de transacciones correctamente en el modelo de recuperación completa y muestra las técnicas para hacerlo en SQL Server.

Las operaciones en un RDBMS se ha iniciado (o registradas) en el físico y lógico nivel en términos de lo que ocurre en las estructuras de almacenamiento de la base de datos.Cada cambio en las estructuras de almacenamiento tiene su propio registro a registro, que describe la estructura que se va a cambiar y lo que era el cambio.Para ello de tal forma que se puede reproducir o deshacer, el cambio si es necesario.Los registros se almacenan en un archivo especial llamado el registro de transacciones, describirá este con más detalle más adelante, pero por ahora se puede considerar de ella como un archivo secuencial acceso.

Un conjunto de uno o más estos cambios pueden estar (y de hecho, siempre son) agrupados juntos en una transacción, que proporciona la unidad básica de realizar cambios (atomicidad) en una base de datos hasta como usuarios, los programadores de aplicaciones, y los administradores de bases de datos se refiere.Una transacción tiene éxito (confirmación) o se produce un error o cancela (restauración).En el primer caso, las operaciones que forman la transacción se garantiza que se reflejarán en la base de datos.En el segundo caso, las operaciones se garantiza que no se reflejarán en la base de datos.

Las transacciones en SQL Server son marcas comerciales explícita o implícita.Una transacción explícita es uno que el usuario o la aplicación emite una instrucción BEGIN TRANSACTION T-SQL, señalización el inicio de un grupo de cambios relacionados por esa sesión.Una transacción explícita correctamente cuando se emite una instrucción COMMIT TRANSACTION, señalización la correcta realización del grupo de cambios.Si en su lugar, se emite una instrucción ROLLBACK TRANSACTION, todos los cambios de esa sesión desde que se emitió la instrucción BEGIN TRANSACTION se revertir (deshacer) y se anula la transacción.También se puede forzar una reversión de transacciones mediante un evento externo, como la base de datos se quede sin espacio en disco o un bloqueo de servidor, como explicará más adelante.

Una transacción implícita es uno que el usuario o la aplicación no explícitamente emite una instrucción BEGIN TRANSACTION antes de emitir una instrucción de T-SQL.Sin embargo, dado que todos los cambios realizados en la base de datos deben ser transaccionales, el motor de almacenamiento se iniciará automáticamente una transacción en segundo plano.Cuando finalice la instrucción de T-SQL, el motor de almacenamiento confirma automáticamente la transacción que inició para ajustar alrededor de la instrucción del usuario.

Se puede considerar que no es necesario porque una única instrucción T-SQL no generar un número grande de los cambios en las estructuras de almacenamiento de la base de datos, pero considere algo parecido a una instrucción ALTER INDEX REBUILD.Aunque esta instrucción no puede incluirse en una transacción explícita, podría generar un número enorme de los cambios en la base de datos.Por lo que debe haber algún mecanismo para garantizar que si algo ir mal (la instrucción se cancela, por ejemplo), todos los cambios se correctamente revierten.

Como ejemplo, considere lo que ocurre cuando se actualiza una fila de tabla única en una transacción implícita.Imagine una tabla de montón simple con un c1 de la columna entero y un c2 de la columna char.La tabla tiene 10.000 filas, y un usuario envía una consulta de actualización de los siguientes:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

Realizarse las siguientes operaciones:

• Se leen las páginas de datos de SimpleTable desde el disco en la memoria (el grupo de búferes) para que se pueden buscar las filas coincidentes. Resulta que las páginas de datos tres contienen cinco filas que cumplen el predicado de la cláusula WHERE.
• El motor de almacenamiento se inicia automáticamente una transacción implícita.
• Las páginas de tres datos y las filas de datos cinco están bloqueadas para permitir las actualizaciones que se produzca.
• Se realizan los cambios en los registros de datos de cinco en las páginas de datos tres en la memoria.
• Los cambios se registran también en registros en el registro de transacciones en el disco.
• El motor de almacenamiento confirma automáticamente la transacción implícita.

Tenga en cuenta que no mostrar un paso donde las páginas de las tres datos actualizados se escriben volver en el disco. Se trata porque aún no necesitan que; siempre que los registros se describen los cambios están en el disco en el registro de transacciones, los cambios están protegidos. Si las páginas necesita ser leído o cambien de nuevo posteriormente, a continuación, la copia más actualizada de la página es ya en memoria, pero no en disco (aún). Las páginas de datos se escribirse en el disco cuando se produce la siguiente operación punto de control o si la memoria que utilizan en el grupo de búferes es necesaria para otra imagen de la página.

Puntos de control existen para dos razones: para las operaciones de E/s para mejorar el rendimiento y reducir el tiempo de escritura de lotes necesario para la recuperación de bloqueo. En términos de rendimiento, si una página de datos se veían obligada salida en el disco cada vez que se actualiza, el número de escritura que se producen en un sistema ocupado las operaciones de E/s podría fácilmente sobrecargar el subsistema de E/s. Es mejor periódicamente escribir páginas desfasadas (las páginas que han cambiado desde que se leen del disco) que al escribir páginas inmediatamente cuando que se cambian. HABLARÉ sobre los aspectos de recuperación de los controles en un momento.

Una equivocación común sobre los puntos de comprobación es que sólo escribir páginas con los cambios de las transacciones confirmadas. Esto no es cierto, una punto de control siempre escribe todas las páginas desfasadas, independientemente de si ha confirmado la transacción que ha cambiado una página o no.

Registro de escritura anticipada es el mecanismo que en que se escriben los registros que describe un cambio en el disco antes de los cambios ellos mismos se escriban. Proporciona la parte de durabilidad de las propiedades ACID. Siempre que los registros que describen los cambios sean en disco, en el caso de un bloqueo, los registros (y, por tanto, los cambios ellos mismos) se pueden recuperar y los efectos de la transacción no se pierden.

¿Qué es la recuperación?

¿Busca las sugerencias de SQL Server?

Para obtener sugerencias acerca de SQL Server, visite la Las sugerencias de TechNet Magazine SQL Server página.

Para obtener más sugerencias en otros productos, visite la Índice de TechNet Magazine sugerencias.

El registro existe para admitir una variedad de operaciones de SQL Server. Esto garantiza que si se produce un error, una transacciones confirmadas correctamente aparecerán en la base de datos después del bloqueo. Asegura que una transacción sin confirmar se se correctamente deshace y no se reflejan en la base de datos después de un bloqueo. Garantiza que es posible cancelar una transacción en curso y dispone de todas sus operaciones deshacer. Permite una copia de copia de seguridad del registro de transacciones para realizarse de forma que pueda restaurar una base de datos y las copias de las seguridad del registro de transacciones reproducidos para poner la base de datos a un punto específico en el tiempo con coherencia transaccional. Y admite características que dependen de leer el registro de transacciones, como la replicación, la creación de reflejos de bases de datos y captura de datos de cambio.

La mayoría de estos usos de registro implican un mecanismo denominado recuperación. Recuperación es el proceso de disponer de los cambios que se describe en los registros de registro reproducidos o revertido en la base de datos. Reproducir los registros se denomina REDO (o rollo hacia delante) fase de recuperación. Registro reverting registros se denomina DESHACER (o al volver) fase de recuperación. En otras palabras, recuperación se asegurará que una transacción y todos sus registros de registro constituyentes son bien rehacer o deshacer.

La forma sencilla de recuperación es cuando se cancela una transacción única, en cuyo caso se trata de deshacer y no hay ningún efecto neto en la base de datos. La forma más compleja es recuperación de errores, cuando SQL Server se bloquea (por cualquier motivo) y se debe recuperar el registro de transacciones para llevar la base de datos a un punto transaccionalmente coherente. Esto significa que todas las transacciones que se encontraban confirmadas en el momento del bloqueo se deben propagar hacia delante para garantizar que sus efectos son persistentes en la base de datos. Y todas las transacciones en curso que no habían confirmado en el momento del bloqueo deben se deshace para garantizar que no se conservan sus efectos en la base de datos.

Esto es porque no ninguna característica para una transacción en SQL Server para continuar después de un bloqueo. Por lo tanto, si los efectos de una transacción completa parcialmente no se deshace, la base de datos podría quedar en un estado incoherente (posiblemente incluso estructuralmente dañada, según lo que se la transacción en el medio de esto).

¿Cómo recuperación sabrá qué hacer? Todos los procesos de recuperación dependen el hecho de que cada registro se marca con un número de secuencia registro (LSN). Un número de secuencia del registro es un número creciente, tres partes que define de forma exclusiva la posición de un registro en el registro de transacciones. Cada registro de registro de una transacción se almacena en orden secuencial en el registro de transacciones y contiene el IDENTIFICADOR de transacción y la LSN del registro anterior registro de la transacción. En otras palabras, cada operación que se registra como parte de la transacción tiene un "vínculo" volver a la operación que precedido inmediatamente.

En el caso sencillo de una única transacción se deshace, el mecanismo de recuperación puede fácil y rápidamente seguir la cadena de operaciones registradas en la operación más reciente de volver a la primera operación y deshaga los efectos de las operaciones en el orden opuesto desde el que se produjeron. Las páginas de base de datos que afectados por la transacción son todavía en el grupo de búfer o en el disco. En ambos casos, la imagen de la página que está disponible se garantiza que se uno donde el efecto de la transacción se refleja en la página y se debe deshacer.

Durante la recuperación de bloqueo, el mecanismo es más complicado. El hecho de que las páginas de bases de datos no se escriben en disco cuando se confirma una transacción significa que no se garantiza que el conjunto de páginas de base de datos en disco refleja con exactitud el conjunto de cambios se describe en el registro de transacciones, ya sea para las transacciones confirmadas o no confirmadas. Sin embargo, hay una pieza final del rompecabezas que he no ha mencionado aún, todas las páginas de base de datos tienen un campo en el encabezado de página (una parte de 96 bytes de la página de 8192 bytes que contiene metadatos acerca de la página) que contiene el LSN del último registro registro que afectados de la página. Esto permite el sistema de recuperación decidir qué hacer con un registro concreto que debe recuperar:

• Para un registro de una transacción confirmado en la página de base de datos tiene un igual LSN a o mayor que el LSN del registro de registro, no hay nada necesita realizarse. El efecto del registro ya se ha conservado en la página en el disco.
• Para un registro de registro de una transacción confirmado en la página de base de datos tiene un LSN menor que el LSN del registro de registro, se debe rehacer el registro para garantizar que se conservan los efectos de transacción.
• Para un registro de registro en una transacción sin confirmar que la página de base de datos tiene un igual LSN a o mayor que el LSN del registro de registro, se debe deshacer el registro para garantizar que no se conservan los efectos de transacción.
• Para un registro de una transacción no confirmado en la página de base de datos tiene un LSN menor que el LSN del registro de registro, no hay nada necesita realizarse. El efecto del registro no se conserva en la página en el disco y como no es necesario que deshacer.

Recuperación de bloqueo leen el registro de transacciones y asegura que todos los efectos de las transacciones confirmadas todo se conservan en la base de datos, y todos los efectos de todas las transacciones sin confirmar no son persistentes en la base de datos, el REDO y DESHACER fases, respectivamente. Una vez completada la recuperación de errores, la base de datos se transaccionalmente coherente y se encuentra disponible para su uso.

He mencionado anteriormente que uno de los usos de una operación punto de control es reducir la cantidad de tiempo que bloquea la toma de recuperación. Al vaciar periódicamente todas páginas desfasadas en el disco, se reduce el número de páginas que han cambiado debido de transacciones confirmadas pero cuyas imágenes no están en el disco. A su vez, esto, reduce el número de páginas que necesitan tener recuperación REDO aplicará durante la recuperación de errores.

El registro de transacciones

Recuperación de errores sólo es posible si el registro de transacciones está intacto. De hecho, el registro de transacciones es la parte más importante de la base de datos, es el único lugar donde todos los cambios a la base de datos se garantiza que se describe en el del caso de un bloqueo.

Si el registro de transacciones falta o está dañada después de un bloqueo, a continuación, recuperación de errores no se puede completar, lleve a una base de datos sospechoso. En ese caso, la base de datos debe restaurarse desde copias de seguridad o recupera utilizando menos deseables opciones, tales como la reparación de emergencia modo. (Estos procedimientos quedan fuera del alcance de este artículo, pero se tratarán en profundidad en artículos más adelante en el año.)

El registro de transacciones es un archivo especial que debe tener cada base de datos para que funcione correctamente. Contiene los registros que se generan desde el registro y se utiliza para leerlos nuevo durante recuperación (o en cualquiera de los otros usos de registro que ya he mencionado). Así como el espacio ocupado por los registros a sí mismos, una transacción también reservar espacio en el registro de transacciones para los registros posibles necesario si la transacción se cancelarse y necesarios para volver. Este cuentas para el comportamiento se puede observar dónde, decir que, una transacción que se actualiza 50 MB de datos de la base de datos es posible que requieren en realidad 100 MB de espacio de registro de transacciones.

Cuando se crea una nueva base de datos, el registro de transacciones es esencialmente vacío. Cuando se producen las transacciones, registros se escriben secuencialmente en el registro de transacciones, lo que significa no hay ninguna ganancia de rendimiento procedente de crear transacción varios archivos de registro, una equivocación muy común. El registro de transacciones utilizará cada archivo de registro a su vez.

Registros para transacciones simultáneas pueden ser intercalados en el registro de transacciones. Recuerde que registros de una sola transacción están vinculados mediante sus LSNs, por lo no es necesario para todos los registros de registro para una transacción en agrupados juntos en el registro. LSNs puede casi considerarse como una marca de fecha y hora.

La arquitectura física del registro de transacciones se muestra en la figura 1 . Se divide internamente en fragmentos más pequeños denominadas archivos de registro virtuales (o VLFs). Estos son simplemente una ayuda para más fácil administración interna del registro de transacciones. Cuando se llena un VLF, automáticamente la sesión continúa para usar la siguiente VLF en el registro de transacciones. Se podría pensar que, finalmente, el registro de transacciones se quede sin espacio, pero esto es donde el registro de transacciones es por lo que diferente de los archivos de datos.

Figura 1 arquitectura física de la transacción de la sesión

El registro de transacciones es en realidad un archivo circular, siempre y cuando los registros al principio del registro de transacciones han se ha truncado (o desactivada). A continuación, cuando el registro alcanza el final del registro de transacciones, se ajusta al principio vuelva a y comienza a sobrescribir lo que estaba presente antes.

¿Cómo registros obtener truncados por lo que se puede reutilizar el espacio que ocupa? Un registro ya no es necesario en el registro de transacciones si todas de los siguientes son verdaderas:

• Se confirma la transacción que forma parte.
• Las páginas de base de datos es que se ha cambiado han todos escritas en el disco por un punto de control.
• El registro no es necesario para una copia de seguridad (completa, diferencial o registro).
• El registro no es necesario para cualquier característica que lee el registro (como la creación de reflejos de bases de datos o la replicación).

Un registro que aún se necesita se denomina activo, y un VLF que tiene al menos un registro de registro activo también se denomina activo. Cada tan a menudo, el registro de transacciones se comprueba para ver si todos los registros de registro de un VLF completa están activos o no; si son todo inactivos, el VLF está marcado como truncado (lo que significa que se puede sobrescribir la VLF una vez que se ajusta el registro de transacciones). Cuando un VLF se trunca, se no es sobrescribir o llena con ceros de ninguna manera, sólo se marca como truncará y, a continuación, se puede volver a utilizar.

Este proceso se denomina truncamiento del registro, no a se debe confundir con realidad reducir el tamaño del registro de transacciones de. Truncamiento de registro nunca cambia el tamaño físico del registro de transacciones, sólo qué partes del registro de transacciones están activas o no. Figura 2 muestra el registro de transacciones de Figura 1 una vez que haya ocurrido truncamiento.

La Figura 2 la transacción iniciar después de truncamiento del registro

Activo VLFs forman el registro lógico, la parte del registro de transacciones que contiene todos los registros de registro activo. La propia base de datos sabe donde debería empezar leer registros en la parte activa del registro de recuperación de bloqueo, el inicio de la transacción activa más antigua en el registro, el MinLSN (se almacena en la página de inicio de la base de datos).

Recuperación de errores no sabe dónde dejar de leer registros, por lo que continúa hasta que alcanza una sección cero del registro de transacciones (si aún no ha ajustado el registro de transacciones) o un registro cuyos bits de paridad no encajan la secuencia del registro registro anterior.

Medida VLFs se trunca y nuevos se activan, el registro lógico se mueve en el archivo de registro transacciones físicas y, finalmente, debe ajustarse alrededor al principio de nuevo, tal como se muestra en La figura 3 .

La figura 3 la naturaleza circular del registro de transacciones

La comprobación de si truncamiento del registro puede tener lugar en cualquiera de las siguientes circunstancias:

• Se cuando un punto de control produce en el modelo de recuperación SIMPLE o en otros modelos de recuperación cuando nunca se ha tomado una copia de seguridad completa. (Esto implica que una base de datos permanecerán en un modelo de recuperación pseudo-SIMPLE después de que se cambia de SIMPLE hasta que se produzca una copia de seguridad completa de la base de datos).
• Cuando finaliza una copia de seguridad del registro.

Recuerde que truncamiento del registro no puede ser posible debido de muchas razones que un registro debe permanecer activo. Cuando truncamiento del registro no se puede realizar, no se trunca los VLFs y, finalmente, el registro de transacciones crecer (o agregar otro archivo de registro de transacciones). Crecimiento de registro de transacciones excesivo puede provocar problemas de rendimiento a través de un fenómeno que se conoce como fragmentación VLF. Quitar la fragmentación de VLF a veces, puede llevar a una mejora importante en el rendimiento de las actividades relacionadas con inicio de sesión.

Para más información sobre esto, vea blog Kimberly Tripp posterior" Los pasos 8 para mejores el rendimiento de registro de transacciones." Kimberly describe las prácticas recomendadas relativas a transacciones registro capacidad de planeamiento, administración, mejoras y rendimiento, merece la pena también leer!

Hay dos problemas comunes que pueden impedir que truncamiento del registro:

• Una transacción activa de larga ejecución. El registro de toda transacción ya que nunca se puede truncar el primer registro de la transacción activa más antigua hasta esa transacción confirma o anula.
• Cambia al modelo de recuperación FULL, realizar una copia de seguridad completa y, a continuación, nunca tomar cualquier registro copias de seguridad. El registro de transacciones todo permanecerá activo, esperando para realizar copias de seguridad en una copia de seguridad del registro.

Para obtener una lista completa de factores y las instrucciones sobre cómo determinar lo que está impidiendo el truncamiento del registro, vea el tema de Libros en pantalla de SQL Server" Factores que pueden retrasar truncamiento del registro." También he creado una demostración de vídeo que muestra el efecto de crecimiento de registro de transacciones no controlado y cómo quitar la fragmentación de VLF, desproteger este vídeo screencast (y anteriores screencasts sobre temas SQL) en technetmagazine.com/videos.

Si el registro de transacciones aumentan al capacidad y no puede crecer cualquier aún más, a continuación, se informará error 9002 y tendrá tomar medidas para proporcionar más espacio, por ejemplo, aumentar el archivo de registro, agregar otro archivo de registro o quitar cualquier impediment en el registro se truncará.

Bajo ninguna circunstancia debe eliminar el registro de transacciones, intentar volver a generar mediante comandos sin documentar o simplemente truncar utilizando las opciones de registro de copia de seguridad NO_LOG o TRUNCATE_ONLY (que se han quitado de SQL Server 2008). Estas opciones se bien se causar incoherencias de transacciones (y daños más probable) ni se quitarán la posibilidad de poder recuperar correctamente la base de datos.

Para obtener más información acerca de cómo solucionar problemas de un registro de transacción completa, consulte el tema de libros en línea" Solucionar problemas de un registro de transacciones completo (error 9002)."

Modelos de recuperación

Como puede ver, el comportamiento del registro de transacciones depende en parte en la base de datos está utilizando el modelo de recuperación. Existen tres modelos de recuperación, y todos tienen un efecto en comportamiento de registro de transacciones o cómo se registran las operaciones o ambos.

El modelo de recuperación FULL significa que cada parte de cada operación se registra, que se denomina totalmente se ha iniciado. Una vez que ha tomado una copia de seguridad completa de la base de datos en el modelo de recuperación FULL, el registro de transacciones no automáticamente truncará hasta que se realiza una copia de seguridad del registro. Si no desea hacer uso de las copias de seguridad del registro y la capacidad de recuperar una base de datos a un punto específico en tiempo, no utilice el modelo de recuperación FULL. Sin embargo, si desea utilizar la creación de reflejos de base de datos, a continuación, no tiene ninguna opción, que sólo sea compatible con el modelo de recuperación FULL.

El modelo de recuperación BULK_LOGGED tiene la misma semántica de transacción registro truncamiento modelo de recuperación FULL pero permite algunas operaciones que se va a parcialmente registrar, que se denomina mínimamente está registrando. Algunos ejemplos son una reconstrucción de índices y algunas operaciones de carga masiva, en el modelo de recuperación FULL se registra toda la operación.

Pero en el modelo de recuperación BULK_LOGGED sólo la asignación los cambios se registran, que reduce drásticamente el número de registros generados y, a su vez, reduce la posibilidad de crecimiento de registro de transacciones. Para obtener más información sobre operaciones mínimamente conectadas, vea la sección los libros en pantalla" Las operaciones que ha pueden ser mínimamente iniciadas."

Por último, el modelo de recuperación SIMPLE realmente tiene el mismo comportamiento de registro que la recuperación BULK_LOGGED, pero la semántica de truncamiento del registro de transacciones es bastante diferente. Las copias de seguridad del registro no son posibles en el modelo de recuperación SIMPLE, lo que significa que el registro se puede truncar (siempre y cuando nada más mantiene registros activos) cuando se produce un punto de control. Hay ventajas y desventajas a cada uno de estos modelos de recuperación en términos de las copias de seguridad que son posibles (o necesarios) y la posibilidad de recuperar en distintos puntos en el tiempo (trataré esto en otro artículo más adelante este año).

Ajustar hacia arriba

En este artículo ha sido realmente una explicación más académico de cómo funciona una parte crítica de SQL Server. Espero que ha administrado borrar hasta las equivocaciones es posible que haya tenido. Si se trata de la primera Introducción al registro y recuperación, estos se los puntos claves que me gustaría que realice fuera de este artículo:

• No cree varios archivos de registro, que no se producirán un aumento del rendimiento.
• Tener en cuenta el modelo de recuperación está utilizando la base de datos y el efecto tiene sobre el registro de transacciones, especialmente alrededor si puede automáticamente truncar o no cuando se producirá un punto de control.
• Tener en cuenta la posibilidad de crecimiento de registro de transacciones, los factores que pueden conducir a él y cómo conseguir bajo el control.
• Saber dónde buscar ayuda para solucionar un registro de transacción completa.

En mi blog, tengo mucha más información sobre el registro de transacciones y factores que afectan a él, ver mi categoría de entrada de blog " Registro de transacciones"para obtener más detalles. Los diversos temas los libros en pantalla sobre el registro de transacciones también son muy buenos, comenzando por Administración de registros de transacciones.

Como siempre, si tiene preguntas o comentarios, por favor, coloque me una línea en Paul@SQLskills.com.

Gracias a l. Kimberly Tripp para proporcionar una revisión técnica de este artículo.

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, 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.