Oasis

lunes, febrero 27, 2006

SQL: Optimización de las consultas

Bueno, ya tenemos la forma en la cual podemos capturar o rastrear los eventos que se están ejecutando en el servidor, ahora es importante saber leer estos eventos y saber cuales están provocando un stress o demora en el desempeño.

Normalmente lo que pasa cuando el desempeño esta mal son 2 cosas:


• Estas consultas consumen muchos recursos del sistema y hacen que no se realice un desempeño adecuado.
• También pasa que las consultas problemáticas bloquean a otras consultas haciéndolas lentas, por lo tanto optimizar a las consultas problemáticas beneficia a todas las consultas y eventos.

Para identificar a estas consultas lentas o problemáticas podemos usar las columnas CPU o Reads. Como ya sabemos Read es el numero de lecturas y CPU el numero de milisegundos que tarda una consulta.

Aunque un evento solamente haga lecturas hace una especie de bloqueo sobre los datos, por lo tanto es importante optimizarlos.
Hay 2 categorías de consultas problemáticas:
• Simples
• Múltiples


Las simples las identificamos porque tienen una cantidad grande en la columna “reads”, es decir una sola consulta es muy robusta en sus lecturas.
Las múltiples las identificamos porque son pequeñas consultas que se ejecutan muchas veces, es decir consultas con “reads” pequeños pero ejecutados con mucha frecuencia.

martes, febrero 21, 2006

SQL Profiler: Recomendaciones para el Trace

Recomendaciones del libro que estoy leyendo ( “SQL Server Query Performance Tuning Distilled, Second Edition by Sajal Dam” ).
  1. Limitar el numero de eventos y columnas: Se utiliza la PRE y POST filtración, esto es importante ya que de lo contrario estaríamos utilizando muchos recursos. Prefiltrar es estar viendo al momento las actividades capturadas y postfiltrar es donde analizas lo capturado.
  2. Sacar los eventos Start. Nos dicen que no los necesitamos puesto que lo que queremos es ver resultados cuando se terminan de ejecutar los procesos, ahí es cuando tendremos resultados de la duración, costos, etc.
  3. Limitar el tamaño del rastreo: Se nos recomienda poner en propiedades la Duración y las lecturas > 2 ya que las menores no son muy optimizables.
  4. Evitar ordenamientos al momento de hacer el rastreo. Es preferible hacer este ordenamiento una vez que se termine de ejecutar el trace, lo que debemos de hacer es grabarlo y entonces si, aplicar los ordenamientos y agrupaciones que queramos.
  5. No Ejecutar el profiler remotamente. Nos dice que no esta bien ejecutar herramientas de pruebas en el servidor de producción, esto porque el profiler no corre por una sesión remota, y además porque los resultados los dejaría en un directorio del Server y no de nuestra PC.
  6. Capturar el rastreo utilizando Procedimientos Almacenados. Es recomendable hacer el rastreo con un procedimiento almacenado ya que es mas ligero. Lo malo de esto es que es tardado crear el script de este store procedure, porque se necesitan los siguientes comandos:
  • sp_trace_create: Creamos el rastreo.
  • sp_trace_setevent: Agregamos eventos y columnas.
  • sp_trace_setfilter: Aplicamos filtros.
  • sp_trace_setstatus: Iniciamos el rastreo.

    Para evitar hacer el script se nos recomienda lo siguiente:
  • Abrir el profiler
  • Conectarnos al servidor.
  • Abrir un templete ya existente o bien definir uno nuevo.
  • Correr el trace ( temporalmente )
  • Parar el trace.
  • Crear un SQL Script de este trace o rastreo.
  • Abrir este Script en el Query Analyzer.
  • Modificar el parámetro “InsertFileNameHere” del comando sp_trace_create
    Ejecutar el Script, con esto comercia el trace, nos dara un ID ( traceid ) que lo usas para detener el trace.

    Para detener el trace podemos ejecutar el siguiente codigo: EXEC sp_trace_setstatus 1, 0 despues de esto debemos de cerar y borrar el trace, esto se hace con el siguiente codigo:
    sp_trace_setstatus 1, 2

