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


Resumen


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


En 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 el analizador de SQL traza ese detalle 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:
  • Consultas ad-hoc corto que normalmente tienen una duración muy corta producen lento rendimiento general del sistema cuando un gran número de usuarios simultáneos ejecuta las consultas.
  • Muy alta o 100 por ciento uso de la CPU.
  • Sin bloqueo asociado durante los períodos de bajo rendimiento.

    Puede buscar rápidamente para bloquear 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 SPID (ID) del proceso del sistema, allí está bloqueando.
  • En algunas situaciones, se subrayó la memoria del servidor y puede recibir errores similares a los siguientes errores:
    Error: 701, gravedad: 17, estado: 1
    No hay memoria de sistema insuficiente para ejecutar esta consulta.
    - o -
    Msg 8645, nivel 17, estado 1, procedimiento, línea 1
    Se ha producido un tiempo de espera mientras se esperaban recursos de memoria ejecutar la consulta. Vuelva a ejecutar la consulta.

Mejoras en las compilaciones de consulta

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

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

Para la mayoría de las consultas, este aumento de tiempo de compilación se compensa con 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, ocurre una excepción, con muy pequeñas y sencillas, tipo OLTP, las consultas que tienen tiempos de ejecución muy bajos. Para estas consultas, el proceso de generar un plan de consulta puede tener un gasto igual o mayor que la ejecución de la consulta. Como resultado, puede realizar la consulta ligeramente más lenta que en versiones anteriores de SQL Server. Dado que la diferencia es normalmente en milisegundos, estos efectos no se notan para una consulta determinada si se ejecuta de forma individual. Sin embargo, puede observar que sistema total de uso de CPU es mayor que en versiones anteriores de SQL Server si el gran número de consultas ad hoc se ejecuta simultáneamente por un gran número de usuarios.

Desarrollar las consultas parametrizadas

SQL Server 7.0 utiliza varias técnicas, como el almacenamiento en caché de las consultas ad-hoc y parametrización automática. Sin embargo, las consultas que SQL Server 7.0 automáticamente parametriza están limitadas. Utilice los métodos siguientes para asegurarse de que los planes de consulta están parametrizados y pueden reutilizarse de forma más eficaz:
  • Marcadores de parámetros Tanto la API OLE DB y ODBC permiten que se especifiquen con un signo de interrogación cuando los usuarios envíen consultas de parámetros. 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 el uso de procedimientos almacenados no está disponible. El plan de consulta que se genera para las consultas que tienen marcadores de parámetros puede ser reutilizado por cualquier cliente que ejecute la misma consulta, incluso si se especifican valores de parámetro diferentes. Para obtener más información, vea el tema "Marcadores de parámetros" en libros en pantalla de SQL Server 7.0.
  • sp_executesql El procedimiento almacenado sp_executesql es llamado por el proveedor de OLE DB o controlador ODBC cuando se utilizan marcadores de parámetro en una aplicación. Sin embargo, también puede denominarse directamente por la aplicación o en otro procedimiento almacenado explícitamente parametrizar consultas ad-hoc. Esto puede ser muy útil en aplicaciones o archivos por lotes donde 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 del plan 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 Los procedimientos almacenados tienen muchas ventajas, incluida la capacidad de parametrizar consultas y volver a utilizar planes de ejecución. Para obtener más información, consulte los temas "Stored Procedures" y "Programación de procedimientos almacenados" en libros en pantalla de SQL Server 7.0.

Ver los datos del Monitor de rendimiento

Utilice el registro del Monitor de rendimiento para determinar qué recursos del sistema que provocan el cuello de botella. El registro del Monitor de rendimiento puede proporcionarle una visión general del sistema y ayuda a centrar la atención al ver los datos del analizador de SQL. Revise los datos del Monitor de rendimiento desde el momento cuando el rendimiento fue bueno hasta el momento en que el rendimiento disminuye. Determinar el contador que afectó en primer lugar 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: Cada instancia de procesador, consulte
  • Objetos: Administrador de búfer: SQL Server
    Contador: Búferes
  • Objetos: Administrador de búfer: SQL Server
    Contador: Recuento de páginas descartadas
  • Objeto: Administrador de: memoria de SQL Server
    Contador: Concesiones de memoria pendientes
  • Objeto: Estadísticas SQL: SQL Server
    Contador: Compilaciones SQL por segundo
