Cómo solucionar problemas de rendimiento de consultas ad-Hoc en SQL Server

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

En esta página

Resumen

En este artículo se describe cómo solucionar problemas del rendimiento lento de muchas consultas simultáneas ad-hoc en Microsoft SQL Server. Si no ha determinado el origen exacto de su problema, consulte el artículo siguiente en Microsoft Knowledge Base antes de continuar:
224587Cómo solucionar problemas de rendimiento de la aplicación con SQL Server

Este artículo se supone que ha utilizado 224587 KB para limitar el alcance del problema y que ha capturado un registro del Monitor de rendimiento de Windows NT y que detalle de seguimiento del Analizador de SQL las columnas de contadores, eventos y datos específicas.

Características de los problemas de rendimiento

El problema de rendimiento tiene las siguientes características:
  • Las consultas de ad-hoc corta que normalmente tienen una duración muy breve de resultados en lento rendimiento del sistema global cuando un gran número de usuarios simultáneos ejecutar las consultas.
  • Muy alta o 100 porcentaje CPU.
  • No bloquear asociado durante los períodos de un rendimiento lento.

    Puede buscar rápidamente bloqueo comprobando la columna BLK en el resultado del procedimiento almacenado del sistema sp_who . Si la columna BLK no es cero para un número de proceso del sistema (SPID) de identificadores, hay está bloqueando.
  • En algunas situaciones, se carga en memoria del servidor y puede recibir errores que son similares a los errores siguientes:
    Error: 701, gravedad: 17, estado: 1
    No hay memoria del sistema insuficiente para ejecutar esta consulta.
    -o bien -
    Msg 8645, nivel 17, estado 1, procedimiento, línea 1
    Un tiempo de espera excedido recursos de memoria ejecutar la consulta. Vuelva a ejecutar la consulta.

Mejoras en las compilaciones de consulta

Debido de mejoras de arquitectura del sistema a partir de SQL Server 7.0, específicamente el optimizador de consultas, puede observar una diferencia en uso de recursos del sistema por comparación con versiones anteriores de SQL Server de aplicaciones. En concreto, SQL Server 7.0 puede mostrar un aumento en el uso de CPU o la memoria, pero las versiones anteriores de SQL Server normalmente son disco dependiente de E/S. Estos cambios pueden atribuirse a dos factores:
  • Combinaciones hash y combinación
  • Tiempos de compilación de consulta
Las versiones anteriores de SQL Server se basaban completamente en iteraciones de bucle anidado para realizar combinaciones. Uniones de bucle anidado intrínsecamente utilizan E/S de disco. A partir de SQL Server 7.0, se introdujeron las combinaciones hash y mezcla. Las combinaciones hash y mezcla hacer mucho más en memoria de procesamiento de bucle anidado combinaciones. El resultado lógico de esto es que CPU y uso de memoria es mayor cuando se utilizan estas técnicas de combinación. Para obtener más información acerca de las combinaciones hash y combinación, vea los temas "Descripción uniones de hash" y "Descripción combinaciones de correspondencia" en libros en pantalla de SQL Server 7.0.

Tiempos de compilación de consultas se ven afectados porque el optimizador de consultas tiene más opciones e información disponible que en versiones anteriores de SQL Server, incluidas nuevas técnicas de combinación hash y de mezcla, algoritmos de búsqueda mejorada y estadísticas de columna. Esta información adicional permite que el optimizador de consultas seleccione el método más eficaz para recuperar datos de consulta. Sin embargo, el análisis y consideración de estas nuevas técnicas y la información requiere tiempo de procesamiento. Esta mayor uso de CPU puede causar tiempos de compilación de consultas son más largos que en versiones anteriores de SQL Server.

Para la mayoría de consultas, este aumento de tiempo de compilación se desplaza por una disminución del tiempo de ejecución. El efecto general es que la consulta se ejecuta más rápido que en versiones anteriores de SQL Server. Sin embargo, una excepción, se produce con consultas de tipo OLTP muy pequeñas y sencillas, que tienen pocos tiempos de ejecución. Para estas consultas, el proceso de generar un plan de consulta puede tener un gasto igual o mayor que la ejecución de consultas. Como resultado, puede realizar la consulta ligeramente más lenta que en versiones anteriores de SQL Server. Como la diferencia suele en milisegundos, estos efectos se observado no para una consulta determinada si se ejecuta de forma individual. Sin embargo, es posible que observe que sistema global de CPU es mayor que en versiones anteriores de SQL Server si un número elevado de usuarios es que gran número de consultas ad hoc se ejecuta simultáneamente.

