INF: Optimizar el rendimiento de Microsoft SQL Server

Seleccione idioma Seleccione idioma
Id. de artículo: 110352 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Para optimizar de forma más eficaz el rendimiento de Microsoft SQL Server, debe identificar las áreas que producirán los mayores incrementos del rendimiento en la variedad de situaciones y centrar el análisis en estas áreas. En caso contrario, puede hacer mucho tiempo y esfuerzo en temas que no se puede producir mejoras ajustable.

La mayoría de los casos, la siguiente información no soluciona los problemas de rendimiento lematización de simultaneidad multiusuario. Esto es un tema independiente y complejo que se trata en el documento "Optimización Database Consistency and Concurrency," que se puede encontrar en SQL Server versión 4.2 x "Referencia del programador de C," Apéndice E y también en otros artículos de Knowledge Base. No está en la documentación de la versión 6.0, pero se encuentra en el CD de MSDN (Microsoft Developer Network) en ese título.

En lugar de una discusión teórica, este artículo se centra principalmente en áreas que años de experiencia en el equipo de soporte técnico de Microsoft SQL Server ha mostrado de valor práctico en situaciones del mundo real.

La experiencia demuestra que la mayor ventaja de rendimiento de SQL Server puede obtenerse de las áreas generales de diseño lógico de base de datos, diseño de índice, diseño de consulta y diseño de la aplicación. Por el contrario, a menudo el mayores problemas de rendimiento están causados por deficiencias en estas mismas áreas. Si le preocupa con rendimiento, debe concentrarse en estas áreas en primer lugar, ya pueden mejoras de rendimiento muy grandes a menudo se consigue con una inversión de tiempo relativamente pequeña.

Bien otros nivel del sistema aspectos del rendimiento, como memoria, los búferes de caché, hardware y así sucesivamente, ciertamente candidatos para el estudio, la experiencia muestra que la ganancia de rendimiento procedente de estas áreas a menudo es incremental. SQL Server administra los recursos de hardware disponibles automáticamente, en la mayoría de los casos, reducir la necesidad (y por lo tanto, la ventaja) de optimización amplia mano de nivel del sistema.

Microsoft SQL Server 6.0 proporciona nuevas oportunidades para la capa de plataforma mejoras de rendimiento, con grandes cantidades de memoria, multiprocesamiento simétrico, análisis de datos en paralelo, mejoras del optimizador y creación de bandas en disco. Sin embargo, tan grande como son estas mejoras, están finitos en ámbito. El equipo más rápido puede se enrede con consultas ineficaces o una aplicación mal diseñada. Por lo tanto, incluso con el aumento de rendimiento adicional que permite a SQL Server 6.0, es extremadamente importante optimizar la base de datos, índice, consulta y diseño de la aplicación.

La mayoría de los problemas de rendimiento no pueden resolverse correctamente con sólo un enfoque de lado del servidor. El servidor es, esencialmente, un "títere" del cliente, que controla qué consultas se envían, y, por lo tanto, qué bloqueos se obtuvo publicados. Aunque algunos ajustes es posible en el servidor, resolución de problemas de rendimiento dependerá normalmente confirmar la función principal del cliente que desempeña en el problema y analizar el comportamiento de la aplicación de cliente.

Más información

Los siguientes son algunas sugerencias que, basándose en experimentar, se han producido mejoras de rendimiento significativos:

Normalizar el diseño lógico de base de datos

Una normalización razonable del diseño lógico de base de datos produce el mejor rendimiento. Un mayor número de tablas estrechas es característica de una base de datos normalizado. Un número menor de tablas anchas es característica de una base de datos sin normalizar. Una base de datos muy normalizado está asociado habitualmente con combinaciones relacionales complejas, que pueden perjudicar el rendimiento. Sin embargo, el optimizador de SQL Server es muy eficaz en la selección rápidas y eficaces de combinaciones, siempre y que están disponibles índices eficaces.