Si el uso de la CPU, compilaciones SQL/seg. y contadores de búferes libres son altos, y los contadores de concesiones de memoria pendientes y robado el recuento de páginas son bajos, esto indica que la CPU es el cuello de botella. Se centran en cómo parametrizar de forma eficaz y reutilizar planes de consultas para evitar el costo de la generación de planes de consulta y consulte la sección "Agrupar la traza del Analizador SQL por clase de evento" de este artículo. Si los contadores de compilaciones SQL/seg. y búferes libres son bajos y los contadores robado el recuento de páginas y concesiones de memoria pendientes son altos, SQL Server tiene restricciones de memoria. Centrarse en Buscar consultas donde se utilizan combinaciones hash y se pueden cambiar para las combinaciones de bucles y consulte la sección "Agrupar la traza del Analizador SQL por duració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 se resuelve problemas de rendimiento, es extremadamente valiosa para ver datos del analizador de SQL. No es necesario revisar todos los datos que capturaron; sea selectivo. Analizador de SQL le ayuda a ver eficazmente los datos capturados. En la ficha Propiedades (en el
Menú archivo , haga clic en Propiedades), el analizador de SQL le permite limitar los datos que se muestran por quitar columnas de datos o eventos, agrupación u ordenar por columnas de datos y la aplicación de filtros. Puede buscar el seguimiento completo o sólo una columna específica para 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 comoy, a continuación, haga clic en Tabla de traza), y, a continuación, ejecutar consultas SQL contra él.

