SQL Server

Optimización del rendimiento de la CPU de SQL Server

Zach Nichter

Resumen:

• Solución de problemas de rendimiento de bases de datos
• Revisión de causas relacionadas con el hardware
• Uso de PerfMon para hacer un seguimiento de los cuellos de botella en las bases de datos
• Evaluación del rendimiento de las consultas

La solución de problemas de rendimiento en un sistema de base de datos puede ser una tarea muy dura. Es importante saber dónde hay que buscar, pero todavía más crucial es saber por qué el sistema reacciona como reacciona ante una determinada solicitud. Hay varios factores que pueden afectar al uso de la CPU

en un servidor de base de datos: La compilación y recompilación de instrucciones SQL, la ausencia de índices, las operaciones con varios subprocesos, los cuellos de botella de disco, los cuellos de botella de memoria, el mantenimiento rutinario y la actividad de extracción, transformación y carga (ETL), entre otros. El uso de la CPU en sí no es incorrecto: la CPU sirve precisamente para trabajar. La clave para un buen uso de la CPU es comprobar que éste procese lo que debe, en lugar de malgastar ciclos en código mal optimizado o hardware lento.

Dos caminos que llevan al mismo lugar

Visto desde un nivel alto, existen dos vías para identificar problemas de rendimiento de CPU. La primera es revisar el rendimiento del hardware del sistema, un ejercicio que ayuda a determinar dónde buscar cuando se sigue la segunda vía: revisar la eficacia de las consultas del servidor. Esta segunda vía suele ser más eficaz para identificar problemas de rendimiento de SQL Server™. No obstante, a menos que sepa exactamente dónde se encuentran sus problemas de rendimiento de consultas, siempre debe empezar con una evaluación del rendimiento del sistema. Al final, acabará usando las dos vías. Vamos a asentar algunas bases para poder examinar ambas vías.

Asentar las bases

Hyper-threading

El hyper-threading es un tema que vale la pena examinar a fondo, dado que afecta a SQL Server. El hyper-threading presenta ante el sistema operativo dos procesadores lógicos por cada procesador físico. En esencia, el hyper-threading libera tiempo de los procesadores físicos para optimizar el uso de cada uno de ellos. El sitio web de Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) ofrece una descripción más completa de cómo funciona el hyper-threading.

En sistemas SQL Server, el sistema de administración de bases de datos transfiere su propios subprocesos y colas (que son extraordinariamente eficaces) al sistema operativo, por lo que el hyper-threading sólo sirve para sobrecargar las CPU físicas en sistemas con un uso ya alto de la CPU. Cuando SQL Server pone en cola varias solicitudes para trabajar con varios programadores, el sistema operativo tiene que intercambiar el contexto de los subprocesos una y otra vez en los procesadores físicos para satisfacer las solicitudes que se realizan, incluso si los dos procesadores lógicos se encuentran en el mismo procesador físico. Si observa un valor de cambios de contexto por segundo mayor que 5.000 por procesador físico, debería plantearse desactivar el hyper-threading en su sistema y volver a analizar el rendimiento.

En casos excepcionales, las aplicaciones que experimentan un alto uso de CPU en SQL Server pueden aprovechar eficazmente el hyper-threading. Pruebe siempre las aplicaciones contra SQL Server con el hyper-threading activado y desactivado antes de implementar los cambios en sus sistemas de producción.

Un procesador avanzado de doble núcleo obtendrá fácilmente un rendimiento superior al de la RAM en un equipo, y éste funcionará más rápidamente que un dispositivo de almacenamiento conectado. Una buena CPU puede gestionar aproximadamente un rendimiento seis veces superior al de una memoria actual de altas prestaciones DDR2, y dos veces superior al de una memoria de altas prestaciones DDR3. El rendimiento normal de una memoria es 10 veces superior al de las unidades de canal de fibra más rápidas. En cambio, los discos duros sólo pueden realizar un número limitado de IOPS (operaciones de entrada/salida por segundo), un valor que está determinado enteramente por el número de búsquedas por segundo que puede realizar una unidad. Para ser justos, no es normal que se use una única unidad de almacenamiento para responder a todas las necesidades de almacenamiento en sistemas de bases de datos corporativos. La mayoría de las instalaciones actuales usan redes de área de almacenamiento (SAN) en servidores de base de datos de empresa o grupos RAID más grandes, que pueden evitar o minimizar problemas relacionados con el procesador de E/S del disco. Lo más importante que debe recordar es que, independientemente de cuál sea la configuración, los cuellos de botella de disco y de memoria pueden afectar al rendimiento de sus procesadores.

