SQL Q & A: Sin ningún seguimiento
Los procesos como las copias de seguridad y restauración y la comprobación de coherencia pueden provocar comportamientos inesperados, pero tienen sentido.
Paul S. Randal
El rigor de la restauración
P. Estoy trabajando los requisitos de tiempo de inactividad para algunas de nuestras instancias de SQL Server como parte de la planificación de recuperación ante desastres. ¿Es suficiente considerar sólo el tiempo necesario para restaurar copias de seguridad?
**R.**No, hay algunas otras cosas que debe considerar. En primer lugar, tener en cuenta el tiempo total necesario para restaurar todas las copias de seguridad necesarias. Que incluye su copia de seguridad completa más reciente, la copia de seguridad diferencial más reciente y todas las copias de seguridad de registro de transacciones. Piense siempre que el peor de los casos — donde se destruye la base de datos antes de tomar la siguiente copia de seguridad completa, por lo que tiene el mayor número posible de copias de seguridad.
A continuación, considere el tiempo adicional que se tomará para restaurar la copia de seguridad completa inicial para crear archivos de registro de datos y transacciones si ya no existen. Si has habilitado la inicialización instantánea de archivos, archivos de datos se creará casi instantáneamente. Sin embargo, el archivo de registro de transacción, debe ser inicializado a cero.
Si usted tiene un archivo de gran tamaño que es más de cientos de gigabytes, una restauración podría durar varias horas. Si luego tienes que restaurar una copia de seguridad diferencial, que será completamente nuevo cero-inicializar el archivo de registro de transacciones. Tendrá en cuenta esta vez. Si hay cualquier transacción adicional de archivos de registro que fueron temporalmente añadido (pero no eliminado) tendrás que cero-¡ inicializar estas así — potencialmente dos veces.
La última fase del proceso de restauración de base de datos es realizar una recuperación de fallos. El tiempo necesario para ello dependerá de cuántos registros de transacciones es necesario revertir. Son parte de las transacciones no confirmadas en el momento de la copia de seguridad de registro final. Si tienes transacciones de ejecución larga en su base de datos, asuma siempre lo peor. Asumir que tendrás que hacer retroceder casi todas las transacciones más larga posible. Necesita agregar ese tiempo a la ecuación.
Finalmente, también considerar cuánto tiempo tarda el servidor físico para llegar al punto donde puede empezar a restaurar copias de seguridad. En otras palabras, ¿cuánto tiempo tarda el servidor de arranque (corriente POST, controles de memoria y así sucesivamente) y arrancar Windows? Esto también se puede añadir a la inactividad.
Si tenemos en cuenta todas estas cosas en su peor de los casos, que le dará un tiempo máximo de inactividad posible. Se sorprenderá cuando usted agrega todo.
No interrumpas
P. Recientemente me encontré con un interesante problema. He intentado interrumpir un proceso de DBCC CHECKDB que estaba teniendo más de lo habitual. Encontré no podía interrumpirla y tuvo que esperar mucho tiempo terminar el proceso. ¿Puede explicar lo que estaba sucediendo?
**R.**Este comportamiento se espera, pero no es intuitivo en todo. Cuando se inicia el DBCC CHECKDB, crea una instantánea de base de datos ocultos. La instantánea de la base de datos está obligada a proporcionar DBCC CHECKDB con una vista transaccionalmente consistente y que no cambian de la base de datos. De esa manera, DBCC CHECKDB sabe que está comprobando la consistencia de una base de datos estática que no debería tener corrupciones.
El proceso crea una instantánea de base de datos de puntos de control primero la base de datos. A continuación, se crea la instantánea de la base de datos vacía y utiliza el registro de transacciones de la base de datos para ejecutar la recuperación de fallos en la instantánea de la base de datos. En otras palabras, deshace cualquier transacciones activas en la instantánea de la base de datos sin afectar realmente la base de datos real. La instantánea de la base de datos se convierte así consistente transaccionalmente.
El tiempo que tarda en ejecutar recuperación, mientras que la creación de la instantánea de la base de datos es proporcional a la cantidad y duración de las transacciones no confirmadas en la base de datos al iniciar la instantánea de la base de datos. Si hay una transacción de ejecución larga, puede tardar mucho tiempo en volver. Esto significa la creación de la instantánea de la base de datos y el proceso de DBCC CHECKDB tardará más tiempo.
En casos extremos, cuando la creación de la instantánea de la base de datos requiere mucho más de lo normal y decide matar el proceso de DBCC CHECKDB, nada sucederá inmediatamente. Tienes que esperar para que la recuperación de fallos de instantánea de base de datos completar antes de que el proceso responde a la señal de matar. Usted no puede interrumpir la recuperación de fallos, y no hay distinción en el código de recuperación de accidente en SQL Server entre real recuperación después de un cierre inesperado y una recuperación de fallos para una instantánea de base de datos.
La única alternativa en este caso es reiniciar la instancia de SQL Server, que eliminará la instantánea de la base de datos ocultos. Esto no funciona en el caso de una recuperación real de base de datos normal. En esos casos, recuperaciones continuará después de reiniciar una instancia.
Hay varias maneras que usted puede evitar esta situación. Intente sólo ejecutar DBCC CHECKDB cuando sabes que no hay ninguna transacción de ejecución larga en la base de datos. Tiene que tener estos laminados como parte de la creación de la instantánea de la base de datos ocultos de DBCC CHECKDB. También se puede utilizar un mecanismo de verificación de la consistencia, que es para restaurar la base de datos a otro servidor y, a continuación, la copia restaurada de la comprobación de coherencia. Esto evita la posibilidad de transacciones de larga duración en total.
Encontrar el momento adecuado
P. La semana pasada tuve que restaurar copias de seguridad para salvar una mesa alguien había caído accidentalmente. La traza de predeterminado ya había perdido la información sobre cuando se cayó la tabla, por lo que era un proceso tedioso para encontrar la posición de copia de seguridad a la que necesitaba para restaurar. ¿Hay una manera de encontrar el punto correcto en el tiempo que debo restaurar?
**R.**Cada vez que intenta determinar cuando cayó una tabla, verificar la traza de forma predeterminada. Hace la nota de eventos de lenguaje de definición de datos (DDL). Puedes leer más acerca de la seguimiento predeterminado en libros en pantalla de SQL Server.
El único problema con seguimiento por defecto es que es un tamaño finito. También ha quedado obsoleto en favor de Extended Events en SQL Server 2012. Así que si hay mucha actividad en el servidor, el registro de cuando se cayó la tabla no exista en la traza más.
Eso significa que la única forma de encontrar cuando se cayó la tabla es hacer lo que yo llamo "moviéndose a través del registro de transacciones". Restaurar una copia de la base de datos en un tiempo cuando la tabla se sabe que existen. Luego repetidamente hacer restores de point-in-time mediante las opciones con STOPAT y con modo de espera. Mueva ligeramente hacia adelante en el tiempo cada vez. Cuando encuentre el momento cuando ya no existe la tabla, restaurar la base de datos para justo antes de ese momento y puede recuperar datos de la tabla.
Este proceso es muy tedioso y puede tomar mucho tiempo. Cada vez que se restaure la base de datos usando con espera, todas las transacciones sin confirmar en ese momento se deshacen en un archivo de deshacer. La próxima restauración en el proceso de deshace el deshacer, restaura un poco más y nuevamente deshace las transacciones no confirmadas en el archivo de deshacer. Tendrá que repetir este proceso hasta que encuentre la hora correcta.
Hay una buena manera alternativa para ello. Analizar los registros de las copias de seguridad de registro de transacción para buscar transacciones llamadas DROPOBJ. Hacer esto con una función con valores de tabla indocumentada llamada fn_dump_dblog. Esto se comporta de la misma manera como la fn_dblog más conocida, que vertederos ingresar registros desde un registro de transacciones activas, trabajando contra una copia de seguridad de la base de datos.
Puede utilizar esta función para buscar la transacción que cayó el objeto en el que estás interesado. A continuación, puede utilizar el número de secuencia de registro de la transacción (o LSN) para ejecutar una restauración con STOPBEFOREMARK = ' lsn: < el LSN de la transacción >'. Esto restaurará el registro de transacciones, no incluido, la transacción que cae de la tabla. Hacerlo de esta manera evita que tenga que "pulgada a través del registro," como se describió anteriormente. Puede leer más sobre esta función y su uso en mi blog.
Filtrado de eventos
P. Ahora que se ha depreciado traza de SQL en SQL Server 2012, me gustaría entender más acerca de Extended Events. ¿Puede explicar cómo Extended Events se supone que son más ligeros que traza de SQL?
**R.**La razón principal para el rendimiento diferencial entre los dos mecanismos es cómo se filtran eventos. Al definir una sesión de seguimiento o evento, puede filtrar eventos en ambos casos con varios criterios de evento. Filtrado sobre la actividad de una cierta base de datos es un buen ejemplo de esto.
Con la traza de SQL, se generan eventos todo el tiempo. El consumidor de evento hace el filtrado. Esto significa que SQL Server está cargado con generación de todos los eventos, aunque algunos no consumirse. Este proceso es muy ineficiente.
Con Extended Events, el motor de Extended Events dentro de SQL Server realiza filtrado de eventos. El motor de Extended Events evalúa los predicados especificados cuando se definió el período de sesiones del evento. Esto significa que cuando se activa el evento, trabajo sólo mínimo es necesario reunir datos de evento de base. Esto permite que el motor de eventos evaluar el predicado. Si el predicado se evalúa como false, el evento se descarta inmediatamente. El motor de eventos no realiza ninguna transformación posterior. Esto minimiza la sobrecarga de rendimiento de recopilar eventos cuando se compara con la traza de SQL.
Además, traza de SQL recoge todas las columnas asociadas a un evento y descarta cualquier columna que no es necesario. Eventos extendidos, por el contrario, sólo recoge las columnas y otros datos especificados. Además, Esto minimiza el esfuerzo necesario para desencadenar un evento.
Aunque Extended Events es un mecanismo muy superior para la recogida de datos de resolución de problemas, puede afectar negativamente aún rendimiento de SQL Server si la sesión de eventos no está cuidadosamente construida. Si una sesión de eventos requiere producir una pila de llamadas de T-SQL cada vez que ocurre un suceso muy común (por ejemplo, adquirir un bloqueo o una espera de hilo), obviamente esto afectará el rendimiento.
Con cualquier mecanismo, debe probar la recopilación de eventos antes de poner en producción. Usted necesita asegurar que no se comprometa el rendimiento de la carga de trabajo.
.jpg)
Paul S. Randal es el director gerente de SQLskills.com, un director regional de Microsoft y un MVP de SQL Server. Trabajó en el equipo de motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Escribió DBCC CHECKDB y reparación para SQL Server 2005 y fue responsable por el motor de almacenamiento de la base durante el desarrollo de SQL Server 2008. Randal es un experto en recuperación ante desastres, alta disponibilidad y mantenimiento de base de datos y es un presentador regular en conferencias en todo el mundo. Blogs de él en SQLskills.com/blogs/paul, y usted lo puede encontrar en Twitter en twitter.com/PaulRandal.