Nota: Asegúrese de que sólo filtra un archivo de traza guardada. Si sigue estos pasos en una traza activa, se arriesga a perder datos que se capturaron desde que se inició la traza. Guardar una traza activa en un archivo o tabla primero (en la
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 se eliminan. Puede agregar y quitar eventos y columnas de datos como ayuda para centrar las búsquedas.

También debe centrarse en las áreas que recibe el mayor beneficio. Los siguientes factores pueden ayudar a aumentar el rendimiento de la aplicación, pero no necesariamente en el mismo grado. Antes de implementar los cambios, determinar cuán eficaz los cambios pueden ser dependiendo de los factores siguientes:
  • La frecuencia con la que se ejecuta la consulta
  • Cuánto mejora la consulta puede mejorarse.
Por ejemplo, reduciendo el tiempo de ejecución de una consulta única de 1,5 segundos a 1,2 segundos puede no ser útil si la consulta no se ejecuta con frecuencia durante todo el día. Sin embargo, si la consulta se ejecuta con mucha frecuencia por 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 en el rendimiento general si raramente se utiliza. Utilice el agrupamiento y técnicas en el analizador de SQL y su conocimiento de la aplicación de filtrado para estimar los efectos de una determinada consulta o procedimiento antes de implementar los cambios. En primer lugar se centran en los cambios más eficaces y continúe con iteraciones a través de otras consultas y procedimientos hasta llegar a un nivel donde lo suficientemente ha mejorado el rendimiento.

Después de guardar una traza del analizador de SQL a un archivo o tabla, vuelva a abrir la traza en el analizador de SQL y revise el contenido. Para agrupar la traza del analizador de SQL, siga estos pasos:
  • Agrupar la traza del analizador de 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
      Duración. Haga clic en abajo para quitar todas las demás columnas.
    3. Haga clic en la ficha eventos y, a continuación, quite todos los eventos excepto TSQL SQL: StmtCompleted y TSQL RPC: completado. Esto le permite centrarse sólo las consultas que se ejecutan.
    4. Haga clic en Aceptar.
    Agrupación por duración permite ver fácilmente las instrucciones SQL, lotes y procedimientos que se ejecutan con la más lenta. Revise la traza cuando surja el problema y crear una línea de base del buen funcionamiento. Puede filtrar por hora de inicio para dividir la traza en secciones cuando el rendimiento es secciones independientes y buena cuando el rendimiento es deficiente. Buscar las consultas con la mayor duración cuando el rendimiento es bueno. Se trata probablemente de la raíz del problema. Cuando se reduce el rendimiento global del sistema, incluso buenas consultas pueden mostrar duraciones largas porque están esperando para recursos del sistema.

    Revisar los planes de ejecución para las consultas que más frecuentemente tienen duraciones largas. Si ve que se utiliza una combinación hash, considere el uso de la sugerencia de consulta de combinación de bucle para forzar una combinación de bucle anidado para la consulta. Si el tiempo de ejecución para la consulta con una combinación de bucle es menor, igual o incluso ligeramente más elevado 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 la CPU. Al reducir el estrés en el cuello de botella de recursos (CPU y memoria), puede mejorar el rendimiento general del sistema. Para obtener más información acerca de la sugerencia de consulta JOIN de bucle, consulte 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
      Clase de evento y el 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 eventos y, a continuación, asegúrese de que todos los eventos se incluyen.
    4. Haga clic en Aceptar.

Tipos de eventos

Para ver qué tipos de eventos se producen en el equipo que ejecuta SQL Server y con qué frecuencia se producen los eventos, agrupar por la columna de la Clase de evento . Buscar en esta columna para los siguientes eventos:
  • MISC: preparar SQL y Exec preparado SQL; CURSORES: Cursorprepare un evento Preparar SQL indica que se ha preparado una instrucción SQL para su uso con un conjunto de resultados predeterminado (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, de sólo lectura, tamaño de conjunto de filas = 1. Un evento Cursorprepare indica que se ha preparado un cursor de servidor en una instrucción SQL mediante SQLPrepare y SQLExecute (para ODBC) o ICommandText::Prepare/ICommandText:: Execute (para OLE DB) con una de las opciones de cursor anteriores establecidas en un valor no predeterminado. Un evento de Exec preparar SQL indica que se ejecutó cualquiera de los tipos anteriores de instrucciones preparadas existentes. Si ve las apariciones frecuentes de estos eventos, la aplicación utiliza el modelo preparar/ejecutar cuando se abre conjuntos de resultados. Si es así, debe determinar si está utilizando el modelo preparar/ejecutar correctamente.

    Idealmente, una aplicación prepara una instrucción SQL de una vez y ejecuta muchas veces para que el optimizador no tiene que compilar un nuevo plan cada vez que se ejecuta la instrucción. Cada vez que ejecuta una instrucción preparada, ahorrar el costo de la compilación de la consulta. Si sólo va a ejecutar una consulta una vez, Microsoft recomienda no prepararlo. Preparación y después ejecutar una instrucción SQL requieren tres ida y vuelta de red: uno para preparar la instrucción, uno para ejecutar la instrucción y otro para cancelaciones de preparación de la instrucción. Preparación de cursores de servidor requiere al menos cinco ida y vuelta: uno para preparar el cursor, uno para ejecutar o abrirlo, uno o más para obtener de ella, para cerrarla y otro para cancelaciones de preparación se. Ejecutar la consulta, sólo requiere uno de ida y vuelta.

    Para ver la efectividad con la aplicación utiliza el modelo de preparación y ejecución, compare el número de veces que estos dos eventos (preparar y ejecutar) se producen. El número de eventos Exec preparado SQL debe ser mucho mayor que el total de Preparar SQL y eventos CursorPrepare (al menos tres a cinco veces más grande es una buena estimación). Esto indica que instrucciones preparadas que se vuelven a utilizarse 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 SQL preparados de Exec , esto puede indicar que la aplicación no utiliza 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 esas instrucciones.

    La aplicación debe escribirse específicamente para utilizar eficazmente el modelo Preparar/Ejecutar. La duración de un identificador para una instrucción preparada controla cuánto tiempo 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, a continuación, libere el HSTMT, por tanto, perder el identificador para el plan preparado. Si lo hace, no recibe ningún beneficio del modelo Preparar/Ejecutar. De hecho, puede ver una degradación del rendimiento debido a la sobrecarga adicional de ida y vuelta por la red. La aplicación debe tener un método para almacenar en caché el HSTMT o el objeto con el identificador de instrucción preparada y tener acceso a ellos para su reutilización. El controlador o el proveedor no realiza esta operación automáticamente; la aplicación es responsable de la implementación, mantenimiento y uso de esta información. Si la aplicación no puede hacerlo, considere el uso de marcadores de parámetro en lugar del método preparación y ejecución.
  • Uso de marcadores de parámetro Aplicaciones pueden utilizar marcadores de parámetros para optimizar el uso de la misma instrucción de Transact-SQL varias veces con distintos valores de entrada y salida. La primera vez que se ejecuta una consulta, como una consulta parametrizada se prepara y SQL Server genera y almacena en caché un plan para la consulta parametrizado. Para llamadas posteriores a la misma consulta mediante los parámetros mismos o diferentes, SQL Server no tiene que generar un nuevo plan de consulta; SQL Server puede volver a utilizar 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 ICommandText:: Execute (para OLE DB), el controlador o proveedor automáticamente empaqueta la instrucción SQL y se ejecuta como una llamada sp_executesql . No tiene la instrucción que se prepara y se ejecuta por separado. Cuando SQL Server recibe una llamada a sp_executesql, automáticamente comprueba la caché de procedimientos para un plan coincidente y reutiliza dicho plan o genera un nuevo plan.

    Para determinar si su aplicación utiliza marcadores de parámetro, puede buscar el
    Columna de texto en la traza del analizador de SQL para "sp_executesql". Sin embargo, dado que sp_executesql puede ser llamado directamente, no todas las instancias indican el uso de los marcadores de parámetro.

    Para obtener más información sobre el modelo de preparación y ejecución, consulte 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ámetro, vea el tema "Marcadores de parámetros" en libros en pantalla de SQL Server 7.0.
  • SP: completado Instrucciones SQL dinámicas ejecutadas con el comando EXECUTE se muestran como un SP: completado con el texto "SQL dinámica". Expanda el SP: completado evento y, a continuación, busque las coincidencias que tienen "SQL dinámicas" como texto. Si hay muchos de estos eventos, puede mejorar el rendimiento de la aplicación mediante el uso de sp_executesql en lugar de la instrucción EXECUTE. El procedimiento almacenado sp_executesql permisos de SQL Server para volver a utilizar planes de ejecución si se ejecuta la misma consulta de nuevo con parámetros diferentes. 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 con los mismos parámetros.

    Para determinar las consultas o los procedimientos que utilizan eventos SQL dinámicos con la instrucción EXECUTE, observe el identificador de conexión y la hora de inicio de 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 el identificador de conexión (en la ficha filtros ) y, a continuación, quite todas las clases de evento excepto la SP: a partir de y SP: completa eventos para una mejor legibilidad. A continuación, puede buscar la hora de inicio del evento (en el menú Edición , haga clic en
    Buscar). Los resultados se muestran al inicia el evento SQL dinámico. Si el evento se produjo en un procedimiento almacenado, el evento aparece entre el SP: a partir de y SP: completado eventos para dicho procedimiento. Si el evento no se produjo en un procedimiento almacenado, se llevó a cabo como una consulta ad hoc, y puede utilizar las otras columnas de datos (Nombre de la aplicación, Nombre de usuario de NTy otros) para determinar donde se ejecutó el comando. Para determinar el texto del comando y el contexto donde se llevó a cabo, también puede agregar clases de evento, como SQL: BatchCompleted y SQL:RPCCompleted.

    Después de determinar si se utiliza la instrucción EXECUTE, considere la posibilidad de reemplazarlo por una llamada a sp_executesql. Por ejemplo, considere el siguiente escenario donde se utiliza el comando EXECUTE 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 basándose en el valor de ID. 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 no se parametriza automáticamente, si se ejecuta este procedimiento contra la tabla titles en la base de datos de ejemplo pubs dos veces con distintos valores para el parámetro @idValue , 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 simple que SQL Server puede parametrizar automáticamente y utilizar realmente el plan de ejecución. Sin embargo, si se trata de una consulta compleja que SQL Server no puede parametrizar automáticamente, SQL Server puede reutilizar el plan para la segunda ejecución si se ha cambiado el parámetro @idValue . 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 hace más eficiente debido a que genera planes de ejecución que son más propensos a ser reutilizado 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 para la instrucción SELECT parametrizado de títulos con title_id como parámetro. En la segunda ejecución, SQL Server reutiliza el plan con el nuevo valor de 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 recompile indica que SQL Server está utilizando recursos para la compilación de la consulta en lugar de ejecución de la consulta.
Si no ve estos eventos, la aplicación está ejecutando sólo consultas ad-hoc contra SQL Server. A menos que SQL Server determina que pueden parametrizar automáticamente determinadas consultas o si constantemente se utilizan 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 muchas compilaciones por segundo SQL. Puede ser que consumen más CPU para muchos usuarios simultáneos. Para evitar este problema, buscar las consultas ejecutan la más frecuentemente y considerar la creación de procedimientos almacenados para estas consultas, mediante marcadores de parámetro o 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:

224587 cómo solucionar problemas de rendimiento de aplicaciones con SQL Server

224453 INF: descripción y resolver problemas de bloqueo de 2000 o de SQL Server 7.0

Recompilación de procedimiento almacenado de la solución de problemas 243586

243589 cómo solucionar problemas de consultas de ejecución lenta en SQL Server 7.0 o posterior

251004 INF: cómo supervisar los bloqueos de SQL Server 7.0