A causa de las diferencias de velocidad de E/S, recuperar datos del disco cuesta mucho más que recuperar datos de la memoria. Una página de datos de SQL Server ocupa 8 KB. Una extensión de SQL Server está formada por ocho páginas de 8 KB, que da un total de 64 KB. Esto es importante porque cuando SQL Server solicita una página de datos concreta del disco, no se recupera sólo la página de datos, sino toda la extensión en la que reside la página de datos. Existen algunas razones por las que este sistema es más rentable para SQL Server, pero aquí no entraremos en detalles. Publicar una página de datos que ya está copiada en caché desde el grupo de búferes en rendimiento máximo debería tardar menos de medio milisegundo; recuperar una única extensión del disco debería tardar entre 2 y 4 milisegundos en un entorno óptimo. Normalmente se espera que una lectura del subsistema de un disco en buen estado tarde entre 4 y 10 milisegundos. Recuperar una página de datos de la memoria suele ser entre 4 y 20 veces más rápido que publicar una página de datos del disco.

Cuando SQL Server solicita una página de datos, comprueba la memoria caché del búfer de la memoria antes de buscar la página de datos en el subsistema del disco. Si la página de datos se encuentra en el grupo de búferes, el procesador recuperará los datos y, a continuación, realizará el trabajo necesario. Este tipo de errores se denominan errores de software de página. Los errores de software de página son ideales para SQL Server porque los datos que se recuperan como parte de una solicitud deben estar en la memoria caché del búfer antes de poder usarlos. Una página de datos que no se encuentra en la memoria caché del búfer debe recuperarse desde el subsistema de disco del servidor. Cuando el sistema operativo tiene que recuperar la página de datos desde el disco, se habla de un error de disco duro de página.

Al correlacionar el rendimiento de la memoria, el rendimiento del disco y el rendimiento de la CPU, un denominador común ayuda a obtener una visión general de todo: el rendimiento. Para que pueda entenderse, rendimiento se puede definir como la medida de la cantidad de datos que se pueden especificar en una canalización con capacidad limitada.

Vía 1: Rendimiento del sistema

Existen pocos métodos para determinar si un servidor tiene un cuello de botella de CPU, y no hay muchas causas posibles de un uso alto de la CPU. Es posible hacer un seguimiento de algunos de estos problemas mediante PerfMon o una herramienta de supervisión del sistema equivalente, mientras que el seguimiento de los demás se puede llevar a cabo mediante el Analizador SQL o herramientas equivalentes. Otro método es usar comandos de SQL a través del Analizador de consultas o SQL Server Management Studio (SSMS).

La filosofía que sigo para evaluar el rendimiento del sistema consiste en empezar con una visión general y, después, ir profundizando. Obviamente, no se pueden analizar las áreas conflictivas hasta haberlas identificado. Después de evaluar el uso general de la CPU con una herramienta como PerfMon, puede usarla para examinar un par de contadores de rendimiento sencillos y fáciles de comprender.

Uno de los contadores de rendimiento más sencillos es el de porcentaje de tiempo de procesador; cuando está en PerfMon, se resalta al abrir la ventana Agregar contadores. El porcentaje de tiempo de procesador es el tiempo que los procesadores están ocupados realizando tareas. El uso de procesadores se considera alto cuando este valor es del 80 por ciento o más durante la mayor parte del tiempo de máximo funcionamiento. Lo normal y previsible es que existen picos de hasta el 100 por cien algunas veces, incluso cuando el servidor no esté funcionando al 80 por ciento.