Entre las ventajas de la normalización incluyen:
  • Acelera la creación de ordenación y el índice, porque las tablas son más estrechas.
  • Permite más índices agrupados, porque hay más tablas.
  • Los índices tienden a ser más estrecha y más compacta.
  • Menos índices por tabla, ayudando a rendimiento de UPDATE.
  • Menos valores NULL y datos menos redundantes, aumento compactness de base de datos.
  • Reduce el impacto de simultaneidad de diagnósticos DBCC, porque los bloqueos de tabla necesario afectará menos datos.
Con SQL Server, una normalización razonable a menudo ayuda en lugar de rendimiento hurts. A medida que aumenta la normalización, ocurre lo mismo el número y la complejidad de las combinaciones necesarias para recuperar datos. Como norma general, Microsoft sugiere realizar el proceso de normalización a menos que por esta razón muchos las consultas con combinaciones de cuatro vías o mayores.

Si el diseño lógico de base de datos ya está fija y total rediseño no es viable, que es posible normalizar de forma selectiva una tabla grande Si análisis muestra un cuello de botella en esta tabla. Si el acceso a la base de datos se realiza mediante procedimientos almacenados, este cambio de esquema podría llevarse a cabo sin afectar a las aplicaciones. Si no es así, es posible ocultar el cambio al crear una vista similar a una sola tabla.

Utilice el diseño de índices eficaz

A diferencia de muchos sistemas no relacionales, relacionales índices no se consideran parte del diseño lógico de base de datos. Los índices se pueden quitar, agregar y cambiados sin afectar el diseño de esquema o aplicación de base de datos de ninguna manera distinta de rendimiento. Diseño de índices eficaz es primordial para lograr el buen rendimiento de SQL Server. Por estos motivos, no debe dude en experimentar con distintos índices.

El optimizador selecciona confiable el índice más eficaz en la mayoría de los casos. La estrategia general de diseño de índice debe ser proporcionan una buena selección de índices al optimizador y confiar en él para que la decisión correcta. Esto reduce el tiempo de análisis y proporciona buen rendimiento a través de una amplia variedad de situaciones.