Desarrollar las consultas parametrizadas

SQL Server 7.0 utiliza varias técnicas nuevas, como el almacenamiento en caché las consultas ad hoc y parametrización automática. Sin embargo, las consultas que SQL Server 7.0 automáticamente parametriza están limitados. Utilice los métodos siguientes para asegurarse de que los planes de consulta están parametrizados y se pueden reutilizar más eficaz:
  • marcadores de parámetro El OLE DB y ODBC API permiten parámetros especificarse con un signo de interrogación de cierre cuando los usuarios enviar consultas. Esto puede ser muy útil en cualquier aplicación, especialmente para las aplicaciones de nivel medio que tienen módulos de generación de consulta donde no está disponible mediante procedimientos almacenados. El plan de consulta que se genera para las consultas que tienen marcadores de parámetros puede ser reutilizado por los clientes que ejecutan la misma consulta, incluso si se especifican valores de parámetro diferente. Para obtener más información, vea el tema "Marcadores de parámetros" en línea en los libros de SQL Server 7.0.
  • sp_executesql El procedimiento almacenado sp_executesql llaman el proveedor OLE DB o el controlador ODBC cuando se utilizan marcadores de parámetro en una aplicación. Sin embargo, es posible que también se denomina directamente por la aplicación o en otro procedimiento almacenado para explícitamente parametrizar consultas ad hoc. Esto puede ser muy útil en aplicaciones o archivos por lotes donde en que se utiliza la instrucción EXECUTE para ejecutar instrucciones SQL dinámicas. A diferencia de sp_executesql , la instrucción EXECUTE no permite la parametrización. Esto limita la posibilidad de reutilización de planes de consulta. Para obtener más información, consulte la "sp_executesql (T-SQL)" y "Utilizar sp_executesql" temas en libros en pantalla de SQL Server 7.0.
  • procedimientos almacenados Procedimientos almacenados tener muchas ventajas, incluida la capacidad de parametrizar consultas y reutilizar los planes de ejecución. Para obtener más información, vea los temas "Procedimientos almacenados" y "Programación de procedimientos almacenados" en libros en pantalla de SQL Server 7.0.

Ver los datos de Monitor

Utilizar el registro de monitor para determinar qué recursos del sistema que provocan el cuello de botella. El registro de Monitor puede ofrecerle una visión general del sistema y ayuda a centrar la atención al ver los datos del Analizador de SQL. Revise los datos Monitor desde el momento cuando el rendimiento fue bueno mediante el tiempo que reduce el rendimiento. Determine el contador que se ve afectado por primera vez y, a continuación, determinar cuál de los siguientes problemas es más relevante para su situación:
  • Objeto: proceso
    Contador: procesador
    Instancia: SQL Server
  • Objeto: procesador
    Contador: % tiempo de procesador
    Instancia: Comprobación cada instancia de procesador
  • Objeto: Administrador SQL Server: búfer
    Contador: Búferes disponibles
  • Objeto: Administrador SQL Server: búfer
    Contador: Número de páginas de robo
  • Objeto: Administrador SQL Server: memoria
    Contador: Memoria concede pendiente
  • Objeto: Estadísticas SQL Server: SQL
    Contador: SQL compilaciones por segundo
Si el uso de CPU, compilaciones SQL/seg. y búferes libres contadores son alta, concesiones de memoria pendientes y número de páginas descartadas contadores son bajos, esto indica que la CPU es el cuello de botella. Céntrese en cómo parametrizar y reutilizar planes de consulta para evitar el costo de generación del plan de consulta de forma eficaz y consulte la sección "Grupo de la traza del Analizador SQL por clase de evento" de este artículo. Si los búferes libres y contadores de compilaciones SQL por segundo son bajos y los contadores de número de páginas descartadas y concesiones de memoria pendientes son altos, SQL Server está delimitada de memoria. Centrarse en Buscar consultas donde las combinaciones hash se utilizan y pueden cambiarse para combinaciones de bucle y consulte "Group el Analizador de SQL traza por duración" sección de este artículo. Para obtener más información acerca de estos contadores, utilice el nombre del contador para buscar los libros en pantalla de SQL Server 7.0.

