Preguntas y respuestas sobre SQL: Datos dinámicos y recuperación de desastres
Soluciones de este mes para el éxito SQL abarca toda la gama de expandir un tempdb y organización en clústeres un acertijo para planes de recuperación ante desastres de half-baked.
Paul S. Randal
Llene el espacio
P. Uno de los servidores de producción que soy responsable tiene un problema. Tempdb crece realmente grande dentro de unos días. Se trata de un problema relativamente nuevo. No veo ninguna diferencia en el número de conexiones al servidor o el uso de memoria. ¿Cómo se puede supervisar la situación para determinar lo que está utilizando todo el espacio de tempdb?
R. Hay muy pocas razones podría aumentar el uso de tempdb:
- Uso del sistema de control de versiones (aislamiento de instantánea o las operaciones de índice, por ejemplo) podría provocar que el almacén de versiones en tempdb para crecer.
- Un plan de consulta se puede cambiar debido a las estadísticas no actualizadas, que a su vez provocaría a un operador de plan de consulta que da como resultado de un desbordamiento de gran tamaño de memoria en tempdb.
- Puede que alguien haya implementado nuevo código de la aplicación que utiliza las tablas temporales a los datos de almacén ha procesado parcialmente.
Tal como esté, hay algunos métodos sencillos para poder localizar lo que está ocurriendo. Lo primero que debe hacer es examinar el uso del espacio de tempdb general con la sys.dm_db_file_space_usage de la vista de administración dinámica (DMV). Si captura los resultados de esta DMV cada 30 segundos, por ejemplo, podrá saber si es el uso de espacio adicional del almacén de versiones, objetos de usuario o de objetos creados para ayudar a procesar una consulta.
Si es el almacén de versiones que ocupa todo el espacio, puede profundizar aún más mediante la sys.dm_tran_top_version_generators DMV. Deberá incorporarse a ella con sys.partitions y sys.indexes para obtener información realmente útil fuera de ella, pero que le permitirá saber qué tablas tienen la mayoría de las versiones que se está generando.
Si se trata de algo else ocupando espacio, se puede desglosar al capturar los resultados de sys.dm_db_task_space_usage con una frecuencia similar. A continuación, unirse a la DMV al sys.dm_exec_requests para averiguar qué conexiones y las consultas están ocupando espacio.
Si resulta para ser un procedimiento almacenado largo, es posible que deba instrumentar el procedimiento para la cantidad de espacio de tempdb que utiliza para que pueda trabajar fuera de las instrucciones dentro del procedimiento son los culpables de salida periódicamente. He tenido que hacer esto varias veces en los sistemas cliente.
Encontrará mucha más información sobre el uso de estas DMV en el white paper, "trabajo con tempdb en SQL Server 2005." (Este documento también se aplica a las versiones posteriores de SQL Server).
Clústeres de buena
P. He recibido para diseñar el esquema de una base de datos que se va a almacenar datos para una nueva aplicación. He leído todos los tipos de recomendaciones sobre la elección de claves de índice agrupado "bueno" para las tablas. ¿Puede explicar lo que hace que una "buena" clave de índice agrupado y por qué es importante mucho?
R. Se trata de una pregunta compleja y casi imposible integral de respuesta aquí. En pocas palabras, una "buena" clave de índice agrupado es aquél que se ha selecciona cuidadosamente para minimizar el espacio desperdiciado y un rendimiento deficiente. Son las cuatro calidades de una clave de índice agrupado buena: estrecho, estático, único y creciente:
- Restringir (ocupando tantos bytes como sea posible): todos los registros de índice no agrupado incluyen la clave de índice agrupado. Es mayor, ocupa la información duplicada más de espacio en los índices no agrupados.
- Estático (que no cambian): los cambios realizados en los valores de clave son costosos. ¿Por qué una actualización de clave como una eliminación de SQL Server + operación de inserción (consulte mi publicación del blog aquí), y siempre que se actualiza una clave de índice agrupado, todas las filas coincidentes en los índices no agrupados también deben actualizarse. Cambios clave también pueden conducir a un espacio vacío en las páginas del archivo de datos si no se utiliza esa clave posición en el índice de nuevo.
- UNIQUE: Esto evita tener que SQL Server agrega una columna oculta de cuatro bytes para "uniquify" los valores de clave duplicados, lo que hace que la clave más ancha.
- Creciente: el patrón de insertar nuevos registros da como resultado inserciones aleatorias en el índice agrupado que puede provocar operaciones costosas de división de páginas. Esto conduce a la fragmentación lógica y el espacio desaprovechado en páginas de archivos de datos.
Haya dado estas cualidades de una clave de índice agrupado buena, a menudo no una clave natural que se ajuste a (por ejemplo, uno derivada de la tabla de datos), por lo que se deba utilizar una clave suplente (por ejemplo, una columna de tabla artificial). Una columna BIGINT IDENTITY es un ejemplo de una clave suplente buena. Leer más explicaciones exhaustivas y justificaciones en la categoría de blog de Kimberly Tripp Clave de la organización por clústeres de.
Preparar los peores escenarios
P. En la activación de las recientes terremotos en Nueva Zelanda y Japón, he examinado nuestro plan de recuperación ante desastres y se ha encontrado que realmente está obsoleta. He sin éxito intentando obtener nuestra empresa para modernizar y probar el plan. Simplemente no piensan que nunca tendremos un desastre. ¿Puede darme algunas sugerencias acerca de cómo llevarlo con la administración?
R. Me alegro de escuchar que analizar proactivamente la estrategia de recuperación (DR) en la activación de estos desastres recientes. Muchas empresas están complaciente y tienen la actitud que describa su pregunta. Aunque las catástrofes a gran escala son relativamente raras, más localizadas problemas como la creación de incendios o interrupciones de energía son relativamente habituales y una empresa no debe asumir que es inmune a errores aleatorios.
Incluso si no se puede obtener la administración de su lado, hay muchas pruebas pueden hacer personalmente, como restaurar copias de bases de datos de copias de seguridad. Esto permite probar su estrategia de copia de seguridad y la integridad de la copia de seguridad y, a continuación, puede asegurarse de que el tiempo de restauración cumple los requisitos de tiempo de inactividad máximo permitido para cualquier base de datos determinada. Muy a menudo, esto es el primer problema encontrado durante la prueba de la estrategia de recuperación ante desastres. Los volúmenes de datos crecen con el tiempo y restauración los aumentos de tiempo de commensurately.
Otras partes de la estrategia de recuperación ante desastres son mucho más difíciles de probar usted mismo, como la conmutación por error una asociación o en un clúster de conmutación por error de creación de reflejo de la base de datos. Ambos requieren algunos downtime de aplicación (tanto para la conmutación por error y conmutación por recuperación).
Medida de lo convence de administración se refiere, pregúnteles si buscaran en su lugar fuera de la estrategia de recuperación ante desastres no funciona durante una prueba planificada con todo el personal disponible para ayudar con la recuperación, o cuando sufre un desastre de real a las 2 a.m. en un día festivo cuando sólo un personal de mínima es de-mano.
Hay una gran cantidad de incidentes desafortunados de empresas sufrir interrupciones debido a que una estrategia de recuperación ante desastres era insuficiente. ¿Está interesado administración de su empresa será la siguiente en las noticias? Que puede parecer melodramatic, pero es un punto razonable.
Recuperación ante desastres es minimizar el costo de la empresa y sus clientes. Si los clientes sufran a causa de una interrupción o pierden la fe de la capacidad de recuperarse rápidamente de la empresa, pueden tardar en otra parte su negocio. Obviamente, esto reduce la línea de la parte inferior de la compañía.
Como expertos en tecnología, debemos preguntar administración pensar de desastres en lo que respecta a las consecuencias financieras de la empresa. He descubierto trata de una táctica eficaz en persuadir administración invertir tiempo y dinero para rediseñar y probar la estrategia de recuperación ante desastres. Obtener más información acerca de esto en mi blog recientes aquí.
Reducción de los costes
P. Realmente le gustaría utilizar la característica de compresión de datos de SQL Server 2008 para reducir nuestros costos de almacenamiento de información, pero he leído es sólo para los almacenes de datos y que podrá incurrir en problemas de rendimiento enorme si se intenta utilizarlo en una transacción en línea (OLTP) sistema de procesamiento. ¿Es cierto?
R. Es correcto que la característica de compresión de datos se diseñó originalmente para el uso del almacén de datos. Compresión de datos, reduce el tamaño de los registros de tablas e índices. Esto significa que caben más registros en una página de archivo de datos de 8 KB, y así menos páginas de archivo de datos se necesitan para almacenar los datos en disco. Esto se traduce en menores requerimientos de espacio de disco para la base de datos que contiene los datos comprimidos, que a su vez pueden dar lugar a considerables ahorros de costos como se requiere menos almacenamiento de clase empresarial.
El equilibrio, por supuesto, es que los datos deben descomprimirse antes de utilizarlo. Los datos no se descomprimen cuando se lee en el grupo de búferes de SQL Server (en memoria caché de las páginas del archivo de datos). Sólo se descomprime cuando es realmente necesaria para satisfacer una consulta. Descompresión utiliza recursos de CPU, por lo que un equilibrio es el uso de espacio frente a los recursos de CPU.
Un almacén de datos típico tiene una gran cantidad de datos (piense en cientos de gigabytes a múltiples terabytes). El modelo de acceso para que los datos es normalmente una gran cantidad de datos que se lee en el grupo de búferes, procesa una vez y, a continuación, no volver a utilizar durante mucho tiempo suficiente a los que ha quedado anticuado memoria en.
Con este modelo de acceso, tiene sentido reducir el número de operaciones de E/s de lectura al comprimir los datos a un tamaño mucho menor. Esto requeriría menos páginas de archivo de datos de SQL Server para almacenarlo y menos operaciones de E/s para leer esas páginas. Normalmente, esto conduce a una finalización más rápida de estos tipos de consultas. Por eso, otro equilibrio es la velocidad de consulta con respecto a los recursos de CPU (para descomprimir los datos).
Si se considera una carga de trabajo OLTP, suele haber mucho mayor volatilidad de los datos que en un almacén de datos. Esto significa que si utiliza la compresión de datos, tendrás que pagar un alto costo de CPU debido a de la descompresión constante de lectura de datos y compresión de datos que se inserta o actualiza. Tendrá que mirar más detenidamente los pros y contras al considerar la compresión de datos para una base de datos OLTP.
Volviendo a la pregunta, aunque la compresión de datos originalmente era dirigida a los almacenes de datos, muchos clientes de SQL Server han descubierto que tienen una gran cantidad de CPU "sala de la cabeza" en sus servidores. Que pueden permitirse el uso adicional de la CPU y los tiempos de ejecución de consultas potencialmente más tiempo para obtener el ahorro de espacio de gran tamaño y el ahorro de costos de almacenamiento de información asociado con el uso de compresión de datos. Compresión de datos puede ser útil para entornos OLTP. Simplemente asegúrese de que evaluar el ahorro de espacio y los costos de rendimiento para su carga de trabajo antes de ponerlos en producción.
Para el ahorro de espacio, puede utilizar el procedimiento sp_estimate_data_compression_savings para darle una idea de los ahorros de porcentaje que se puede esperar. Es importante debido a que al activar (o desactivar) la compresión de datos se realiza mediante una operación de reconstrucción. Esto puede resultar costoso en sí mismo. Para obtener más información, consulte el white paper "compresión de datos: estrategia, planificación de capacidad y mejores prácticas."
.jpg)
**Paul S. Randal**es el director gerente de SQLskills.com, director regional de Microsoft y un servidor de SQL Server MVP. Trabajó en el equipo de motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Escribió DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento de información de núcleo durante el desarrollo de SQL Server 2008. Randal es experto en recuperación ante desastres, alta disponibilidad y mantenimiento de bases de datos, y es moderador habitual en congresos en todo el mundo. Blogs en SQLskills.com/blogs/paul, y se le puede encontrar en Twitter en twitter.com/PaulRandal.