Otro contador que se debería considerar es Longitud de la cola del procesador, que se encuentra bajo el objeto de rendimiento del sistema en PerfMon. Longitud de la cola del procesador muestra cuántos subprocesos esperan para realizar tareas en la CPU. SQL Server administra su trabajo mediante programadores en el motor de la base de datos, donde pone en cola y procesa sus propias solicitudes. Dado que SQL Server administra su propio trabajo, usará un único subproceso de CPU para cada procesador lógico. Esto significa que debe haber un número mínimo de conversaciones en espera en la cola del procesador para que se puedan realizar tareas en un sistema dedicado a SQL Server. Normalmente no debería existir un número cinco veces superior al del número de procesadores físicos en un SQL Server dedicado, pero consideramos que hay un problema si dicho número es del doble. En servidores donde el sistema de administración de bases de datos comparte un sistema con otras aplicaciones, es conveniente revisar esto junto con el rendimiento de los contadores de porcentaje de tiempo de procesador y cambios de contexto por segundo (a continuación, se describirán los cambios de contexto) para determinar si sus otras aplicaciones o el sistema de administración de bases de datos debe trasladarse a un servidor diferente.

Cuando veo un procesador en cola junto con un alto uso de CPU, analizo los contadores de compilaciones y de recompilaciones por segundo que hay en SQL Server: Objeto de rendimiento Estadísticas de SQL (vea la figura 1). La compilación y la recompilación de planes de consulta contribuyen a un mayor uso de la CPU del sistema. Deberían existir valores cercanos a cero para las recompilaciones, pero vigile la tendencia de sus sistemas para determinar cómo se comporta normalmente su servidor y así como el número normal de compilaciones. Las recompilaciones no siempre pueden evitarse, pero las consultas y los procedimientos almacenados pueden optimizarse para minimizar las recompilaciones y volver a usar los planes de consulta. Compare estos valores con las instrucciones de SQL que llegan al sistema mediante las solicitudes de lote por segundo que también se encuentran en SQL Server: objeto de rendimiento Estadísticas de SQL. Si las compilaciones y recompilaciones por segundo suponen un porcentaje alto de las solicitudes de lote que llegan al sistema, significa que esta es un área que debe revisarse. En algunas situaciones, es posible que los desarrolladores de SQL no entiendan cómo ni por qué su código puede contribuir a agravar este tipo de problemas de recursos del sistema. En otro lugar de este artículo se ofrecerán algunas referencias para ayudarle a minimizar este tipo de actividad.

Figura 1** Selección de los contadores que supervisar **(Hacer clic en la imagen para ampliarla)

Desde PerfMon, compruebe el contador de rendimiento llamado Cambios de contexto por segundo (vea la figura 2). Este contador indica cuántas veces hay que sacar los subprocesos de los programadores del sistema operativo (no de los programadores de SQL) para trabajar para otros subprocesos que están en espera. Los cambios de contexto suelen ser más frecuentes en los sistemas de base de datos compartidos con otras aplicaciones como IIS u otros componentes del servidor de aplicaciones de proveedor. El umbral que uso para Cambios de contexto por segundo es unas 5.000 veces superior al número de procesadores del servidor. Este valor puede ser mayor en sistemas que tienen activados los subprocesos y un uso de la CPU entre moderado y alto. Cuando el uso de la CPU y los cambios de contexto superan periódicamente sus umbrales, significa que existe un cuello de botella de la CPU. Si esto ocurre frecuentemente, debe empezar a planear la compra de más CPU, o de CPU más rápidas si su sistema está obsoleto. Para obtener más información, consulte la barra lateral "Hyper-threading".

Figure 2 Contadores de rendimiento que deben tenerse en cuenta

El escritor diferido de SQL Server (que es el nombre que recibe en SQL Server 2000) o el monitor de recursos (como se denomina en SQL Server 2005) es otra área que supervisar cuando el uso de CPU es alto. El vaciado de búfer y de las memorias caché de procedimientos pueden contribuir a consumir tiempo de CPU mediante el subproceso de recursos llamado Monitor de recursos. El Monitor de recursos es un proceso de SQL Server que determina qué páginas se conservarán y qué páginas necesitan ser vaciadas desde grupo de búferes al disco. A cada página del búfer y de las memorias caché de procedimiento se les asigna en principio un costo que representa los recursos que se consumen cuando se coloca dicha página en caché. Este valor de costo disminuye cada vez que el Monitor de recursos lo examina. Cuando una solicitud requiere espacio caché, las páginas se vacían de la memoria a partir del costo asociado a cada página; las páginas con los valores más bajos se vacían primero. Se puede seguir la actividad del Monitor de recursos a través del contador de rendimiento de escrituras diferidas por segundo bajo SQL Server: objeto Administrador de búfer dentro de PerfMon. Debería realizar un seguimiento de la tendencia que sigue este valor para determinar qué umbral es el normal en su sistema. Generalmente se revisa este contador junto con los contadores de duración prevista de la página y de controles por segundo para determinar si existe demanda de memoria.