lunes, febrero 20, 2006

SQL: Data Columns y Filtros del trace

Continuando con el profiler, esta herramienta nos permite seleccionar que columnas de datos queremos visualizar, estas columnas representan diferentes atributos de un evento, las columnas que utilizaríamos serian al menos las siguientes:

  • EventClass ( Tipo de Evento )
  • TextData ( Operación ejecutada )
  • CPU ( Costo en milisegundos del CPU )
  • Reads ( Numero de lecturas )
  • Writes ( Numero de escrituras )
  • Duration ( Tiempo de ejecución en milisegundos )
  • SPID ( Identificador del proceso )
  • StartTime ( Tiempo de arranque ).

Estas columnas las podemos especificar dentro de la herramienta en la pestaña de Data Columns. Además de las ya mencionadas columnas existen muchas mas que pueden ser de gran ayuda, unas de las que me llamaron la atención para agregarlas son las de:

  • EventSubClass
  • DatabaseID
  • IndexId
  • Error
  • TransactionID.

También es conveniente ponerle filtros a nuestro rastreo ya que no es necesario tener todo lo que se esta ejecutando, sino solo lo que esta entorpeciendo el desempeño de la base de datos. Podemos filtrar los eventos para solo tener los que se presentan en la aplicación y base de datos que queremos, para los eventos que duran mucho ( poner mayor a 2 ), para los que realizan muchas lecturas y talvez de algún usuario en especial.

miércoles, febrero 15, 2006

SQL: Que podemos hacer con el SQL Profiler.

  • Esta herramienta nos sirve para Monitorear las actividades del servidor SQL, analisis de rendimiento, Diagnosticar problemas, etc. Tambien se pueden capturar las actividades desarrolladas en el server, esto se hace con el "TRACE".
  • Este trace tiene diferentes eventos, entre los cuales tenemos eventos por cursores, Procedimentos almacenados, por locks y consultas, cada evento tiene una descripcion que nos va a ayudar en este caso para realizar un analisis de desempeño y realizar acciones correctivas si es necesario.
  • El analisis del desempeño se realiza una vez que los eventos terminan, los eventos que me van a servir a mi son de Store Procedures ( RPC y Stmt ) y TSQL. Los RPC son procesos que son ejecutados usando Remote Procedure Call, esto se ejecuta por el driver ODBC y son ejecutadas mas rapido que si ponemos un EXEC en una sentencia TSQL. Los Stmt son sentencias de SQL dentro de un Store Procedure, esto puede ser un SELECT COUNT(Emp_ID) FROM Empleados.
  • Bueno ya sabemos de algunos de los eventos que necesitamos, pero como capturar estos eventos?, como tener solamente los que queremos ver?, puesto que el Profiler tiene una lista de eventos muy grande, pues es muy sencillo, en el Profiler viene una pestaña que tiene el listado de los eventos y ahi los añadimos y removemos.

  • Como dije anteriormente, solo sabemos de algunos eventos, existen aun mas, voy a poner una lista que viene en el libro que estoy tomando como referencia para todo esto.



Bueno, falta muchisimo que leer, seguire leyendo y conforme tenga mas conocimientos del tema los ire escribiendo aqui.

SQL Profiler: Trace

En el trabajo se esta presentando un problema que al principio no existia, este problema es que se estan generando excepciones de "time-out", para no darle tantas vueltas a las cosas ire al grano. Me comento Carlos Madrigal que podemos utilizar el Trace que trae la herramienta SQL Profiler para poder hacer un rastreo de las excepciones, y ver cuales son los procesos que estan causando estos bloqueos.

Tambien me recomendo un Libro "SQL Server Query Performance Tuning Distilled, Second Edition by Sajal Dam".

Voy a empezar a leerlo y estare escribiendo mis avances.