Los siguientes son recomendaciones de diseño de índice:
  • Examine la cláusula WHERE de las consultas SQL, ya que es el objetivo principal del optimizador.

    Cada columna enumerada en la cláusula WHERE es una posible candidata para un índice. Si tiene demasiadas consultas para examinar, elija un conjunto representativo o sólo los lentos. Si la herramienta de desarrollo transparente genera código SQL, esto es más difícil. Muchas de estas herramientas permiten el registro de la sintaxis SQL generado en un archivo o la pantalla con fines de depuración. Quizás desee averiguar de proveedor de la herramienta si tal una característica está disponible.
  • Utilizar índices estrechos.

    Los índices estrechos suelen ser más eficaz que los índices de varias columnas, compuestos. Los índices estrechos tienen más filas por página y menos niveles de índice, aumentar el rendimiento.

    El optimizador puede con rapidez y eficacia analizar cientos o incluso miles, de posibilidades de combinación y el índice. Tener un mayor número de índices estrechos proporciona el optimizador con más posibilidades de elegir, que normalmente le ayuda a rendimiento. Tener menos índices de varias columnas, anchos, proporciona el optimizador con menos posibilidades para elegir, que puede perjudicar el rendimiento.

    A menudo es mejor no adoptar una estrategia de enfatizar una consulta totalmente cubierta. Es cierto que si todas las columnas de la cláusula SELECT están cubiertas por un índice no agrupado, el optimizador puede reconocer esta y proporcionar muy buen rendimiento. Sin embargo, esto a menudo da como resultado índices excesivamente extensa y demasiado depende de la posibilidad de que el optimizador utilizará esta estrategia. Normalmente, debe utilizar más numerosos índices estrechos que a menudo proporcionan un mejor rendimiento sobre una amplia gama de consultas.

    No debe tener más índices que son necesarios para lograr un rendimiento de lectura adecuado porque la sobrecarga implicada en actualizar dichos índices. Sin embargo, la mayoría incluso de las operaciones orientadas a actualización requieren leer mucho más que escribir. Por lo tanto, no dude para probar un nuevo índice si piensa le ayudará; se pueden colocar posteriormente siempre.
  • Utilizar índices agrupados.

    Uso apropiado de índices agrupados puede tremendamente aumentar el rendimiento. A menudo acelerado por operaciones incluso UPDATE y DELETE los índices agrupados, ya que estas operaciones requieren mucho lectura. Está permitido un único índice agrupado por tabla, por lo tanto, utilizar este índice de forma inteligente. Las consultas que devuelven muchas filas o las consultas que implican un intervalo de valores, son buenos candidatos para la aceleración de un índice agrupado.

    Ejemplos:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Por el contrario, las columnas de apellidos o MEMBER_NO mencionadas anteriormente probablemente no son buenos candidatos para un índice no agrupado si este tipo de consulta es común. Intente utilizar los índices no agrupados en columnas que se devuelven varias filas.
  • Examine la unicidad de la columna.

    Esto ayuda a decidir qué columna es candidata para un índice agrupado, non-clustered index o ningún índice.

    Ésta es una consulta de ejemplo para examinar la unicidad de columna:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Devuelve el número de valores únicos en la columna. Compare esto al número total de filas de la tabla. En una tabla 10.000 filas, valores únicos 5.000 sería la columna una buena candidata para un índice no agrupado. En la misma tabla 20 valores únicos adaptarlo un índice agrupado. No se deben indizar en todos los tres valores únicos. Estos son sólo ejemplos, no las reglas de disco duros y rápidas. No olvide colocar los índices en las columnas individuales aparecen en las cláusulas WHERE de las consultas.
  • Examine la distribución de datos en columnas indizadas.

    A menudo una consulta de larga ejecución se produce porque se indiza una columna con pocos valores únicos o se realiza una combinación de tal una columna. Esto es un problema fundamental con los datos y la propia consulta y normalmente no se puede resolver sin identificar esta situación. Por ejemplo, una agenda telefónica ordenada alfabéticamente por apellidos no acelerará buscar una persona si todas las personas en la ciudad se llaman sólo "Smith" o "Jones". Junto con la consulta anterior, que proporciona una sola figura de unicidad de columna, puede utilizar una consulta GROUP BY para ver la distribución de datos de los valores claves indizadas. Esto proporciona una imagen de resolución mayor de los datos y una mejor perspectiva para la forma en que el optimizador ve los datos.

    Ésta es una consulta de ejemplo para examinar la distribución de datos de valores de claves indizados, suponiendo una clave de dos columnas en COL1, COL2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Esto devolverá una fila por cada valor de clave, con un recuento de las instancias de cada valor. Para reducir el número de filas devueltas, puede resultar útil excluir algunos con una cláusula HAVING. Por ejemplo, la cláusula
          HAVING COUNT(*) > 1
    
    						
    excluirá todas las filas que tienen una clave única.

    El número de filas devueltas en una consulta también es un factor importante en la selección de índices. El optimizador considera que un índice no agrupado al menos una E/s de página por cada fila devuelta de coste. Esta velocidad rápidamente resulta más eficaz para explorar toda la tabla. Se trata de otra razón para restringir el tamaño del conjunto de resultados o para localizar el resultado grande con un índice agrupado.
No igualar siempre uso de índice con buen rendimiento y viceversa. Si utiliza un índice siempre produjera el mejor rendimiento, trabajo del optimizador sería muy simple: utilice siempre cualquier índice disponible. En realidad, opción incorrecta de la recuperación indizada puede producir rendimiento muy incorrecto. Por lo tanto tarea del optimizador es seleccionar la recuperación indizada donde se mejorar el rendimiento y evitar la recuperación indizada donde se afectar al rendimiento.

Utilice el diseño de consulta eficaz

