SP_WHO2 - Estudiando Lentitud en Sql Server

Amigos,

Hay tres análisis básicos que pueden ayudarnos a la hora de estudiar un degradamiento general de nuestra Base de Datos.

A) Estudiar Posibles Bloqueos

B) Analizar Valores Altos de I/O y CPU

C) Relevar Múltiples Procesos con un  mismo SPID, (el spid es el nº que el sql server le da a cada proceso corriendo en el servidor)

  
Para estudiar estos tres puntos vitales de nuestro sistema mi arma favorita es el sp_who2

Este sp muestra todas las sesiones que están actualmente establecidas en el servidor.

La sentencia es sumamente sencilla:

EXEC sp_who2

El resultado ha obtener será el siguiente:



 Los primeros 50 SPID están reservados para procesos del sistema que generalmente no merecen nuestra atención, ya que no suelen ser el origen de la degrdación de la performance del server.

 Ahora los puntos que SI debemos tener en cuenta

 1) Bloqueos

     Existe una columna llamada BlkBy la cual nos informa el SPID que está bloqueando al proceso de la fila que estemos observando.

     Antes de "matar al proceso"  con el comando KILL + SPID,  podemos saber en que consiste el proceso  que está bloqueado. Cómo? Pues simplemente utilizando la sentencia DBCC Inputbuffer (SPID).

      Puede ocurrir que varios procesos estén bloqueados por el mismo SPID, en ese caso conviene estudiar en profundidad el proceso bloqueante


  2) Altos Valores de INPUT/OUPUT y/o CPU
   
    Para esto disponemos de dos columnas "CPUTime" y "DiskIO". Los procesos que demanden mucha lectura/escritura en disco y/ o CPU merecen ser analizados en detalle. Pueden hacerse mejoras de distinto tipo para evitar esta utilización excesiva de los recursos del sistema. (Recomiendo puntualmente analizar en detalle los planes de ejecución para determinar los pasos a seguir)


 3) Procesos Paralelos

    Cuando observamos varias filas destinadas a un mismo SPID tenemos que saber que es una acción que toma el SQL SERVER al estimar que le llevará un largo tiempo resolver el proceso. Cuando esto ocurre el sql server "tira" multiples hilos para el mismo proceso pudiendo tener esto consecuencias muy malas en términos de performance del server.
Una vez más, estudiemos el proceso "responsable" y tratemos de mejorarlo. De ser imposible podemos disminuir el máximo número de procesadores que el paralelismo puede usar. Esto se hace a nivel de servidor (MAXDOP).


 Amigos, eso es todo, espero que el artículo sea de utilidad.

 Saludos.
  
 Otro Post Recomendado por el Autor

 "Mantenimiento de Estadísticas Para una Performance Optima de nuestra BD"

 https://www.blogger.com/blogger.g?blogID=4841087034568585749#editor/target=post;postID=5281491474180357583;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname

Script Para Consultar el Historial de Ejecución de un Job

Amigos,

    Cuantas veces han tratado de ver el historial de ejecución de un job por consola haciendo botón derecho sobre el job y "view history" y se han encontrado con el molesto cartelito de "Time Out Expired", quedando vuestras manos vacías?

     Estoy seguro que muchas veces... Ppor ejemplo en ocasión del fallo de un Job ante la necesidad de conocer  el mensaje del error del job....

     Pues bien, les traigo un script super práctico que les permitirá saber, no solo el motivo en caso de un error o simplemente el detalle de lo ejecutado en caso de un job exitoso, sino también la duración en la ejecución del job y el resultado final de mismo.

     Entonces.. tengan a mano este script también cuando sospechen que un job "esta tardando en ejecutarse más que hace xx tiempo" . Con este script prontamente podrán evacuar esa duda.

     Con uds el script, solo seteen el run_date para limitar la fecha para la cual quieren la data.

     Cualquier duda como siempre quedo a disposición, saludos!!

 ----------------------------------------------------------------------

-- Detalle: Estudia La Historia de Ejecución de un Job A Partir de una Fecha

-- Tip: Utiliza la tablas msdb SysJobHistory/SysJobs    

-----------------------------------------------------------------------

 use msdb

 select

 step_id,

 message,

 run_date,

 case

   len(run_duration) when  6 then left(convert(varchar(6), run_duration),2)+':'+substring(convert(varchar(6), run_duration),3,2)+':'+right(convert(varchar(6),run_duration),2)

                     when  5 then '0'+left(convert(varchar(5), run_duration),1)+':'+substring(convert(varchar(5), run_duration),2,2)+':'+right(convert(varchar(6),run_duration),2)   

                     when  4 then '00'+':'+left(convert(varchar(4),run_duration),2)+':'+right(convert(varchar(4),run_duration),2)

                     when  3 then '00:0'+left(convert(varchar(3),run_duration),1)+':'+right(convert(varchar(4),run_duration),2)     

        end       

         as 'run_duration',

 case run_status when 0 then 'failed'

                  when  1 then 'succeded'

                  when 2 then 'retry'

                  when 3 then 'canceled'

                 end as 'run_status'

 from

 SysJobHistory as a

 --

 left join SysJobs  as b

 on a.job_id = b.job_id

 --

where

b.name = 'DBA - Indexes Optimize - Arcalltv - Miercoles 6 AM' and

run_date > 20130902

order by run_date

Script Para Determinar Nivel de Fragmentación de Indices

Que tal amigos, una vez más con uds. esta vez para acercarles un script útil, para tener a mano a la hora de echar un vistazo a los niveles de fragmentación de nuestros idx.
Les recomiendo antes que nada leer en mi blog el white paper relacionado con el tema.

Hoy nada de teoría, simplemente dejarles el script aclarandoles lo siguiente:

- El script puede ser utilizado para medir la fragmetnación a nivel de Servidor/Base de Datos/Tablas (por default se los dejo "comentado (--)" para que lo puedan utilizar a nivel de Base de Datos

- En el where pueden filtrar el nivel de fragmentación que desean listar.

Quedo a disposición de uds. Saludos!

-----------------------------------------------------------------------------

-- Detalle: Se listan lo objetos que se encuentran fragmentados

-- acorde a lo seteado en el wheare    

-- Detalle 2 (podemos hacer a nivel de Servidor/ Base de Datos / Tabla)                          

-- Autor: GH - Octubre 2013                                                                      

-- --------------------------------------------------------------------------

SELECT

db.name as 'Database',

o.name as 'Table',

case when I.name is null then 'Heap' else I.name end as 'Indice',

left(avg_fragmentation_in_percent,4) as '% frag'

--FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL, NULL, NULL) AS a   

FROM sys.dm_db_index_physical_stats (DB_ID('NOMBRE BASE DE DATOS'), NULL, NULL, NULL, NULL) AS a  

--FROM sys.dm_db_index_physical_stats (DB_ID('NOMBRE BASE DE DATOS'), OBJECT_ID('NOMBRE DE TABLA'), NULL, NULL, NULL) AS a  

-- left para obtener nombre db --

LEFT JOIN Sys.Databases as DB    

on A.Database_Id = DB.Database_Id

-- left para obtener nombre del idx --

LEFT JOIN sys.indexes AS I

ON

a.object_id = I.object_id AND

a.index_id = I.index_id

-- left para obtener nombre tabla --

LEFT JOIN sys.objects as o

on I.[object_id] = o.[object_id]

----------------

WHERE avg_fragmentation_in_percent > 20 -- % de fragmentación en este caso > 20

and index_level = 0 --> analizando la rama principal de los índices

and page_count > 1000 --> mas de 1000 hojas

order by

o.name