El contador de duración prevista de la página (PLE) ayuda a determinar la demanda de la memoria. El contador de PLE muestra cuánto tiempo permanece una página de datos en la memoria caché del búfer. 300 segundos es el umbral aceptado por el sector para este contador. Un promedio inferior a 300 segundos durante un período extendido le indica que las páginas de datos se están vaciando de la memoria con demasiada frecuencia. Cuando esto sucede, el Monitor de recursos debe trabajar más intensamente, lo que a su vez exige más actividad en los procesadores. El contador de PLE debe evaluarse junto con el contador de páginas de control por segundo. Cuando se produce un control en el sistema, las páginas de datos erróneos de la memoria caché del búfer se vacían en el disco, y causa que disminuya el valor de PLE. El proceso del Monitor de recursos es el mecanismo que vacía estas páginas en el disco, así que durante estos controles es normal que incremente el valor de escrituras diferidas por segundo. Si su valor de PLE aumenta inmediatamente una vez completado un control, puede hacer caso omiso de síntoma temporal. Por otro lado, si encuentra que está habitualmente por debajo del umbral de PLE, es bastante probable que esa memoria adicional alivie sus problemas y que al mismo tiempo devuelva algunos recursos a la CPU. Todos estos contadores se encuentran en SQL Server: objeto de rendimiento Administrador de búfer.

Vía 2: Rendimiento de las consultas

Seguimiento de SP

Al realizar el seguimiento de su aplicación SQL Server, vale la pena familiarizarse con los procedimientos almacenados que se usan para el seguimiento. Si usa una interfaz gráfica (SQL Server Profiler) para realizar el seguimiento, puede aumentar la carga del sistema entre un 15 y un 25 por ciento. Si puede usar procedimientos almacenados en su seguimiento, este valor puede reducirse a la mitad.

Cuando sé que el sistema tiene un cuello de botella en algún lugar y deseo determinar qué instrucciones SQL actuales están probando problemas en el servidor, ejecuto la consulta siguiente. Esta consulta me permite ver las distintas instrucciones y los recursos que están usando actualmente, así como instrucciones que necesitan ser revisadas para mejorar el rendimiento. Para obtener más información acerca de los seguimientos de SQL, consulte msdn2.microsoft.com/ms191006.aspx.

SELECT 
    substring(text,qs.statement_start_offset/2
        ,(CASE    
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2 
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset)/2) 
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r 
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Los planes de consulta se evalúan, se optimizan, se compilan y se ubican en la memoria caché de procedimiento cuando se envía una nueva consulta a SQL Server. Cada vez que se envía una consulta al servidor, la memoria caché de procedimiento se revisa para intentar conciliarla con un plan de consulta que coincida con una solicitud. Si no se encuentra ninguna, SQL Server crea un nuevo plan; ésta es una operación que puede llegar a suponer un gran costo.

Algunas consideraciones para la optimización de CPU de T-SQL:

• Reutilización del plan de consulta
• Reducción de compilaciones y recompilaciones
• Clasificación de operaciones
• Uniones inapropiadas
• Ausencia de índices
• Análisis de tabla/índice
• Uso de funciones en cláusulas SELECT y WHERE
• Operaciones con varios subprocesos

Vamos a examinar todo esto con un poco de perspectiva. Normalmente, SQL Server obtiene datos tanto de la memoria como del disco y habitualmente trabaja con más de una página de datos. Normalmente hay varias partes de una aplicación que trabajan en un registro que ejecutan varias consultas más pequeñas o unen tablas para proporcionar una vista completa de los datos pertinentes. En entornos OLAP, es posible que las aplicaciones trabajen con millones de filas de una o dos tablas para poder consolidar, acumular y resumir los datos para un informe regional de ventas. En este tipo de situaciones, la recuperación de datos se puede medir en milisegundos si los datos están en la memoria, pero estos milisegundos pueden convertirse en minutos cuando se recuperan los mismos datos desde disco en lugar de desde la RAM.