Algunos tipos de consultas son intrínsecamente recursos. Esto está relacionado con base de datos fundamental y índice problemas comunes para la mayoría de los sistemas de administración de bases de datos relacionales (RDBMS), no específicamente para SQL Server. No son ineficaces, ya que el optimizador implementará las consultas de la forma más eficaz posible. Sin embargo, son recursos y la naturaleza orientada a conjuntos de SQL puede que aparezcan ineficaz. Ningún grado de inteligencia del optimizador puede eliminar el costo de recurso inherente de estas construcciones. Son intrínsecamente costosas cuando se comparan a una consulta más simple. Aunque SQL Server utilizará el plan de acceso óptimo, está limitado por lo que es fundamentalmente posible.

Por ejemplo:
  • Grandes conjuntos de resultados
  • IN, NOT IN O consultas
  • Cláusulas WHERE prácticamente no únicas
  • ! = operadores de comparación (no igual)
  • Determinadas funciones de la columna, como suma
  • Conversiones de expresiones o datos en la cláusula WHERE
  • Variables locales en la cláusula WHERE
  • Vistas complejas con GROUP BY
Diversos factores que exigen el uso de algunas de estas construcciones de consulta. Si el optimizador puede restringir el conjunto antes de aplicar la parte intensiva de recursos de la consulta de resultados, se se disminuye el impacto de estos. Los siguientes son algunos ejemplos.

Intensivo de los recursos:
   SELECT SUM(SALARY) FROM TABLE
				

Menos intensivo de los recursos:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Intensivo de los recursos:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Menos intensivo de los recursos:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

En el primer ejemplo, la operación de suma no puede ser acelerada con un índice. Cada fila debe leerse y suma. Suponiendo que haya un índice en la columna ZIP, el optimizador probablemente utilizará inicialmente restringir el conjunto antes de aplicar la suma de resultados. Esto puede ser mucho más rápido.

En el segundo ejemplo, la variable local no está resuelto hasta el tiempo de ejecución. Sin embargo, el optimizador no puede aplazar la elección del plan de acceso hasta el tiempo de ejecución; debe elegir en tiempo de compilación. Aún en tiempo de compilación, cuando se genera el plan de acceso, el valor de @ VAR no se conoce y, por lo tanto, no puede utilizarse como entrada para la selección de índices.

La técnica ilustrada para mejora implica restringir el conjunto con una cláusula AND de resultados. Como una técnica alternativa, utilice un procedimiento almacenado y pasar el valor de @ VAR como un parámetro al procedimiento almacenado.

En algunos casos es mejor utilizar un grupo de consultas sencillas con tablas temporales para almacenar los resultados intermedios que utilizar una sola consulta muy compleja.

Conjuntos de resultados grandes son costosos en la mayoría de los RDBMS. Debe intentar no devolver un conjunto al cliente para la selección de datos final explorando de resultados grande. Es mucho más eficaz para restringir el tamaño del conjunto de resultados, lo que permite el sistema de base de datos realizar la función para el que se diseñó. Esto también reduce la E/s de red y hace que la aplicación más representables para implementación a través de comunicación remota lenta de vínculos. También mejora relacionadas con la concurrencia rendimiento como la aplicación ajusta hacia arriba a más usuarios.

Utilice el diseño de aplicaciones eficaces

La función que desempeña de diseño de la aplicación en rendimiento de SQL Server no puede estar resaltada. En lugar de imagen del servidor en la función dominante, es más exacta para la imagen del cliente como una entidad de control y el servidor como un títere del cliente. SQL Server es totalmente en el comando del cliente sobre el tipo de consultas, cuándo se envían y cómo se procesan los resultados. Esto a su vez tiene un efecto principal en el tipo y duración de bloqueos, cantidad de carga de E/s y CPU en el servidor y, por lo tanto, si el rendimiento es buena o es incorrecta.

Por este motivo, es importante tomar las decisiones correctas durante la fase de diseño de la aplicación. Sin embargo incluso si se enfrenta a un problema de rendimiento mediante una aplicación "llave en mano" donde los cambios en la aplicación cliente parecen imposible, esto no cambia los factores fundamentales que afectan al rendimiento, concretamente que el cliente desempeña una función dominante y muchos problemas de rendimiento no puede ser resolver sin realizar cambios en el cliente.

