Analizador de SQL Server 2005, seguimiento de solicitudes de aplicaciones, plantillas de seguimiento, agrupación de información de solicitudes
Uno de los medios más útiles para monitorear la actividad del usuario es perfilador (perfilador). Con esta herramienta, puede averiguar qué comandos SQL Server está ejecutando actualmente. La necesidad de utilizar un perfilador surge muy a menudo. Aquí hay algunas situaciones estándar en las que puede ser muy difícil prescindir de él:
q Desea analizar la aplicación y ver qué comandos ejecuta en el servidor. Esta información puede ser útil:
· comprender con qué tablas de la base de datos trabaja esta aplicación al realizar ciertas operaciones. Muy a menudo, en una empresa, existe la necesidad de crear informes en un formato que no proporciona la aplicación, y los desarrolladores rara vez brindan información detallada sobre la estructura de la base de datos;
· para averiguar cuán óptimas en términos de rendimiento son enviadas las solicitudes al servidor por la aplicación. En la práctica, cuando se utiliza un generador de perfiles, a menudo es posible identificar consultas completamente subóptimas, por ejemplo, cuando se filtran o clasifican los datos del cliente;
· Comprender qué comando Transact -SQL de una aplicación en el servidor genera un error.
q recopilar información sobre la actividad del usuario durante un largo período de tiempo (por ejemplo, puede recopilar todas las solicitudes que una determinada aplicación envió al servidor durante la jornada laboral). La información recopilada se puede analizar manualmente o pasar al Asesor de ajuste de la base de datos para un análisis automatizado;
q para monitorear el funcionamiento del servidor en tiempo real. Por ejemplo, si el servidor se ralentiza repentinamente, puede ver en la ventana del generador de perfiles qué comandos se están ejecutando actualmente en él.
El generador de perfiles tiene muchas características nuevas en SQL Server 2005:
q Se agregaron perfiles de eventos de Integration Services. Ahora puede usar el generador de perfiles para monitorear el progreso de los nuevos paquetes DTS;
q se hizo posible registrar las lecturas del contador del Monitor del sistema al registrar información sobre la ejecución de un comando;
q Se han agregado muchos nuevos eventos y fuentes de información al generador de perfiles que se pueden seleccionar para escribir en el archivo de seguimiento. La definición de qué escribir en el archivo de seguimiento ahora se puede guardar en formato XML;
q ahora es posible guardar los resultados de la traza en formato XML (también se guarda la capacidad de escribir en los formatos ANSI, OEM, UNICODE);
q Incluso puede guardar planes de ejecución para comandos Transact -SQL capturados por el generador de perfiles en formato XML. Estos planes luego se pueden abrir en SQL Server Management Studio para un análisis más detallado;
q se hizo posible agrupar eventos directamente en la ventana del generador de perfiles. La agrupación, por ejemplo, hace que sea muy fácil contar cuántas veces se ejecutó un determinado comando Transact -SQL en el servidor durante el día.
Trabajar con el generador de perfiles parece muy simple. Esta aplicación se puede iniciar desde el menú Comienzo| Programas| Servidor Microsoft SQL 2005 | herramientas de rendimiento | Analizador de SQL Server . Para comenzar, en la ventana del generador de perfiles que se abre, en el menú Archivo(Archivo) debe ser seleccionado NuevoRastro(Nueva traza) y conéctese al servidor SQL Server 2005 que desea monitorear. La palabra "seguimiento" hace referencia a una sesión que recopila información sobre el funcionamiento de SQL Server 2005. Sin embargo, antes de comenzar a recopilar información, debe configurar los ajustes de esta sesión. Este ajuste se realiza en la ventana RastroPropiedades(Propiedades de seguimiento), que se abre automáticamente antes de iniciar una sesión de seguimiento (Fig. 11.1).
Arroz. 11.1. Configuración de las opciones de la sesión de rastreo
en la pestaña General(General) en la lista usarelplantilla(Usar plantilla) puede elegir la plantilla más adecuada para recopilar información dentro de su sesión. En principio, no puede prestar atención a la configuración de la plantilla, sino definir manualmente los parámetros para recopilar información (usando la pestaña adyacente EventosSelección(Seleccionar eventos)). Sin embargo, especificar la plantilla correcta puede ahorrar tiempo y evitar errores. Por lo tanto, nos detendremos en las plantillas con más detalle.
Una plantilla se guarda en un archivo especial con la extensión tfd configuración de la sesión de seguimiento. El trabajo con plantillas (agregar nuevas, cambiar las existentes, importar y exportar informes a otros directorios) se realiza mediante el menú Archivo| Plantillas(Archivo| Plantillas) en SQL Server Profiler . Inicialmente, tienes ocho plantillas a tu disposición:
q Estándar (defecto)- como su nombre lo indica, esta plantilla es adecuada para la mayoría de las situaciones y, por lo tanto, se selecciona de forma predeterminada. Le permite realizar un seguimiento de todos los procedimientos almacenados y los comandos Transact -SQL que se ejecutan;
q SP_cuenta- se recopila información sobre los procedimientos almacenados y las funciones lanzadas para su ejecución. Al mismo tiempo, la información en la ventana del generador de perfiles se clasifica (en la terminología del generador de perfiles, agrupada) por los nombres de los procedimientos almacenados;
q TSQL- Recopila información sobre todos los comandos Transact -SQL que se ejecutan en el servidor. Además del código de comando, también se registra información sobre los identificadores de los procesos de usuario y la hora de inicio. Por lo general, este patrón se usa para monitorear los comandos enviados al servidor por una aplicación;
q TSQL_duración- casi lo mismo que la plantilla anterior, pero en lugar de registrar información sobre cuándo se ejecutó el comando Transact -SQL, se registra el tiempo que tardó en ejecutarse. Normalmente, esta plantilla se utiliza para supervisar "manualmente" el rendimiento del servidor;
q TSQL_agrupados- además de la información sobre el código del comando Transact -SQL y la hora en que se ejecutó, se registra información sobre el nombre de la aplicación, la cuenta de usuario en el sistema operativo y el inicio de sesión del usuario que se utilizó para conectarse. Los registros se agrupan por inicio de sesión. Por lo general, este patrón se usa en situaciones en las que desea realizar un seguimiento de la actividad de una aplicación específica;
q TSQL_Repetición- Se registrará la información más detallada sobre los comandos Transact -SQL ejecutados. Luego, esta información se puede utilizar para reproducir la carga en el servidor con la máxima precisión. Por lo general, esta plantilla se usa para escribir un conjunto de comandos que luego se usarán para probar diferentes configuraciones del servidor en términos de rendimiento;
q TSQL_SP- además de registrar información sobre el inicio del lanzamiento de todo el procedimiento almacenado (evento SP: Comenzando), esta opción de seguimiento también registra información sobre la ejecución de cada comando de este procedimiento almacenado (evento SP: StmtIniciando). Este patrón se suele utilizar para supervisar el funcionamiento de procedimientos almacenados complejos;
q Afinación- esta plantilla está destinada a registrar la información más adecuada para la transmisión del Asesor de ajuste de la base de datos. Acerca de cómo trabajar con esta herramienta para el análisis automatizado y la optimización del rendimiento se describirá en segundo. 11.5.5.
Como ya se mencionó, no es necesario limitarse a un conjunto de plantillas listas para usar. Puede utilizar sus propios ajustes de sesión de seguimiento configurándolos en la pestaña EventosSelección. En la tabla de esta pestaña, debe seleccionar los eventos requeridos (en filas) y la información (en columnas) que se registrará para ellos. Tenga en cuenta que solo una pequeña fracción de las filas y columnas disponibles están visibles de forma predeterminada. Para habilitar la visualización de todas las filas y columnas, debe marcar las casillas showTodoEventos(Mostrar todos los eventos) y showTodocolumnas(Mostrar todas las columnas).
Suele ocurrir que desea realizar un seguimiento solo de las acciones realizadas en una base de datos específica, o por una aplicación específica, o por un usuario específico, o seleccionar todas estas condiciones al mismo tiempo. Los filtros para recopilar información se pueden configurar haciendo clic en el botón Columnafiltros Pestaña (Filtros de columna) EventosSelección. Cada columna se puede configurar para registrar solo valores específicos ( Me gusta) o impidiendo que se escriban determinados valores ( No como). De forma predeterminada, solo se configura un filtro: No como para columna Nombre de la aplicación. Hace que se ignoren todos los eventos de SQL Server Profiler, es decir, todos los eventos relacionados con el propio proceso de recopilación de seguimiento. Es mejor no eliminar este filtro, porque de lo contrario puede ocurrir una retroalimentación positiva con un registro interminable de información.
Con otro botón Organizarcolumnas(Organizar columnas), que se encuentra en la pestaña EventosSelección, puede personalizar el orden de las columnas para mostrar o registrar en el generador de perfiles. Presta atención a la sección. grupo(Grupo) en esta lista. Para aquellas columnas que se coloquen en él, la agrupación se realizará automáticamente. Si coloca solo una columna en esta sección, cuando la vea, tendrá la oportunidad de usar un modo muy conveniente. Agregadovista(Vista agregada) (cuando la información se agrupa automáticamente, por ejemplo, por base de datos, aplicación, nombre de usuario, etc., y los registros de la base de datos, la aplicación o el usuario deseados se pueden expandir y contraer).
Después de seleccionar la plantilla deseada o configurar su propio conjunto de eventos para el registro, solo tiene que volver a la pestaña General y configure algunas opciones avanzadas de sesión de seguimiento.
La información de seguimiento se puede registrar en un archivo. Este archivo se puede utilizar en diferentes situaciones:
q se puede pasar como fuente de información a Database Tuning Advisor;
q puede "jugar" nuevamente en el generador de perfiles, repitiendo todos los comandos grabados, por ejemplo, para evaluar el rendimiento con diferentes configuraciones del servidor;
q se puede presentar a los desarrolladores en apoyo de sus reclamos a la aplicación.
Observemos algunos puntos relacionados con el registro de una sesión de rastreo en un archivo:
q 5 MB, que es el límite de tamaño de archivo predeterminado, es muy pequeño. Al perfilar un servidor de producción, este tamaño se gana en minutos. Es cierto, la casilla de verificación está marcada de forma predeterminada. permitirArchivodese la vuelta(Habilitar cambio de archivo), es decir, después de completar un archivo, se creará automáticamente un segundo archivo, a cuyo nombre se agregará el número 1, luego - 2, etc., pero trabajar con una gran cantidad de archivos no es siempre conveniente. Si está recopilando información para enviarla al Asesor de optimización de la base de datos, es mejor establecer el límite de tamaño de archivo en 1 GB (utilizando el colocarmáximoArchivoTalla Pestaña (Establecer tamaño máximo de archivo) General). El seguimiento suele escribirse en un archivo desde la estación de trabajo del administrador, por lo que se necesitará espacio en disco en la estación de trabajo y no en el servidor;
q parámetro servidorprocesosrastrodatos(El servidor está procesando datos de rastreo) se puede utilizar para aumentar la confiabilidad de registrar información de rastreo. De forma predeterminada, SQL Server Profiler maneja los datos de seguimiento y lo hace en la máquina en la que se ejecuta (no necesariamente en el servidor). Si selecciona esta casilla de verificación, el servidor manejará el procesamiento de la información de rastreo. Esto garantiza que se recopile toda la información de rastreo (si la casilla de verificación no está marcada, es posible que se pierda parte de la información durante las horas pico del servidor), pero aumentará la carga en el servidor.
Otra opción para escribir información de seguimiento es escribir en una tabla de SQL Server. Se creará automáticamente una tabla con el conjunto de columnas deseado. Solo puede ajustar el número máximo de entradas en esta tabla. Tenga en cuenta que en esta pestaña el número máximo de entradas se indica en miles.
La última opción en la pestaña. General- permitirRastrodetenerhora(Habilitar tiempo de parada de seguimiento). Puede especificar una hora en la que el seguimiento se deshabilitará automáticamente. Por lo general, tiene sentido desactivar el seguimiento antes de iniciar algunas operaciones de limpieza que no le interesan desde el punto de vista del registro (copia de seguridad, carga masiva de datos, procesamiento de cubos OLAP, etc.).
Después de configurar todos los parámetros de seguimiento, puede hacer clic en el botón Correr Pestaña (Ejecutar) General y comience a rastrear (Fig. 11.2).
Arroz. 11.2. Visualización de información durante una sesión de seguimiento
El funcionamiento del Visor de información de seguimiento es bastante sencillo: la sección superior muestra los eventos que ocurren en el servidor, mientras que la sección inferior proporciona información detallada sobre ellos (por ejemplo, código de comando SQL). Estas son algunas de las opciones disponibles en esta ventana:
q si ficha Organizarcolumnas en las propiedades de la plantilla ha seleccionado columnas para agrupar, puede agrupar registros por estas columnas en la ventana de vista. Para ello, el menú vista(Ver) comando proporcionado agrupadosvista(vista agrupada);
q si en la misma pestaña en las propiedades de la plantilla en la lista grupo solo se ha colocado una columna, puede usar un modo de visualización aún más conveniente Agregadovista(Figura 11.3). Este modo se habilita con el comando Agregadovista del mismo menú vista y le permite convertir los valores de la columna elegida en nodos de árbol que se pueden contraer y expandir. Además, el número de eventos se cuenta automáticamente para cada uno de estos nodos.
Arroz. 11.3. Modo de visualización Agregadovista
q en el generador de perfiles, puede mostrar no solo los eventos que se acaban de capturar, sino también los archivos guardados y las tablas de seguimiento. Además, puede abrir scripts normales de SQL Server con comandos Transact -SQL. La información de estos archivos o tablas se puede utilizar para reproducir operaciones registradas. Los comandos del menú son para este propósito. Repetición(Repetir);
q Se ha introducido una nueva característica en SQL Server 2005 Profiler: vincular la información de seguimiento con los contadores de rendimiento del Monitor de rendimiento. Para aprovechar esta oportunidad necesitas:
definir una sesión de seguimiento durante la cual se debe escribir la información de las columnas Hora de inicio y Hora de finalización;
· iniciar una sesión de rastreo con información escrita en un archivo o tabla. Simultáneamente con él, recopile un registro de las lecturas del medidor Performance Monitor en un archivo;
abra la información recopilada del archivo de rastreo en el perfilador y luego use el comando ImportarRendimientoDatos(Importar datos de rendimiento) del menú Archivo.
SQL Server 2005 proporciona un reemplazo para el generador de perfiles. Estos son procedimientos almacenados de seguimiento. Su funcionalidad es casi idéntica a la del generador de perfiles. Por ejemplo, también puede seleccionar eventos para rastrear y escribirlos en un archivo de texto. La principal diferencia es que todas las configuraciones deberán realizarse desde el código Transact -SQL.
Trabajar con procedimientos almacenados de rastreo es más difícil y menos conveniente que con un generador de perfiles, y no proporcionan características adicionales. Por lo tanto, no los consideraremos en detalle. Damos solo una lista de dichos procedimientos almacenados con una breve descripción:
q sp_trace_create- le permite configurar los parámetros de la sesión de seguimiento;
q sp_trace_setevent- le permite seleccionar los eventos necesarios para la sesión de seguimiento creada;
q sp_trace_setfilter- le permite configurar un filtro para recopilar información de seguimiento;
q sp_trace_setstatus- le permite iniciar un seguimiento, detenerlo o eliminar el procedimiento almacenado generado sp_trace_create definición de la sesión actual;
q sp_trace_generateevent- le permite generar un evento personalizado que será interceptado durante el rastreo.
El producto de software SQL Server Profiler es un shell gráfico diseñado para crear seguimientos y analizar los resultados del seguimiento. Los eventos se almacenan en un archivo de seguimiento, que luego se puede analizar o usar para reproducir ciertas secuencias de pasos para identificar los problemas que han ocurrido.
Para realizar un seguimiento de las acciones que se están ejecutando actualmente, debe ejecutar MS SQL Profiler, crear un nuevo seguimiento y configurar el análisis de indicadores:
En la pestaña "General", debe especificar el nombre de la traza. Especifique dónde se guardarán los datos de rastreo capturados: en un archivo y/o en una tabla de base de datos.
De gran interés es la pestaña "Seleccionar eventos":
Esta página enumera los eventos que necesitan ser monitoreados. En este ejemplo, especificaremos los datos necesarios para realizar un seguimiento de los planes de consulta.
Obtenga lecciones en video de 267 1C gratis:
De forma predeterminada, el seguimiento se ejecuta a través de todos los eventos especificados en todas las bases de datos. Para aplicar filtros a los datos recibidos, debe hacer clic en el botón "Filtros de columnas...":
Por ejemplo, establezcamos la selección por ID de la base de datos (puede averiguar el ID de la base de datos mediante la consulta SELECT DB_ID(N'BaseName')).
Comenzando el rastreo en Profiler para 1C
Después de realizar todas las configuraciones, queda por comenzar el seguimiento, para esto debe hacer clic en "Ejecutar" (EJECUTAR). A partir de este momento, se comenzará a rastrear todas las acciones especificadas en el filtro:
Por ejemplo, ejecuto una ruta por la duración del documento "Recibos de bienes y servicios" para rastrear las operaciones que requieren más mano de obra.
Una vez recibida la traza, debe analizarse.
Análisis de datos de Profiler
Para el análisis, la traza resultante se puede guardar en un archivo o en una tabla. Guardaremos en una tabla de base de datos:
En esta lección, continuaremos con nuestro estudio de los procedimientos almacenados, que comenzamos en "Creación y administración de procedimientos almacenados". Aprenderá a analizar procedimientos almacenados y otras declaraciones T-SQL utilizando Microsoft SQL Server Query Analyzer y SQL Server Profiler. A partir de este análisis, podrá determinar qué tan eficientes son las declaraciones T-SQL. Una consulta eficiente de SQL Server utiliza la secuencia correcta de operaciones y los índices correctos para reducir el procesamiento de filas y minimizar la E/S.
Usando el Query Analyzer, puede ver el plan de ejecución elegido para la declaración T-SQL optimizador de consultas Servidor SQL. Optimizador de consultas es un módulo interno que busca el mejor plan de ejecución para cada sentencia T-SQL. Optimizador de consultas analiza cada instrucción T-SQL, analiza una serie de posibles planes de ejecución y evalúa el "costo" de cada plan en términos de recursos necesarios y tiempo de procesamiento. Se selecciona el plan de menor costo. El costo de cada plan se determina en función de las estadísticas disponibles que recopila el sistema y que pueden estar desactualizadas. Dado que puede saber más sobre su base de datos y sus datos que optimizador de consultas, entonces podrá crear un plan que sea mejor que el optimizador de consultas. Con la información proporcionada por Query Analyzer, puede determinar si el plan del optimizador de consultas para una declaración en particular será eficiente y, de no ser así, puede intentar optimizar esa declaración modificándola o usando una sugerencia de SQL. En esta lección, aprenderá a optimizar las declaraciones de T-SQL además de aprender a usar el Analizador de consultas.
Con Profiler, puede analizar las operaciones dentro de su sistema SQL Server para determinar qué instrucciones SQL y procedimientos almacenados están utilizando recursos del sistema innecesarios. Con esta información, puede centrar sus esfuerzos de ajuste en estas declaraciones y procedimientos almacenados primero. Además de describir cómo usar Profiler, este capítulo también le muestra cómo aprovechar al máximo la información que obtiene de Profiler.
Uso del analizador de consultas SQL
La utilidad Query Analyzer se envía con Microsoft SQL Server 2000 en lugar de
En nuestro trabajo, a menudo nos encontramos con una situación en la que una determinada consulta se ejecuta lentamente y no se ven problemas evidentes en el texto de la consulta. Por lo general, en este caso es necesario investigar el problema a un nivel más profundo. Como regla, se hace necesario mirar el texto de la consulta SQL y su plan, y aquí es donde SQLProfiler nos ayuda.
¿Qué es SQL Profiler y por qué es necesario?
SQLProfiler es un programa suministrado con MS SQL Server y está diseñado para ver todos los eventos que ocurren en SQL Server o, en otras palabras, para registrar un seguimiento. ¿Por qué un programador 1C necesitaría SQLProfiler? Al menos para obtener el texto de la consulta en SQL y ver su plan. Por supuesto, esto también se puede hacer con la ayuda de una revista de tecnología, pero esto requiere algunas habilidades, y el plan en el TJ no es tan hermoso ni legible. En el generador de perfiles, puede ver no solo un texto, sino también un plan gráfico de ejecución de consultas, lo que, en mi opinión, es mucho más conveniente. También puede usar el generador de perfiles para determinar: solicitudes de más de cierto tiempo, solicitudes a una mesa de espera específica, tiempos de espera de interbloqueo de bloqueos y mucho más...
Análisis de consultas con SQL Profiler
La mayoría de las veces, el generador de perfiles se usa específicamente para el análisis de consultas. Como regla, no necesitamos rastrear todas las consultas, a menudo necesitamos ver cómo una determinada consulta en el lenguaje 1C se traduce a SQL y ver su plan de ejecución. Por ejemplo, esto podría ser necesario para determinar por qué una consulta se está ejecutando lentamente, o si hemos escrito una consulta grande y queremos asegurarnos de que el texto de la consulta SQL no contenga uniones de subconsultas. Para capturar la solicitud en el seguimiento, haga lo siguiente:
1. Ejecute SQL Profiler Inicio - Todos los programas - Microsoft SQL Server 2008 R2 - Herramientas de rendimiento - SQLProfiler
2. Crear un nuevo archivo de seguimiento - Crear seguimiento (Ctrl+N)
3. Especifique el servidor DBMS en el que se encuentra nuestra base de datos y haga clic en "Conectar".
Naturalmente, nada le impide rastrear un servidor DBMS que se encuentra en otra computadora. 4. En la ventana que aparece "Propiedades de seguimiento", vaya a la segunda pestaña "Seleccionar eventos" 
5. Ahora necesita especificar los eventos y las propiedades de estos eventos que queremos ver en la traza. Necesitamos consultas y planes de consulta, por lo que debemos habilitar los eventos apropiados. Para mostrar la lista completa de propiedades y eventos, habilite las banderas "Mostrar todas las columnas" y "Mostrar todos los eventos". A continuación, debe seleccionar solo los eventos que se muestran en la figura a continuación, todos los demás eventos deben estar deshabilitados.
Descripción de eventos: ShowplanStatisticsProfile - plan de ejecución de consulta de texto.
ShowplanXMLStatisticsProfile: plan de ejecución de consultas gráficas.
RPC: Completado: texto de solicitud, si se ejecuta como un procedimiento (si se ejecuta una solicitud 1C con parámetros).
SQL:BatchCompleted: texto de consulta si se ejecuta como una consulta normal (si se ejecutó una consulta 1C sin parámetros).
6. Ahora necesita configurar el filtro para eventos. Si esto no se hace, veremos consultas para todas las bases de datos ubicadas en este servidor DBMS. Haga clic en el botón "Filtros de columna" y especifique un filtro por nombre de base de datos
Ahora veremos en el rastreo solo consultas a la base de datos "TestBase_8_2". Si lo desea, puede poner un filtro en otros campos, el más interesante de ellos: Duration (Duración), TextData (generalmente este es el texto de la consulta) y RowCounts (el número de filas devueltas por la consulta).
Por ejemplo, si necesito capturar todas las solicitudes a la tabla "_InfoRg4312" que duran más de 3 segundos en la base de datos "TestBase_8_2", entonces hago lo siguiente:
a) Filtrar por base de datos, ejemplo mostrado arriba
b) Filtrar por duración en milisegundos. 
C) Filtrar por texto de solicitud 
Aquí especificamos la máscara. Si necesita realizar un seguimiento de las consultas que acceden a varias tablas, cree varios elementos en la sección "Parece". Las condiciones de todos los filtros funcionan juntas.
7. Ahora puede comenzar a rastrear. Haga clic en "Iniciar", después de eso, el seguimiento comienza a funcionar y puede ver los eventos que configuró para mostrar y que se incluyen en sus filtros. Puede utilizar los botones de la barra de comandos para controlar el seguimiento.
De izquierda a derecha: Borrador: borra la ventana de rastreo, Inicio: comienza el rastreo, Pausa: detiene el rastreo, al presionar Inicio se reanuda el rastreo, Detener: se detiene el rastreo
8. La ventana de seguimiento consta de dos partes. Los eventos y las propiedades de los eventos se encuentran en la parte superior. La parte inferior muestra diferente información según el tipo de eventos. En nuestro caso, aquí se mostrará el texto de la solicitud o su plan.
9. Ejecute la consulta en la consola de consultas 1C y vea cómo se refleja en el generador de perfiles. 
El rastro muestra que hubo varias solicitudes, y solo una de ellas es la nuestra. El resto de las solicitudes son de servicio.
10. Por las propiedades de los eventos, puede comprender: cuántos segundos se ejecutó la consulta (Duración), cuántas lecturas lógicas (Reads) hubo, cuántas filas devolvió la consulta como resultado (RowCounts), etc. En mi caso, la consulta tomó 2 milisegundos, hizo 4 lecturas lógicas y devolvió 1 fila.
11. Si subimos un evento, podemos ver el plan de consulta de forma gráfica.
Como se puede ver en el plan, la búsqueda se realiza por índice por precio, aunque este plan no puede llamarse ideal, porque. el índice no cubre, los campos de código y nombre se obtienen usando KeyLookup, que toma el 50% del tiempo. 
Usando el menú contextual, el plan gráfico se puede guardar en un archivo separado con la extensión *.SQLPlan y abrirlo en un generador de perfiles en otra computadora o usando el programa más avanzado SQL Sentry Plan Explorer.
12. Si subimos aún más, veremos el mismo plan de consulta, pero en forma de texto. Es este plan el que se muestra en los controles de rendimiento TJ, TsUP y otros 1C. Para analizarlo, recomiendo usar un editor de texto avanzado con resaltado, como Notepad++.
13. Usando el menú "Archivo-Guardar como", la traza completa se puede guardar en varios formatos:
a) Al formato del propio perfilador, es decir con extensión *.trc
b) A formato xml
c) Puedes hacer una plantilla con el trazo. Véase el párrafo siguiente.
d) Puede guardar la traza como una tabla de base de datos. Una forma cómoda si necesitamos encontrar, por ejemplo, la petición más lenta de toda la traza o seleccionar peticiones por algún parámetro. Archivo - Guardar como - Tabla de seguimiento: seleccione un servidor DBMS y conéctese a él. A continuación, debe seleccionar una base de datos en el servidor especificado y especificar el nombre de la tabla donde se guardará el seguimiento. Puede seleccionar una tabla existente o escribir un nuevo nombre y luego la tabla se creará automáticamente en la base de datos seleccionada. 
En este caso hay que tener en cuenta que la Duración se almacena en la tabla en millonésimas de segundo y a la hora de mostrar el resultado conviene convertir el valor a milisegundos. La columna RowNumber también se agrega a la tabla, que muestra el número de la fila dada en el seguimiento.
14. Si a menudo necesita usar el generador de perfiles para analizar solicitudes, configurar los filtros y eventos necesarios rápidamente se volverá aburrido y, además, llevará mucho tiempo. Las plantillas de seguimiento vienen al rescate, donde especificamos los filtros que necesitamos y el orden de las columnas, y luego simplemente seleccionamos esta plantilla al crear un nuevo seguimiento. Para crear una plantilla, utilice el menú Archivo - Plantillas - Nueva plantilla
En la primera pestaña, todo es simple. Especifique el tipo de servidor, el nombre de la plantilla y, si es necesario, establezca un indicador para usar esta plantilla de forma predeterminada. En la segunda pestaña, seleccionamos eventos y configuramos filtros, como ya se mostró arriba. También recomiendo ajustar el orden de las columnas en la traza, esto ahorra tiempo a la hora de analizar las consultas. Por ejemplo, me parece más conveniente usar el siguiente orden.
Ahora, al crear un nuevo seguimiento, simplemente puede especificar la plantilla requerida, después de eso, en la segunda pestaña, todos los filtros y eventos se completarán automáticamente. 
Por supuesto, lejos de todas las formas de usar esta maravillosa herramienta que se muestran aquí, si hay interés por parte de la audiencia, en el futuro será posible reponer la colección de artículos sobre este tema.
16/05/2000 Itzik Ben Gan
Así como la reconstrucción de la escena de un crimen ayuda a encontrar al perpetrador, el rastreo de la base de datos ayuda a identificar cuellos de botella y eliminarlos.
El artículo "Catch the Event" de la edición anterior del blog describía la arquitectura del sistema de seguimiento de SQL Server 7.0 y mostraba cómo definir gráficamente un seguimiento en SQL Profiler. Esta vez hablaremos sobre cómo recrear seguimientos utilizando SQL Profiler y cómo definir el inicio automático a través de procedimientos almacenados de seguimiento extendidos. Con una base tan sólida, podrá utilizar SQL Profiler y los procedimientos almacenados de manera experta para una amplia variedad de investigaciones, desde consultas de larga ejecución hasta interbloqueos complejos.
Preparación preliminar para la reproducción de pistas
Con SQL Profiler, puede volver a rastrear los rastros guardados para depurar aplicaciones problemáticas, crear escenarios de la vida real para casos de prueba, ajustar bases de datos y más. Si desea volver a caminar por la pista, tendrá que hacer un trabajo preparatorio. En primer lugar, debe definir un seguimiento para rastrear eventos específicos y columnas de datos que no sean los que le interesan. La corrección de estos eventos y columnas adicionales garantiza que todas las acciones se repetirán exactamente como ocurrieron antes. En segundo lugar, debe guardar los resultados del seguimiento en un archivo, una tabla o una secuencia de comandos SQL.
Cualquier repetición debe capturar los eventos Connect, Disconnect, ExistingConnection y RPC:Starting y SQL:BatchStarting. Además, al reproducir cursores de API de back-end (es decir, cursores de servidor controlados por funciones de cursor de API), debe capturar los eventos CursorExecute, CursorOpen y CursorPrepare. Para reproducir instrucciones SQL preparadas del lado del servidor, agregue los eventos Exec Prepared SQL y Prepare SQL. La reproducción requerirá columnas que contengan los siguientes datos: nombre de la aplicación, información binaria, ID de conexión o ID de proceso del servidor (SPID), ID de la base de datos, clase de evento, subclase de evento, nombre de host, información numérica, nombre del servidor, nombre de usuario SQL, tiempo de inicio de ejecución e información de texto.
Es importante tener en cuenta que durante la segunda ejecución, los eventos capturados no se simulan, vuelven a ocurrir. Por lo tanto, tenga en cuenta que durante el rastreo inicial, lo más probable es que haya cambiado su base de datos. Por ejemplo, al reproducir un seguimiento que incluye una instrucción INSERT, puede aparecer una clave duplicada en la tabla. Para evitar tales problemas, debe restablecer la base de datos si el seguimiento se reproduce en el servidor original (es decir, en el servidor donde se realizó el seguimiento original).
Si la nueva ejecución se realizará en un servidor diferente, es importante asegurarse de que la base de datos de ese servidor esté en el mismo estado que la base de datos del servidor original. En este caso, asegúrese de utilizar los mismos nombres de usuario, sus autoridades, los identificadores de la base de datos que se utilizaron en el servidor de origen.
El uso de los mismos identificadores requiere una habilidad y experiencia especiales, especialmente porque Microsoft no fomenta el acceso directo a la tabla del sistema sysdatabases, que es necesaria para cambiar los identificadores de la base de datos. Puede hacer coincidir los ID de la base de datos de otra manera. Para hacer esto, copie los archivos de la base de datos del usuario del servidor de origen al que se reproducirá la pista y luego restaure la copia de seguridad de la base de datos maestra del servidor de origen. Un método alternativo es restaurar la copia de seguridad de la base de datos del usuario desde el servidor de origen al servidor elegido para la ejecución y luego restaurar la copia de seguridad de la base de datos maestra en el mismo servidor. En ambos casos, en el servidor donde se reproduce la pista, los archivos de la base de datos estarán ubicados en los mismos directorios que en el servidor de origen, y las tablas del sistema de la base de datos maestra contendrán los identificadores de la base de datos original. Para deshacerse por completo de estos problemas, solo necesita eliminar la columna del identificador de la base de datos del seguimiento y configurar la base de datos predeterminada para cada usuario que se captura en el seguimiento como se establece.
También puede controlar el nivel de tiempo del guión y la velocidad de reproducción. Seleccione Configuración en el menú Reproducir para acceder al cuadro de diálogo Reproducir SQL Server. El parámetro Nivel de sincronización, que controla la sincronización dentro de una conexión, puede tomar los siguientes valores:
Sincronización completa (Full synchronization). Este valor se utiliza de forma predeterminada. En este caso, todos los eventos que ocurrieron en una conexión se reproducen en su orden original. Sincronización parcial. Con este valor, los eventos en una conexión pueden comenzar antes que los eventos ya registrados en otras conexiones. Sin sincronización. Con este valor de parámetro, los eventos pueden ocurrir inmediatamente después del final del evento anterior en la misma conexión, es decir, sin ninguna sincronización dentro de la conexión.El parámetro de velocidad de reproducción, Replay Rates, se puede establecer en uno de los siguientes valores:
Lo más rápido posible (Lo más rápido posible). Este es el valor predeterminado, en este caso, el próximo evento comienza tan pronto como finaliza el anterior. Mantener intervalo entre eventos. Este valor conserva el intervalo de tiempo original entre la ocurrencia de eventos. Mantener la relación con la hora de inicio. Con este valor, los eventos ocurren en los mismos puntos de tiempo relativos al comienzo de la reproducción de la traza como en la traza original.Organización de reproducción de pistas
Suponga que desea reproducir un seguimiento de ejecución de instrucciones SQL preparadas del lado del servidor, que son instrucciones Transact-SQL (T-SQL) enviadas por un usuario a un servidor a través de ADO, OLE DB u ODBC. SQL Server 7.0 ejecuta sentencias SQL preparadas en el lado del servidor mediante procedimientos pseudoalmacenados sp_prepare y sp_execute a los que llama la aplicación cliente.
La llamada sp_prepare hace que SQL Server prepare declaraciones T_SQL para su ejecución compilándolas y almacenando en caché los planes de ejecución. Cuando se llama a sp_execute, SQL Server ejecuta planes previamente almacenados en caché y posiblemente lo haga más de una vez. Cada llamada a procedimiento almacenado activa los eventos RPC:BatchStarting, Prepare SQL y Exec Prepared SQL. Es por esta razón que estos eventos deben incluirse en la definición de seguimiento.
SQL Profiler contiene varias definiciones de seguimiento de muestra que se pueden usar como plantillas. Esto incluye el ejemplo número 6, "T-SQL for Replay", que hace referencia a volver a ejecutar el seguimiento. Este ejemplo es útil para especificar la salida de seguimiento que se genera durante la reproducción. Para abrir la salida de seguimiento guardada para su reproducción, seleccione Abrir en el menú Archivo y seleccione un archivo, tabla o secuencia de comandos SQL para almacenar la información recopilada durante el seguimiento. Puede controlar la reproducción usando las opciones que se muestran en la Tabla 1. Se pueden representar mediante los elementos del menú Reproducir o mediante botones en la barra de herramientas.
Aplicación de procedimientos almacenados extendidos
Algunas funciones de seguimiento de SQL Profiler no están disponibles. Estos incluyen el seguimiento para ejecutarse según un cronograma, ejecutarse cuando ocurre un evento específico o cuando se inicia SQL Server. Además, SQL Profiler no se puede configurar para enviar resultados de seguimiento al registro de la aplicación de Windows NT o Windows 2000. Para realizar estas funciones y proporcionar más control programático sobre los seguimientos, puede utilizar un conjunto de procedimientos almacenados extendidos conocidos colectivamente como xp_trace*.
Veamos los principios del uso de estos procedimientos almacenados usando el ejemplo de iniciar un seguimiento sp_start_mytrace y el procedimiento almacenado deteniendo un seguimiento sp_stop_mytrace. El primer procedimiento almacenado, sp_start_mytrace, define eventos de seguimiento, columnas de datos, filtros y crea una cola para almacenar eventos capturados. Luego recupera los eventos de la cola y los coloca en un archivo del sistema. El procedimiento sp_start_mytrace se comunica con la cola de eventos y realiza un seguimiento de su estado a través del identificador de tipo entero del identificador de cola que crea el procedimiento durante la creación de la cola. sp_stop_mytrace usa este identificador cuando necesita detener la cola.
Hacer un seguimiento del estado de un descriptor de cola no es una tarea fácil. Aunque existen muchos métodos para obtener su valor, la forma más sencilla y funcional es crear una tabla que registrará datos sobre todos los rastros y sus colas, así como la hora de inicio del rastro, el identificador del usuario que encendió el seguimiento y el nombre del equipo desde el que se inició. El Listado 1 muestra las declaraciones que crean una tabla llamada activetraces. Para ver qué rastros se están tomando actualmente, simplemente vea esta tabla. Para detener el rastreo, simplemente consulte la tabla para el descriptor de cola adecuado.
Procedimiento almacenado para iniciar el rastreo
Recorramos estos dos procedimientos almacenados para ver cómo se inicia y se detiene un seguimiento. El procedimiento almacenado que inicia el seguimiento tiene cuatro parámetros de entrada opcionales. Los dos primeros, @spid_filter y @dbid_filter, le permiten limitar la información recopilada durante un seguimiento solo a aquellos relacionados con un proceso de servidor específico (identificado por su ID, SPID) y una base de datos determinada. Si no se establecen estos parámetros, el seguimiento recopilará datos sobre todos los procesos y bases de datos. El parámetro @email_address le permite asignar una dirección de correo electrónico a la que se enviará información detallada sobre el progreso del rastreo. Si no se especifica este parámetro, sp_start_mytrace solo imprimirá información en la pantalla. Si se proporciona, pero la dirección es incorrecta, el procedimiento almacenado emitirá un mensaje de error y se cerrará. El último parámetro, @filename, pretende especificar el nombre del archivo al que se enviará la información recopilada durante el rastreo. Si no se especifica este parámetro, la información predeterminada se colocará en el archivo c:\mytraceN.trc, donde N es el número del descriptor de cola. Esta convención, que define la regla para nombrar archivos con datos de seguimiento, le permite capturar varios seguimientos al mismo tiempo, sin permitir que uno de ellos bloquee el archivo para escribir resultados solo para sí mismo.
Para probar el activador, cambie las propiedades del archivo:
ALTERAR BASE DE DATOS testdb MODIFICAR ARCHIVO (NOMBRE=`testdb_dat`, TAMAÑO MÁXIMO=30 MB)
Recibirá un mensaje de que se han cambiado las propiedades del archivo:
Las propiedades del archivo cambiaron:
Declaración: ALTER DATABASE testdb MODIFY FILE (NOMBRE = `testdb_dat`,
TAMAÑO MÁXIMO=30 MB)
Nombre de usuario de NT: Gandalf
Nombre de la aplicación: Analizador de consultas MS SQL
Nombre de usuario de SQL: NA
Hora: 2000-11-22 14:15:28
Siempre es muy difícil averiguar qué eventos llevaron a la creación de un punto muerto. Sin embargo, SQL Profiler proporciona eventos especiales que pueden facilitar enormemente la "investigación". Por ejemplo, puede usar el rastreo para rastrear la ocurrencia del evento Lock: Deadlock. La ocurrencia de este evento habla
que se ha producido un impasse. Esto proporciona al usuario el ID del proceso del servidor (SPID), el ID de la transacción bloqueada, el tiempo de bloqueo, el nombre de la aplicación y el ID del usuario. El evento Lock: Deadlock Chain, que se genera cada vez que ocurre un bloqueo, es extremadamente conveniente: le permite conocer los identificadores de proceso (SPID) y las transacciones.
Puede registrar los ID de las transacciones involucradas en el interbloqueo, luego agrupar los resultados del seguimiento por ID de transacción y solo analizar esas transacciones. En otro enfoque, los resultados del seguimiento se envían a una tabla. Luego puede usar consultas para filtrarlo por SPID o ID de transacción.
Para generar una situación de interbloqueo, cree dos tablas, t1 y t2, cada una de las cuales debe tener solo una columna de enteros. Ingrese una fila en cada tabla que contenga el valor 1. Especifique una traza en la que se registrará el siguiente conjunto de eventos: Lock: Deadlock, Lock: Deadlock Chain y los eventos de inicio y finalización correspondientes de la ejecución de sentencias (RPC, SP, SQL ). La elección debe hacerse en función de la fuente prevista de bloqueo. En nuestro ejemplo, solo necesitamos los eventos SQL: StmtStarting y SQL:StmtCompleted.
Además de las columnas de datos predeterminadas, agregue una columna para capturar el ID de transacción y las columnas de su elección. Configure el filtro de seguimiento para que coincida con el ID de la base de datos con la que está trabajando. Después de eso, abra dos conexiones de servidor desde Query Analyzer. En la primera conexión, ejecute:
COMENZAR TRANSACCIÓN ACTUALIZAR t1 SET col1 = 1
En la conexión 2, ejecute la siguiente transacción:
COMENZAR TRANSACCIÓN
ACTUALIZAR t2 SET col1 = 1
SELECCIONE * DESDE t1
COMPROMETER TRANSACCIÓN
Finalmente, en la conexión 1, ejecute las sentencias:
SELECCIONE * DESDE t2
COMPROMETER TRANSACCIÓN
Detenga el seguimiento y abra el archivo de seguimiento. Busque los eventos Lock:Deadlock Chain y anote los números de las transacciones involucradas. Agrupe la salida por ID de transacción y expanda las transacciones correspondientes. La salida se verá similar a la Pantalla 1.
SQL Server Enterprise Manager incluye un asistente que puede ayudarlo a configurar seguimientos, incluidos los que se usan para encontrar la causa de los interbloqueos. Para utilizar el asistente Crear seguimiento para definir un seguimiento, inicie sesión en Enterprise Manager, seleccione Asistentes en el menú Herramientas, luego abra la categoría Gestión y seleccione Asistente Crear seguimiento.
Observación final
Las capacidades de seguimiento proporcionadas por SQL Profiler, junto con los procedimientos almacenados de seguimiento extendidos disponibles en SQL Server 7.0, le permiten depurar el comportamiento de la base de datos. Ya sea que solo esté monitoreando el estado de su entorno de SQL Server o resolviendo problemas de rendimiento de aplicaciones, es hora de poner en práctica sus conocimientos.
Itzik Ben Gan [correo electrónico protegido] posee las certificaciones MCDBA, MCSE+I, MCSD, MCT y SQL Server MVP. Es profesor titular de cursos de SQL Server en Hi-Tech College en Israel y presidente del grupo de usuarios de SQL Server de Israel.