Ver los datos del Analizador de SQL

Cuando la resolución de problemas de rendimiento, son sumamente valioso para ver datos del Analizador de SQL. No es necesario que revisar todos los datos capturan; ser selectivo. Analizador de SQL le ayuda a ver eficazmente los datos capturados. En la ficha Propiedades (en el menú archivo , haga clic en Propiedades ), Analizador de SQL permite limitar los datos que se muestran por quitar columnas de datos o eventos, agrupación o ordenar por columnas de datos y aplicar filtros. Puede buscar el seguimiento de todo o sólo una columna específica para los valores específicos (en el menú Edición , haga clic en Buscar ). También puede guardar los datos del Analizador de SQL a una tabla de SQL Server (en el menú archivo , elija Guardar como y, a continuación, haga clic en Seguimiento tabla ), y ejecutan consultas SQL contra él.

Nota Asegúrese de filtrar únicamente un archivo de traza guardada. Si sigue estos pasos en una traza activa, se arriesga a perder datos que fue capturados que se inició la traza. Guardar una traza activa en un archivo o tabla primero (en el menú archivo , haga clic en Guardar como ) y a continuación, vuelva a abrirlo (en el menú archivo , haga clic en Abrir ) antes de continuar. Cuando se trabaja con un archivo de traza guardada, el filtrado no permanentemente quita los datos; los datos sólo se oculta, no eliminado. Puede agregar y quitar eventos y columnas de datos para centrarse las búsquedas.

También debe centrarse en las áreas donde recibirá el máximo provecho. Los siguientes factores pueden ayudar a aumentar el rendimiento de aplicación pero no necesariamente el mismo grado. Antes de implementar los cambios, determinar la eficacia los cambios pueden ser según los factores siguientes:
  • ¿Con qué frecuencia se ejecuta la consulta
  • Cuánto mejora puede mejorarse la consulta
Por ejemplo, reducir el tiempo ejecución de una consulta única de 1,5 segundos en 1,2 segundos puede no resultar útil si no se ejecuta la consulta con frecuencia durante todo el día. Sin embargo, si la consulta se ejecuta con mucha frecuencia un gran número de usuarios simultáneos, la mejora del rendimiento puede ser muy eficaz. Por el contrario, mejorar una sola consulta de 6 minutos a 3 segundos puede no producir un aumento notable del rendimiento global si se utiliza rara vez. Utilice el agrupamiento y técnicas en el Analizador de SQL y el conocimiento de la aplicación de filtrado para estimar los efectos de una consulta determinada o un procedimiento antes de implementar los cambios. Centrarse en primer lugar los cambios más eficaces y continúe con iteraciones a través de otras consultas y procedimientos hasta llegar a un nivel donde suficientemente ha mejorado el rendimiento.

Después de guardar una traza del Analizador de SQL en un archivo o una tabla, vuelva a abrir la traza del Analizador de SQL y revise el contenido. Para agrupar la traza del Analizador SQL, siga estos pasos:
  • Agrupar la traza del Analizador SQL por duración:
    1. En el menú archivo , haga clic en Propiedades .
    2. Haga clic en la ficha Columnas de datos y, a continuación, en grupos , haga clic en arriba para mover la duración . Haga clic en abajo para quitar todas las demás columnas.
    3. Haga clic en la ficha sucesos y quite todos los eventos excepto SQL:StmtCompleted de TSQL y TSQL RPC: finalización . Esto permite centrarse sólo las consultas que se están ejecutando.
    4. Haga clic en Aceptar .
    Agrupación por duración permite para ver fácilmente el SQL instrucciones, lotes y procedimientos que se ejecutan la más lenta. Revise la traza cuando se está produciendo el problema y crear una línea de base del buen rendimiento. Puede filtrar por hora de comienzo para dividir la traza en secciones cuando rendimiento secciones independientes y buena cuando el rendimiento es deficiente. Busque las consultas con la duración más larga al rendimiento es bueno. Lo más probable es que son la raíz del problema. Cuando se disminuye el rendimiento general del sistema, incluso buenas consultas pueden mostrar duraciones largas porque están esperando recursos del sistema.

    Revise los planes de ejecución para las consultas más frecuentemente que duraciones largas. Si observa que se utiliza una combinación hash, considere el uso la sugerencia de consulta de combinación LOOP para forzar una combinación de bucle anidado de la consulta. Si el tiempo de ejecución de la consulta mediante una combinación de bucle es menor, igual o incluso ligeramente mayor que el tiempo de ejecución con la combinación hash, una combinación de bucle puede ser una mejor opción si el equipo tiene mucha memoria y uso de CPU. Reduciendo la carga en el cuello de botella recursos (CPU y memoria), puede mejorar el rendimiento general del sistema. Para obtener más información acerca de la UNIÓN de LOOP consulta la sugerencia, vea el tema "SELECT (T-SQL)" en libros en pantalla de SQL Server 7.0.
  • Agrupar la traza del Analizador SQL por clase de evento:
    1. En el menú archivo , haga clic en Propiedades .
    2. Haga clic en la ficha Columnas de datos y, a continuación, bajo el encabezado de grupos , haga clic en arriba para mover Event Class y texto con la Clase de evento en la parte superior. Haga clic en abajo para quitar todas las demás columnas bajo el encabezado de grupos .
    3. Haga clic en la ficha sucesos y, a continuación, asegúrese de que se incluyen todos los eventos.
    4. Haga clic en Aceptar .

