SQL Server Profiler (o Analizador)

Envíos De Dinero a México Envía dinero por Internet a México de manera rápida por tan solo $4.99 www.xoom.com Introducción al uso del Microsoft SQL Server Profiler (o Analizador) Esta útil –aunque fea- herramienta permite ver “el interior” de los sistemas. Nos deja visualizar en tiempo real la actividad del servidor de base de datos, lo que a su vez permite detectar cuellos de botella en las aplicaciones. Una consulta mal diseñada o un índice inexistente puede provocar una terrible demora en las operaciones más sencillas. El Profiler nos deja hacer un seguimiento detallado y encontrar “dónde le duele” a la base de datos. Además es totalmente inocuo, no se puede “romper nada” con él, así que para meter la cabeza dentro del servidor es una perfecta opción. Cómo se usa El acceso para ingresar está en el mismo grupo de programas que el resto de las herramientas de cliente de SQL Server. Los ejemplos y pantallas que siguen corresponden a la versión 2000. La primer pantalla es un poco triste: Al menos no asusta con incontables funcionalidades… Vamos a empezar: Archivo -> Nueva -> Traza Una “traza” es un registro de actividades del servidor. La traza se genera en tiempo real, con los parámetros que especifiquemos. Acto seguido el sistema solicitará conectarse a un servidor: No voy a explicar ahora cómo se conecta, asumo que ya eso lo pueden hacer sin problemas. Click en “Aceptar” y seguimos. Ahora viene la papota: La primer solapa permite colocar un nombre a la traza (cosa que se puede obviar a menos que querramos guardarla, y de todos modos se puede poner al final). La “Plantilla” es lo segundo que permite seleccionar. La plantilla es un conjunto de las selecciones de las otras tres solapas. Hay algunas precargadas que se pueden utilizar. Esas las dejo para que investiguen. Siempre se debe seleccionar una, la llamada “SQLProfilerStandard” es la que llamaríamos “traza por default”. Vamos a tomarla como base y configurar una “manualmente”. La primer solapa permite configurar “sucesos”. Dichos “sucesos” son los eventos que generarán un registro en la traza. Por default no son muchos (hay más para elegir). Para el caso basta con los que aparecen cargados: Audit login y Audit logout: marcan el comienzo del registro y el final. Además de la fecha y hora, se genera un resumen de la actividad auditada. RPC Completed: Cuando se completa una ejecución de Procedimiento Almacenado (Store procedure para los amigos) generará un registro. TSQL: BatchCompleted: Al completarse una tarea por lotes de Transac-SQL (una consulta, insert, update, etc), también generará un registro. La segunda solapa corresponde a las “Columnas de datos” Algunas columnas serán interesantes para ver su contenido. Otras tal vez no, pero al principio nos servirán para determinar filtros adecuados para la traza. Vamos a dejarlo así por el momento. La última solapa permite determinar “Filtros”. Los filtros permitirán separar “paja del trigo”. Cuanto más carga tenga un servidor SQL, más necesario será que utilicemos un filtro. Caso contrario encontraremos miles de registros en la traza, lo que la hace imposible de seguir, además de aburrida. Empecemos por filtrar una base de datos en particular. Aunque hay dos criterios que nos permitirían hacerlo (DatabaseID y DatabaseName), no pude hacer funcionar el segundo. Tal vez solo esté cometiendo un error, pero ni lento de perezoso, busqué las ID de las bases de datos que tenemos. Para ello bastará con ejecutar en el Analizador de Consultas (o Query Analyzer), que es otra herramienta de cliente de SQL Server: select name, dbid from master.dbo.sysdatabases Esta consulta devuelve una lista con las bases de datos y su identificación. Por ejemplo voy a filtrar la base de datos con ID=17 Hay muchos otros campos para filtrar. En función de la aplicación que estemos queriendo analizar será el criterio aplicado. Hay que probar un poco para tener idea de qué valores colocar. Al darle click a “Ejecutar” comienza la traza. Cada renglón será un suceso capturado. Veremos en las columnas algunos datos de interés que marcan la performance. El más evidente es “Duration” que en SQL Server 2000 mide en milisegundos la duración del suceso. También deja medir el consumo de CPU y el acceso a disco (Read). Por cada conexión existente veremos un registro llamado “ExistingConnection”. Cada vez que una conexión de cliente se cierra se genera un resumen de la actividad monitoreada. Bueno, aquí ya se ve algo de data para examinar. Noten que hay dos sucesos que demoran muchísimo más que los otros. Uno de ellos tarda 17606 milisegundos (17 segundos humanizándolo). El otro suceso se trata de un “Audit logout”, o sea que resume una cantidad de operaciones, por lo tanto no es para alarmarse. Lo siguiente para mejorar la performance sería marcar el registro del suceso lento y ver en la parte inferior qué es lo que tarda tanto. En este caso corresponde con un store procedure, al que habrá que examinar para determinar por qué tarda tanto, y corregirlo. Pero eso será en otro post… (si lo piden, obviamente)... Llegó el siguiente post!!! http://www.taringa.net/posts/apuntes-y-monografias/7032863/Optimizacion-de-aplicaciones-cliente-servidor-_SQL_.html