Preguntas y respuestas sobre SQL reproducción la tarjeta de índice
Los índices de SQL pueden ser problemáticos, pero si no les quita los ojos de encima y permanece vigilante respecto de cualquier problema, le debieran resultar más fáciles de administrar.
Paul S. Randal
El DBA Accidental
P. Estoy "DBA no oficial" en mi empresa. Se utiliza SQL Server cada vez más y tener instancias de SQL Server surgiendo en toda la compañía y saber que necesitamos un DBA real para ayudarle. Mientras nos estamos contratar a alguien, necesito poder averiguar qué es lo que algunos casos se ejecutan más lentamente. ¿Dispone de las recomendaciones generales para Dónde debo empezar buscando?
**R.**Se trata de una excelente pregunta. Puede ser frustrante tener una instancia de SQL Server que no está realizando bien y no sabe por dónde empezar a buscar la causa. Existen todo tipo de cosas que podrían contribuir a la degradación del rendimiento, por lo que siempre sea más fácil simplemente pida a propio SQL Server.
SQL Server realiza un seguimiento de dos conjuntos de información: estadísticas de E/s y las estadísticas de espera. Estos deberían proporcionarle una idea de dónde reside el problema.
La mayoría de las instalaciones de SQL Server hoy en día son dependiente de E/s (es decir, que su rendimiento está restringido por algo que ver con la lectura y escritura de datos). La ralentización podría ser un subsistema de E/s lento, una red lenta, conectar un SAN con el servidor, no hay memoria suficiente en el servidor que está obligando a SQL Server para intercambiar páginas dentro y fuera de la memoria, la estrategia de indización deficiente o un montón de cosas.
Puede utilizar el sys.dm_io_virtual_file_stats de vista de administración dinámica (DMV) para ver lo que SQL Server sabe acerca del volumen de E/s, detenciones y retrasos para todas las E/s a los archivos de datos y de registro. Es posible que el propio subsistema de E/s no es la zona activa, pero E/s aún podría ser el problema. El subsistema de E/s se puede copiar inadecuada con la carga de E/s.
Esto es donde entra en juego la otra parte del rompecabezas: estadísticas de espera. SQL Server realiza un seguimiento de cada vez que un subproceso de ejecución tiene que esperar un recurso disponible y cuánto debía esperar el subproceso. También puede averiguar el tiempo en que el subproceso se tuvieron que esperar después de habérsele notificado de la disponibilidad del recurso, pero antes de poder ejecutar en una CPU. Agregando estos datos, es fácil ver las principales áreas causando esperas para SQL Server. Esto le proporciona un puntero de dónde comenzar a buscar la causa.
Se trata de una visión general de esta metodología. Para obtener una explicación más detallada, incluyendo una secuencia de comandos que puede usar, lea mi blog del sistema "Estadísticas de espera.” También dispone de los resultados de una encuesta de lector de más de 1.800 instancias de SQL Server y los tipos de espera muy extendido con explicaciones. Conclusión: no pierda tiempo poking alrededor en SQL Server hasta que haya más frecuentes SQL Server lo que considere acerca del problema.
Análisis de índices que faltan
P. Sólo he descubierto falta índice (DMV). Ahora que me están diciendo tengo cientos de falta de índices en una instancia de SQL Server. ¿Qué simplemente crear todos ellos, o va a causar problemas?
**R.**No cree inmediatamente todos los índices sin realizar primero algunos análisis. El procesador de consultas de SQL Server 2005 y versiones posteriores puede determinar cuándo un índice beneficiaría el plan para una consulta (o por lotes o procedimiento almacenado). Esto consigue al compilar el plan de consulta.
Cada vez que determina que existe un índice perdido, notas de este hecho. También mantiene recuento del número de veces que cada índice que faltan se han utilizado, junto con la mejora prevista en el plan de consulta hubiera existido de dicho índice en el momento en que se compiló el plan de consulta.
Puede tener acceso a toda esta información mediante tres DMV (en sys.dm_db_missing_index_group_stats y sys.dm_db_missing_index_groups, sys.dm_db_missing_index_details). También hay una DMV que le indica qué columnas de una tabla están perdiendo índices (sys.dm_db_missing_index_columns). Las tres primeras DMV son más comunes. Realizar consultas de la forma más sencilla de obtener esos datos. Jesús Escolar ampliamente utilizado, secuencia de comandos"¿Utilizas DMV de índice de falta de SQL?” También puede ayudar.
Se trata de información valiosa, pero debe tomar con un grano de sal. En primer lugar, hay un posible error en el índice perdido DMV. Puede informarle a falta de un índice que existe realmente. Este error se corregirá en la próxima versión de SQL Server. Puede leer más acerca de él en mi entrada de blog, "Error de DMV índice falta que podría costarle su validez..”
En segundo lugar, el mecanismo que determina un índice perdido en el procesador de consultas sólo tiene en cuenta si un índice es útil para la consulta que se está compilaba. No tener en cuenta el impacto de rendimiento posible para las operaciones insert, update o delete que tienen que mantener dicho índice. Esto puede ser enorme si la tabla tiene proporcionalmente muchos más cambios que se lee. No considera el tamaño del índice creado. Que es un equilibrio que sólo usted puede hacer.
Por último, busca el mejor índice absoluto ayudar a que se está compilando el plan de consulta. Por ejemplo, puede haber una tabla con columnas de 30 y un índice agrupado y una consulta que solicita el 25 de las columnas de tabla. El mecanismo de determinación de índice que faltan recomendaría para crear un índice no agrupado para cubrir la consulta de la columna de 25. En la mayoría de los casos que no tendría sentido.
Utilice secuencias de comandos de Duncan para examinar el resultado de la falta de índices agregados. A continuación, busque en los índices de 10 o 20 superiores y realizar algunos análisis para determinar si son realmente vale la pena crear. La mayor parte del tiempo, encontrará algunas que no vale la pena crear, por lo que siempre vale la pena realizar este análisis.
¿No podemos llevarnos a lo largo de?
P. Soy uno de un grupo de DBA en nuestra empresa que se ocupa de distintos equipos de desarrollo de aplicaciones. No hay animosity constante entre los equipos. Resulta perjudicial para el entorno de trabajo. ¿Tiene alguna idea acerca de cómo suavizar las relaciones entre los equipos?
**R.**Se trata de un problema común al que puede hacer que un entorno de trabajo desagradables con animosity, desconfianza y grudges. Ninguno de los ayuda a la productividad y la compañía se ve afectada. Afortunadamente, hay una solución. Es fácil describir, pero es más difícil de poner en práctica:
- Es necesario educar a entre sí. Cada grupo debe comprender lo que piensan que son sus límites de responsabilidad y motivaciones del otro equipo. Se sorprenderá de lo que cada equipo piensa que debería hacer el otro equipo.
- Cada grupo debe comprender los pain points para los otros equipos. Puede hacerlo de forma anónima, sin hacer cosas personales.
- A continuación, cada equipo debe educar a los otros equipos en cómo afecta el trabajo que se realiza de los otros equipos a ellos. Por ejemplo, digamos la dev team escribe algún código, sólo se comprueba con un pequeño conjunto de datos y, a continuación, produce a través de la pared en producción--y se produce un error increíble. Si el equipo de desarrollo espera el equipo de administradores para solucionar y corregir el código, es claramente un proceso roto.
Reconocer y comprender el problema es la única forma de motivar a ambos lados para trabajar hacia una solución que harán que el entorno de trabajo productivo y pacífica nuevo.
Impulsados indización
P. Soy un administrador de SharePoint y una cantidad razonable sobre SQL Server también se puede saber. El equipo con SQL Server 2008 que aloja nuestras bases de datos de SharePoint tiene mucha de la fragmentación del índice. Esto afecta al rendimiento de SharePoint. ¿Sé no se puede cambiar los índices, pero algo que puedo hacer además constantemente tiene que volver a generarlos?
**R.**Constantemente volver a generar índices supone una gran carga en SQL Server en términos de E/s y CPU recursos, generación de registro de transacciones y potencialmente bloquean otros procesos. Incluso ejecutando la DMV para determinar los índices fragmentados sys.dm_db_index_physical_stats puede suponer una pesada de recursos.
Muchos de los índices se fragmentan en un entorno de SharePoint porque las claves de índice había agrupado de uso de esquema de base de datos de SharePoint GUID. Mi esposa, Kimberly trata este tema de su entrada de blog "GUID como claves principales o la clave de agrupación.”
Cuando un índice tiene lo que es esencialmente una clave aleatoria, inserciones de índice se producen al azar y conducen a un proceso denominado divisiones de página. Una fragmentación de causas de división de página, lo cual es costoso proceso (consulte mi blog "¿El costo está página se divide en términos de registro de transacciones?”). Una división de página ocurre cuando una página está completamente llena, pero se requiere espacio en la página (por ejemplo, cuando una instrucción insert ocurre en un índice con un valor de clave aleatorio que se debe almacenar en esa página). Se asigna una nueva página y, a aproximadamente la mitad de los registros de la página completa se mueven a la nueva página, por lo que crea espacio libre. Es el proceso básico.
No se puede modificar los índices de una base de datos de SharePoint, como que interrumpiría el acuerdo de soporte. Sin embargo, puede cambiar su factor de relleno predeterminado. Al crear o volver a generar un índice, puede indicar a SQL Server para dejar una determinada cantidad de espacio libre en las páginas de índice para permitir inserciones aleatorias. Esto significa que es más probable que las páginas de índice ya tienen espacio en ellos para los nuevos registros sin necesidad de una división de página costosos. Establecer un factor de relleno de 80 significa que las páginas se rellenará en capacidad de 80 por ciento cuando se vuelve a generar el índice, dejando espacio libre del 20 por ciento.
A continuación, la pregunta es: "¿Cuál es el factor de relleno mejor?" Por desgracia, no hay ninguna respuesta válida. Para un almacén de datos que no cambian los datos y no hay ninguna actividad de inserción de transacciones en línea (OLTP) de procesamiento, el factor de relleno mejor suele ser el valor predeterminado de SQL Server de 100 (es decir, no hay espacio libre).
Para un entorno OLTP, la respuesta depende de la rapidez con la que se produce la fragmentación y con qué frecuencia volver a crearla para eliminar la fragmentación. Es una buena idea comenzar con 70 (30 por ciento de espacio libre) y supervisar la fragmentación para ver si es necesario ajustar hacia arriba o hacia abajo, o mantenimiento de índice más o menos frecuencia.
.jpg)
Paul S. Randal es el director gerente general de SQLskills.com, director regional de Microsoft y MVP de SQL Server. 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 conferencias en todo el mundo. Le blog en SQLskills.com/blogs/paul y puede encontrar en Twitter en twitter.com/PaulRandal.