Con una aplicación bien diseñada, SQL Server es capaz de admitir miles de usuarios simultáneos. Con una aplicación mal diseñada, incluso la plataforma de servidor más eficaz puede bog hacia abajo con unos pocos usuarios.

Utilizar las siguientes sugerencias para diseñar aplicaciones de cliente proporcionará buen rendimiento de SQL Server:
  • Utilizar conjuntos de resultados pequeños. Recuperando resultados innecesariamente grandes establece (por ejemplo, miles de filas) de exploración en el cliente agrega carga de E/s de CPU y de red, puede limitar la escalabilidad multiusuario y hace que la aplicación menos capaz de uso remoto. Es mejor diseño enviado de la aplicación para pedir al usuario entrada suficiente para que las consultas que generan conjuntos de resultados modesto.

    Las técnicas de diseño de aplicaciones que facilitan este incluyen limitar el uso de comodines al generar consultas, obligatoriedad de determinados campos de entrada y prohibir improvised consultas.
  • Utilice dbcancel() correctamente en las aplicaciones de DB-Library. Todas las aplicaciones deben permitir la cancelación de una consulta en curso. Ninguna aplicación debe forzar al usuario para reiniciar el equipo cliente para cancelar una consulta. No siguiendo este principio puede conducir a problemas de rendimiento que no se pueden resolver. Cuando se utiliza dbcancel(), se debe ejercer cuidado correcto con respecto a nivel de transacción. Para obtener información adicional, consulte en contacto con el siguiente artículo en Microsoft Knowledge Base:
    117143: INF: cuándo y cómo utilizar dbcancel() o sqlcancel()
    Los mismos problemas se aplican a las aplicaciones ODBC, si se utiliza la llamada de sqlcancel() ODBC.
  • Procesar siempre todos los resultados hasta su finalización. No diseñe una aplicación o utilizar una aplicación "llave en mano" que deja de procesar las filas de resultados sin cancelar la consulta. Si lo hace, normalmente provocará rendimiento lento y bloqueo.
  • Implemente siempre un tiempo de espera de consulta. No permitir que se ejecuten indefinidamente las consultas. Hacer que el DB adecuado-Library o llamadas ODBC para establecer un tiempo de espera de consulta. En DB-Library, esto se realiza con la llamada dbsettime() y en ODBC con SQLSetStmtOption().
  • No utilice una herramienta de desarrollo de aplicaciones que no permite el control explícito sobre las instrucciones SQL enviadas al servidor. No utilice una herramienta que genere de forma transparente instrucciones SQL basadas en objetos de nivel superiores, a menos que proporciona características cruciales, como cancelación de la consulta, el tiempo de espera de consulta y control transaccional completo. A menudo no es posible para mantener un buen rendimiento o para resolver un problema de rendimiento si la aplicación todo por sí mismo genera "SQL transparente", porque esto no permite el control explícito sobre transaccional y de bloqueo los problemas que son críticas para la imagen de rendimiento.
  • No combinarse decisiones y transacciones en línea (OLTP) consultas de procesamiento.
  • No diseñe una aplicación o utilizar una aplicación "llave en mano" que obliga al usuario a reiniciar el equipo cliente para cancelar una consulta. Esto puede causar diversos problemas de rendimiento son difíciles de resolver debido de posibles conexiones huérfanas. Para obtener más información, vea el artículo siguiente en Microsoft Knowledge Base:
    137983: cómo solucionar problemas de conexiones huérfanas en SQL Server

Técnicas para analizar despacio

Puede ser tentador resolver un problema de rendimiento únicamente mediante la optimización del rendimiento servidor de nivel del sistema. Por ejemplo, cuánta memoria, el tipo de sistema de archivos, el número y tipo de procesadores y así sucesivamente. La experiencia de soporte técnico de Microsoft SQL Server ha mostrado la mayoría de los problemas de rendimiento no se puede resolver esta forma. Debe nombrar analizando la aplicación, las consultas de la aplicación se envío a la base de datos, e interacción de estas consultas con el esquema de base de datos.