Tipos de sucesos

Para ver qué tipos de eventos se producen en el equipo que ejecuta SQL Server y con qué frecuencia producirán los eventos, agrupar por la columna Event Class . Buscar en esta columna para los eventos siguientes:
  • MISC: preparar SQL y EXEC preparada SQL; cursor: Cursorprepare Un suceso de Preparar SQL indica que se ha preparado una instrucción SQL para su uso con un conjunto de resultados predeterminada (cursor del lado del cliente) mediante SQLPrepare y SQLExecute (para ODBC) o ICommandText::Prepare/ICommandText:: Execute (para OLE DB) con las opciones de cursor predeterminado: hacia delante, sólo lectura, tamaño del conjunto de filas = 1. Un suceso de Cursorprepare indica que se ha preparado un cursor de servidor en una SQL establece instrucción mediante SQLPrepare y SQLExecute (para ODBC) o ICommandText::Prepare/ICommandText:: Execute (para OLE DB) con una de las opciones de cursor anteriores en un valor de no predeterminada. Un evento de Exec Prepared SQL indica que se ejecutó cualquiera de los tipos de instrucciones preparadas existentes anteriores. Si observa con frecuencia las apariciones de estos eventos, la aplicación utiliza el modelo Preparar/ejecutar cuando se abre resultado conjuntos. Si es así, debe determinar si está utilizando el modelo Preparar/ejecutar correctamente.

    Idealmente, una aplicación prepara una instrucción una vez y ejecuta muchas veces para que el optimizador no sea necesario que compilar un plan de nuevo cada vez que se ejecuta la instrucción. Cada vez que ejecute una instrucción preparada, puede guardar el costo de la compilación de consulta. Si sólo piensa ejecutar una consulta una vez, Microsoft recomienda no prepararlo. Preparar y, a continuación, ejecutar una instrucción SQL requieren tres viajes de ida y vuelta de red: uno para preparar la instrucción, uno para ejecutar la instrucción y otro para la instrucción operación de deshacer la preparación. Preparando cursores de servidor requiere al menos cinco ida: uno para preparar el cursor, uno para ejecutar o abrirlo, uno o más para recuperar de ella, uno para cerrarlo y otro para la operación de deshacer la preparación. Ejecutar la consulta sólo requiere un viaje de ida y vuelta.

    Para ver cómo eficazmente la aplicación utiliza el modelo de preparación y ejecución, comparar el número de veces que estos dos eventos (Preparar y ejecutar) se producen. El número de eventos de Exec Prepared SQL debe ser mucho mayor que el total de Preparar SQL y eventos CursorPrepare (al menos tres a cinco horas de mayores es una buena estimación). Esto indica que instrucciones preparadas se vuelven a que se va a utilizar con la frecuencia suficiente para superar la mayor sobrecarga para crearlos. Si el número de eventos SQL preparar y CursorPrepare es aproximadamente equivalente al número de eventos Exec Prepared SQL , esto puede indicar que la aplicación no está utilizando eficazmente el modelo Preparar/Ejecutar. Intente preparar una instrucción una vez y reutilícelo tanto como sea posible. También puede cambiar la aplicación para preparar instrucciones una vez y reutilizar las instrucciones.

    La aplicación debe escribirse específicamente para utilizar eficazmente el modelo de preparación y ejecución. La duración de un identificador de una instrucción preparada controla cuánto mantiene el HSTMT abierta en el objeto de ICommandText en OLE DB o ODBC. Una práctica común consiste en obtener un HSTMT, preparar una instrucción SQL, ejecutar la instrucción preparada y después liberar el HSTMT, perder, por lo tanto, el identificador en el plan preparado. Si lo hace, no recibe ninguna ventaja del modelo Preparar/Ejecutar. De hecho, puede observar una disminución del rendimiento debido a la sobrecarga adicional de los viajes de ida y vuelta de red de. La aplicación debe tener un método para almacenar en caché el objeto con el identificador de instrucción preparada o HSTMT y tener acceso a ellos para su reutilización. El controlador o el proveedor no hace esto automáticamente; la aplicación es responsable de implementar, mantener y utilizar esta información. Si la aplicación no puede hacerlo, considere el uso marcadores de parámetro en lugar del método Preparar/Ejecutar.
  • utilizar marcadores de parámetro Las aplicaciones pueden utilizar marcadores de parámetros para optimizar el uso de la misma instrucción de Transact-SQL varias veces con entrada diferente y los valores de salida. La primera vez que se ejecuta una consulta, está preparado como una consulta parametrizada y SQL Server genera y almacena en caché un plan para la consulta parametrizado. Para las llamadas posteriores a la misma consulta mediante los mismos o diferentes parámetros, SQL Server no es necesario que generar un nuevo plan de consulta; SQL Server puede reutilizar el plan de consulta existente sustituyendo los parámetros actuales.

    Si la aplicación utiliza marcadores de parámetro con llamadas a SQLExecDirect (para ODBC) o a ICommandText:: Execute (para OLE DB), el controlador o proveedor automáticamente empaqueta la instrucción SQL y se ejecuta como una llamada sp_executesql . La instrucción no es necesario estar preparado y ejecutar por separado. Cuando SQL Server recibe una llamada a sp_executesql , automáticamente comprueba la caché de procedimiento para un plan coincidente y vuelve a utilizar dicho plan o genera un nuevo plan.

    Para determinar si la aplicación actualmente utiliza marcadores de parámetro, puede buscar en la columna de texto en la traza del Analizador de SQL para "sp_executesql." Sin embargo, como sp_executesql pueden llamarse directamente, no todas las instancias indican el uso de marcadores de parámetro.

    Para obtener más información sobre el modelo de preparación y ejecución, vea el tema "Ejecución plan de almacenamiento en caché y reutilizar" en libros en pantalla de SQL Server 7.0. Para obtener más información acerca de los marcadores de parámetros, vea el tema "Marcadores de parámetros" en libros en pantalla de SQL Server 7.0.
  • SP: finalización Instrucciones SQL dinámicas ejecutadas con el comando EXECUTE se muestran como un SP: completado evento con el texto "SQL dinámica". Expanda el SP: finalización evento y, a continuación, busque las repeticiones que tienen "SQL dinámicas" como el texto. Si hay muchos de estos eventos, quizás pueda mejorar el rendimiento de la aplicación utilizando sp_executesql en lugar de la instrucción EXECUTE. El procedimiento almacenado sp_executesql permite que SQL Server para reutilizar los planes de ejecución si la misma consulta se ejecuta de nuevo con distintos parámetros. Cuando se utiliza la instrucción EXECUTE, el plan no tiene parámetros y no se reutiliza a menos que la consulta se ejecuta de nuevo utilizando los mismos parámetros.

    Para determinar el consultas o procedimientos que utilicen eventos dinámicos de SQL con el EXECUTE instrucción, el identificador de conexión de la nota y hora de inicio de para cada evento. Desagrupar la traza (quitar Event Class y texto en el encabezado de grupos ). Una vez desagrupada la traza, se ordena en orden cronológico. Puede filtrar la traza por ID de conexión (en la ficha filtros ) y, a continuación, quitar todas las clases de evento excepto el SP: iniciando y SP: completado eventos para mayor legibilidad. A continuación, puede buscar la hora de inicio del evento (en el menú Edición , haga clic en Buscar ). Los resultados muestran cuando inicia el evento SQL dinámico. Si el evento se produjo en un procedimiento almacenado, el evento aparece entre el SP: iniciando y SP: completado eventos para ese procedimiento. Si el evento no se produce en un procedimiento almacenado, se ejecuta como una consulta ad hoc y puede utilizar las otras columnas de datos ( Nombre de la aplicación , Nombre de usuario de NT y otros) para determinar donde se ejecutó el comando. Para determinar el texto del comando y el contexto donde se ejecutó, también puede agregar clases de evento, como SQL: BatchCompleted y SQL:RPCCompleted .

    Después de determinar dónde se utiliza la instrucción EXECUTE, considere lo sustituye por una llamada a sp_executesql . Por ejemplo, considere el siguiente escenario donde el EXECUTE comando se utiliza con SQL dinámico. Un procedimiento toma un nombre de tabla, ID y idValue como parámetros de entrada y, a continuación, ejecuta una instrucción SELECT de la tabla según el valor del identificador. Mediante una instrucción EXECUTE, el procedimiento es similar al código siguiente:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    suponiendo que la consulta automáticamente no está parametrizada, si ejecuta este procedimiento en la tabla titles de la base de datos de ejemplo pubs dos veces con diferentes valores para el @ idValue parámetro, SQL Server debe generar un plan de consulta independiente para cada ejecución. Por ejemplo:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Nota en este ejemplo, la consulta es bastante sencilla que SQL Server puede parametrizar automáticamente y realmente reutilizar el plan de ejecución. Sin embargo, si esto era una consulta compleja que SQL Server no puede parametrizar automáticamente, SQL Server puede volver a no utilizar el plan para la segunda ejecución si la @ idValue parámetro ha cambiado. La siguiente consulta simple limita la complejidad del ejemplo.

    Puede volver a escribir este procedimiento para utilizar sp_executesql en lugar de la instrucción EXECUTE. Compatibilidad con sustitución de parámetros permite que sp_executesql más eficaz ya que genera planes de ejecución que más suelen ser reutilizada por SQL Server. Por ejemplo:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    en este ejemplo, la primera vez que se ejecuta la instrucción sp_executesql , SQL Server genera un plan parametrizado para la instrucción SELECT de títulos con title_id como el parámetro. Para la segunda ejecución, SQL Server reutiliza el plan con el nuevo valor del parámetro. Para obtener más información acerca de sp_executesql , consulte el "sp_executesql (T-SQL)" y "Utilizar sp_executesql" temas en libros en pantalla de SQL Server 7.0.
  • SP:RECOMPILES Este evento indica que se vuelve a compilar un procedimiento almacenado durante la ejecución. Muchos eventos de volver a compilar indica que SQL Server está utilizando recursos para compilación de consulta en lugar de ejecución de consulta.