El primer ejemplo es una situación con un alto volumen de transacciones, y la reutilización del plan depende de la aplicación. Una baja reutilización del plan origina un número elevado de compilaciones de instrucciones de SQL, que a su vez originan un volumen elevado de procesamiento de CPU. En el segundo ejemplo, el uso elevado de recursos del sistema puede hacer que la CPU del sistema esté excesivamente activa, ya que hay que vaciar constantemente los datos existentes de la memoria caché del búfer para hacer sitio para el gran volumen de nuevas páginas de datos.

Imagine un sistema altamente transaccional, donde una instrucción SQL como la que se muestra a continuación se ejecuta 2.000 veces en un período de 15 minutos para recuperar información sobre el embalaje de envío. Sin no se reutiliza el plan de consulta, en teoría podría haber un tiempo individual de ejecución de unos 450 ms por instrucción. Si se usa el mismo plan de consulta después de la ejecución inicial, cada consulta posterior podría ejecutarse probablemente en unos 2 ms, con o que el tiempo total de ejecución podría reducirse a unos 5 segundos.

USE SHIPPING_DIST01;
SELECT 
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;

La reutilización del plan de consulta es crucial para un rendimiento óptimo en sistemas con muchas transacciones, y normalmente se consigue mediante la parametrización de las consultas o los procedimientos almacenados. A continuación, se muestran algunos recursos excelentes para obtener información acerca de la reutilización del plan de consulta:

• Problemas de compilación y de recompilación de lotes y de almacenamiento en caché de planes en SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
• Optimización de procedimientos almacenados de SQL Server para evitar recompilaciones (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
• Recompilación de consultas en SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)

Un lugar útil con valiosa información es el de las vistas dinámicas de administración de SQL Server 2005 (DMV). Cuando el uso de la CPU es elevado, hay un par de DMV que suelo usar para determinar si la CPU se está usando apropiadamente.

Uno de dichos DMV es sys.dm_os_wait_stats, que se usa para proporcionar a los DBA una forma de determinar cada uno de los tipos de recurso o funciones que usa SQL Server y cronometrar el tiempo que el sistema permanece en espera a causa de dicho recurso. Los contadores de este DMV son acumulativos. Esto significa que para saber qué recursos podrían estar afectando a las distintas áreas del sistema, primero tendrá que enviar un comando DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) para restablecer todos los contadores después de revisar los datos de los problemas más importantes. El DMV sys.dm_os_wait_stats es el equivalente del comando DBCC SQLPERF(WAITSTATS) de comprobación de coherencia de base de datos en SQL Server 2000. Puede encontrar más información acerca de los distintos tipos de espera en Libros en línea de SQL Server en msdn2.microsoft.com/ ms179984.aspx.

Es importante saber que las esperas son normales en un sistema, incluso cuando el funcionamiento es óptimo. Debe detectar si las esperas están causadas por un cuello de botella de CPU. Las esperas de señal deberían reducirse al mínimo en relación con el tiempo de espera global. El tiempo que un recurso concreto espera un recurso de procesador puede determinarse fácilmente restando el tiempo de espera de señal del tiempo de espera total; este valor no debería ser mayor que el 20 por ciento del tiempo de espera total.

El DMV sys.dm_exec_sessions muestra todas las sesiones abiertas en el SQL Server. Este DMV proporciona una vista de alto nivel del rendimiento de cada sesión y todo el trabajo que ha realizado cada sesión desde el principio. Esto incluye la cantidad total de tiempo que ha estado esperando la sesión, el uso total de cpu, el uso de memoria y un recuento de lecturas y escrituras. El DMV también le proporcionará la entrada, el tiempo de entrada, el equipo host y la última vez que la sesión hizo una solicitud de SQL Server.