En primer lugar, aísle la consulta o consultas que son lentas. Con frecuencia parece que toda la aplicación es lenta, cuando sólo algunas de las consultas SQL son lentos. Normalmente no es posible resolver un problema de rendimiento sin desglosar el problema y aislar las consultas lentas. Si tiene una herramienta de desarrollo que genera SQL de forma transparente, utilice cualquier modo de depuración de esta herramienta de diagnóstico disponible o para capturar el código SQL generado. En muchos casos están disponibles las características de seguimiento, pero no se pueden documentar abiertamente. Consulte con el técnico para la aplicación determinar si existe una característica de seguimiento para supervisar las instrucciones SQL generadas por la aplicación.

Para herramientas de desarrollo de aplicaciones que utilizan SQL incrustado, esto es mucho más fácil - el SQL es abiertamente visible.

Si la aplicación de herramienta o el usuario final de desarrollo no proporciona una característica de seguimiento, hay varias alternativas:
  • Utilizar el indicador de traza 4032 según las instrucciones en el SQL Server 4.2 x "Guía de solución de problemas" y SQL Server 6.0 "Referencia de Transact-SQL". Esto permitirá la captura de las instrucciones SQL enviadas al servidor en el registro de error SQL.
  • Supervisar las consultas a través de un analizador de red como Microsoft Network Monitor, que forma parte de Systems Management Server.
  • Para las aplicaciones de ODBC, utilice el programa Administrador de ODBC para seleccionar el seguimiento de llamadas ODBC. Consulte la documentación de ODBC para obtener más detalles.
  • Emplee una utilidad de cliente de terceros que intercepta el SQL en las capas de DB-Library o ODBC. Un ejemplo de esto es SQL Inspector de software de lago de azul.
  • Utilice la herramienta análisis de SQLEye proporcionada como un ejemplo en el CD de Microsoft TechNet. Nota: SQLEye no es compatible con soporte técnico de Microsoft.
Después de la consulta lenta está aislada, hacer lo siguiente:
  • Ejecutar la consulta lenta sospechosa en aislamiento, mediante una herramienta de consulta, como ISQL y compruebe que es lento. A menudo es mejor ejecutar la consulta en el propio equipo servidor utilizando ISQL y canalizaciones locales y redirigir la salida a un archivo. Esto ayuda a eliminar complicating factores, como resultado el búfer de aplicación, red y E/s de la pantalla.
  • Utilice SET STATISTICS IO ON para examinar la E/s consumida por la consulta. Observe el número de páginas lógicas de E/s. Objetivo del optimizador es minimizar el recuento de E/s. Realizar un registro del recuento de E/s lógico. Esto constituye una referencia con respecto al cual a medir la mejora. A menudo resulta más eficaz para centrarse exclusivamente en la salida de STATISTICS IO y experimentar con diferente consulta indizar tipos que utilizar SET SHOWPLAN ON. Interpretar y aplicar eficazmente la salida de SHOWPLAN pueden requerir algunos estudiar y pueden consumir el tiempo que puede gastarse más eficaz en las pruebas empírica. Si no se corrige el problema de rendimiento por estas recomendaciones simples, puede utilizar SHOWPLAN para investigar más minuciosamente el comportamiento de optimizador.
  • Si la consulta implica una vista o procedimiento almacenado, extraiga la consulta desde la vista o procedimiento almacenado y ejecutar por separado. Esto permite que el plan de acceso para cambiar como experimentar con distintos índices. También ayuda a localizar el problema en la propia, consulta frente a cómo el optimizador trata las vistas o procedimientos almacenados. Si el problema no está en la consulta propia, pero sólo cuando se ejecute la consulta como parte de una vista o procedimiento almacenado, ejecutar la consulta por sí solo ayudará a determinar esto.
  • Tenga en cuenta posibles desencadenadores en las tablas implicadas que transparente pueden generar E/s mientras se ejecuta el desencadenador. Debe quitar todos los desencadenadores implicados en una consulta lenta. Esto ayuda a determinar si el problema está en la consulta propio desencadenador o vista y, por lo tanto, ayuda a dirigir el foco.
  • Examine los índices de las tablas utilizadas por la consulta lenta. Utilice las técnicas enumeradas anteriormente para determinar si son buenos índices y cámbielas si es necesario. Como un esfuerzo de primero, intente indizar cada columna en la cláusula WHERE. A menudo problemas de rendimiento son causados por simplemente no tener una columna en la cláusula WHERE indizada, o por no tener un índice útil en dicha columna.
  • Mediante las consultas que se ha mencionado anteriormente, examine los unicidad de datos y la distribución para cada columna que se menciona en la cláusula WHERE y especialmente para cada columna indizada. En muchos casos simple inspección de la consulta, tabla, índices y datos mostrará inmediatamente la causa del problema. Por ejemplo, problemas de rendimiento a menudo están causados por tener un índice en una clave con sólo tres o cuatro valores únicos, realizar una combinación en esa columna o devolver un número excesivo de filas al cliente.
  • Según este estudio, haga los cambios necesarios a la aplicación, consulta o índices. Ejecutar la consulta nuevo después de realizar el cambio y observe los cambios en el recuento de E/s.
  • Después de anotar mejora, ejecute la aplicación principal para ver si el rendimiento general es mejor.