Si no ve estos eventos, la aplicación está ejecutando sólo las consultas ad-hoc en SQL Server. A menos que SQL Server determina que puede parametrizar automáticamente determinadas consultas o si se utilizan repetidamente los mismos parámetros, cada consulta que se ejecuta requiere SQL Server generar un nuevo plan de ejecución. Monitor de rendimiento de SQL Server debe mostrar muchos compilaciones de SQL/seg. Puede ser intensivo de la CPU para muchos usuarios simultáneos. Para evitar este problema, busque más frecuentemente ejecutan consultas y considere la creación de procedimientos almacenados para estas consultas con marcadores de parámetros o con sp_executesql .

Referencias

Para obtener más información acerca de cómo supervisar y solucionar problemas de rendimiento en SQL Server, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
224587Cómo solucionar problemas de rendimiento de la aplicación con SQL Server
224453INF: Descripción y resolución de SQL Server 7.0 o problemas de bloqueo de 2000
243586Solucionar problemas de recompilación del procedimiento almacenado
243589Cómo solucionar problemas de ejecución lenta consultas en SQL Server 7.0 o posterior
251004INF: Cómo supervisar el bloqueo de SQL Server 7.0

Propiedades

Id. de artículo: 243588 - Última revisión: jueves, 08 de diciembre de 2005 - Versión: 5.4
La información de este artículo se refiere a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Palabras clave: 
kbmt kbhowtomaster kbhowto kbinfo KB243588 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): 243588

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