Si usa el DMV sys.dm_exec_sessions, podrá determinar sólo las sesiones activas, así que si detecta un uso alto de CPU, aquí es donde debe empezar a buscar. Revise primero las sesiones que tienen un alto recuento de CPU. Determine la aplicación y el usuario que ha estado realizando el trabajo y, a continuación, empiece a analizar más detalladamente. Asociar el DMV sys.dm_exec_sessions al sys.dm_exec_requests puede proporcionarle mucha información que está disponible a través de los procedimientos almacenados sp_who y sp_who2. Si combina estos datos con la función de administración dinámica (DMF) sys.exec_sql_text mediante la columna sql_handle, puede obtener la consulta que está actualmente en ejecución de la sesión. El fragmento de la figura 3 muestra cómo combinar estos datos para poder determinar qué está ocurriendo en un servidor en cada momento.

Figure 3 Determinación de la actividad del servidor

SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec 
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC

Considero que esta instrucción es útil para determinar en qué aplicaciones centrarse. Al comparar la CPU, la memoria, las lecturas, las escrituras y las lecturas lógicas para todas las sesiones de una aplicación, y determinar que el recurso de CPU es mucho mayor que otros recursos usados, en primer lugar, me centro en dichas instrucciones SQL.

Para realizar un seguimiento de instrucciones SQL históricamente para una aplicación, uso rastros de SQL Server. Puede obtener acceso a ellos a través de la herramienta Analizador de SQL o a través de los procedimientos almacenados de rastreo del sistema para poder evaluar qué está ocurriendo. Vea la barra lateral sobre seguimiento de SP para obtener más información acerca de este tema. Debe revisar el analizador en el caso de las instrucciones con un uso alto de CPU, así como advertencias de hash y de clasificación, errores de acceso a caché y otros marcadores rojos. Esto puede ayudarle a estrechar la búsqueda de instrucciones SQL específicas o de un período de tiempo concreto que ha causado un alto uso de recursos. El analizador es capaz de realizar el seguimiento de texto de instrucciones SQL, planes de ejecución, uso de CPU, uso de la memoria, lecturas lógicas, las escrituras, almacenamiento en caché de planes de consulta, recompilaciones, expulsión de planes de consulta de la memoria caché, errores de acceso a caché, análisis de tabla y de índice, estadísticas inexistentes y muchos otros eventos.

Una vez recopilados los datos de los procedimientos almacenados sp_trace o del Analizador de SQL Server, generalmente se usa una base de datos, que se rellena con datos de seguimiento después del suceso o bien mediante la definición del seguimiento de modo que escriba en la base de datos. Puede rellenar la base de datos después del suceso usando la función del sistema de SQL Server llamada fn_trace_getinfo. La ventaja de este método es que puede consultar y clasificar los datos de varias maneras para ver qué instrucciones SQL han usado más CPU o han tenido más lecturas y contar cuántas recompilaciones se han producido, entre otras cosas. Éste es un ejemplo de cómo se usa esta función para cargar una tabla con un archivo de seguimiento del analizador. El valor predeterminado especifica que todos los archivos de seguimiento para ese rastro se cargarán en el orden en el que se han creado:

SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Conclusión

Como ha podido comprobar, un alto uso de CPU no indica necesariamente que existe un cuello de botella de CPU. Un alto uso de CPU puede estar enmascarando otros cuellos de botella de aplicación o de hardware. Una vez que haya llegado a la conclusión de que el uso de la CPU es alto a pesar de que los otros contadores indiquen un estado correcto, puede empezar a buscar la causa en el sistema y aislar una solución (ya sea comprando más CPU u optimizando el código SQL). Haga lo que haga, no abandone. Con las sugerencias ofrecidas en este artículo, junto con un poco de práctica e investigación, optimizar el uso de la CPU bajo SQL Server es un plan de ejecución viable.

Zach Nichter es un profesional de SQL Server con más de 10 años de experiencia. Ha desempeñado numerosas funciones de soporte técnico de SQL Server, entre las que se incluyen administrador de bases de datos, responsable de equipo, administrador y consultor. Actualmente, Zach trabaja para Levi Strauss &Co. como arquitecto de administración de bases de datos, y se centra en la supervisión, la arquitectura y el rendimiento de SQL Server, entre otras iniciativas estratégicas. Además, Zach es el autor de un video blog que se encuentra en www.sqlcatch.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.