Compruebe el programa para el comportamiento de E/s o CPU. A menudo resulta útil determinar si una consulta es E/s o CPU. Esto ayuda a centrar los esfuerzos mejora en el cuello de botella es true. Por ejemplo, si una consulta es la CPU, agregar que más memoria a SQL Server probablemente no mejorará el rendimiento, ya que más memoria mejora sólo la caché de proporción de aciertos, que en este caso, ya es alta.

Cómo examinar el comportamiento de E/s frente a CPU consulta:
  • Utilice a Monitor de rendimiento de Windows NT para inspección E/s frente a la actividad de la CPU. Ver todas las instancias del contador "% tiempo de disco" del disco lógico de objeto. Ver también el "% total de tiempo de procesador" contador del sistema de objeto. Para ver información de rendimiento de disco válido, debe anteriormente activó la configuración de Windows NT DISKPERF emitiendo "diskperf -Y" desde un símbolo del sistema y, a continuación, reiniciar el sistema. Consulte la documentación de Windows para obtener más detalles.
  • Mientras se ejecuta la consulta, si el gráfico de CPU es constantemente alto (por ejemplo, mayor por ciento de 70) y el valor de "% tiempo de disco" es constantemente bajo, esto indica un estado limitado en CPU.
  • Mientras se ejecuta la consulta, si el gráfico de CPU es constantemente bajo (por ejemplo, menor que el 50 por ciento) y "% tiempo de disco" es constantemente alto indica que una E/s enlazado estado.
  • Compare el gráfico de CPU con la información de STATISTICS IO.

Conclusión

SQL Server es capaz de muy alto rendimiento en grandes bases de datos. Esto es especialmente el caso de SQL Server 6.0. Para lograr este potencial de rendimiento, debe utilizar base de datos eficaz, índice, consulta y diseño de la aplicación. Estas áreas son las mejores candidatas para obtener mejora significativa del rendimiento. Intente realizar cada consulta tan eficaz como sea posible, para que cuando la aplicación se escala a más usuarios, la carga multiusuario colectiva es compatible. Estudio del comportamiento de aplicación de cliente, las consultas enviadas por la aplicación y la experimentación con índices mediante las instrucciones de este documento se recomienda. Un enfoque metódico en analizar problemas de rendimiento a menudo dará como resultado una mejora significativa para relativamente poco inversión de tiempo.

Propiedades

Id. de artículo: 110352 - Última revisión: martes, 22 de febrero de 2005 - Versión: 3.1
La información de este artículo se refiere a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palabras clave: 
kbmt kbinfo kbother KB110352 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 110352
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com