Problema de SQL Lento

eso es muy cierto, pero este problema me tiene de cabeza, tengo que
dar con el problema como de lugar

"Eladio Rincón" escribió en el mensaje
news:

estos problemas "enganchan" de verdad... luego subes a las tantas a dormir

y

tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!" :-)

lección? por los datos enviados por Carlo, saltaba a la vista que el
servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
siguiente traza que nos pase Carlo... eso si será un reto ;-)

Por cierto, gracias a Carlo por poder conseguir los contadores que le

hemos

pedido porque como sabes, no siempre se puede auditar un servidor como
desearíamos, ¿verdad? ;-)

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"qwalgrande" wrote in message
news:
> Hola.
>
> Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa
hoy.
> Espero que nos lo sigas contando.
>
> Además de los contadores que indicó Eladio, que están orientados a

buscar

> problemas de bloqueos, yo le pondría un par de ellos más, los dos del
mismo
> objeto:
> SQLServer Access Method: Page Split/sec
> SQLServer Access Method: Full Scans/sec
>
> El motivo, intentar elucubrar si hay problemas de indexación sin usar

los

> contadores de disco. Un valor alto en estos contadores puede indicarnos
que
> la indexación no es todo lo buena que debiera. Sería una mala noticia,

ya

> que en un producto cerrado, tocar la indexación puede traerte otros
> contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una

traza

de
> profiler para traernos consultas con muchas lecturas lógicas y/o mucho
> tiempo con ciertas garantías.
>
> (por cierto, Carlo, hemos tenido mucha suerte con la participación de
> Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de
estos
> de rendimiento y contadores siempre acaba dejándome con la boca abierta.
> Eladio, gracias por otra lección más.)
>
> qwalgrande
>
>

Hola.

Yo no le veo nada. Tienes bloqueos, pero muchos. El page Split no es alto
(salvo momentos puntuales) y Full Scan tampoco tiene muchos.

Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que no
vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que no
se reinicie).

Asumiendo que los problemas son de disco, comentaste que haces backup del
log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de log?
¿Tienes separados los datos del log en discos diferentes? ¿Y el backup, lo
haces a los mismos discos o a otros distintos?

qwalgrande

qwalgrande


"Carlo Sorrel" wrote in message
news:%
Estiamdos, el archivo es bastante grande para poder postearlo..., lo estoy
comprimiendo en RAR. Aqui va de nuevo.
"Eladio Rincón" escribió en el mensaje
news:

estos problemas "enganchan" de verdad... luego subes a las tantas a dormir

y

tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!" :-)

lección? por los datos enviados por Carlo, saltaba a la vista que el
servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
siguiente traza que nos pase Carlo... eso si será un reto ;-)

Por cierto, gracias a Carlo por poder conseguir los contadores que le

hemos

pedido porque como sabes, no siempre se puede auditar un servidor como
desearíamos, ¿verdad? ;-)

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"qwalgrande" wrote in message
news:
> Hola.
>
> Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa
hoy.
> Espero que nos lo sigas contando.
>
> Además de los contadores que indicó Eladio, que están orientados a

buscar

> problemas de bloqueos, yo le pondría un par de ellos más, los dos del
mismo
> objeto:
> SQLServer Access Method: Page Split/sec
> SQLServer Access Method: Full Scans/sec
>
> El motivo, intentar elucubrar si hay problemas de indexación sin usar

los

> contadores de disco. Un valor alto en estos contadores puede indicarnos
que
> la indexación no es todo lo buena que debiera. Sería una mala noticia,

ya

> que en un producto cerrado, tocar la indexación puede traerte otros
> contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una

traza

de
> profiler para traernos consultas con muchas lecturas lógicas y/o mucho
> tiempo con ciertas garantías.
>
> (por cierto, Carlo, hemos tenido mucha suerte con la participación de
> Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de
estos
> de rendimiento y contadores siempre acaba dejándome con la boca abierta.
> Eladio, gracias por otra lección más.)
>
> qwalgrande
>
>

No, no los hago a discos, los tiro directamente al sistema de
respaldos...Tivoli Storage Manager de IBM con el TDP de SQL., y
respondiendo a tu otra pregunta, el log esta ólo en un Raid 1 de 33 Gb, la
Tempdb tambien en un Raid 1 de 33 gb..
"qwalgrande" escribió en el mensaje
news:

Hola.

Yo no le veo nada. Tienes bloqueos, pero muchos. El page Split no es alto
(salvo momentos puntuales) y Full Scan tampoco tiene muchos.

Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que no
vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que

no

se reinicie).

Asumiendo que los problemas son de disco, comentaste que haces backup del
log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de

log?

¿Tienes separados los datos del log en discos diferentes? ¿Y el backup, lo
haces a los mismos discos o a otros distintos?

qwalgrande

qwalgrande


"Carlo Sorrel" wrote in message
news:%
Estiamdos, el archivo es bastante grande para poder postearlo..., lo estoy
comprimiendo en RAR. Aqui va de nuevo.
"Eladio Rincón" escribió en el mensaje
news:
> estos problemas "enganchan" de verdad... luego subes a las tantas a

dormir

y
> tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!"

:-)

>
> lección? por los datos enviados por Carlo, saltaba a la vista que el
> servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
> siguiente traza que nos pase Carlo... eso si será un reto ;-)
>
> Por cierto, gracias a Carlo por poder conseguir los contadores que le
hemos
> pedido porque como sabes, no siempre se puede auditar un servidor como
> desearíamos, ¿verdad? ;-)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "qwalgrande" wrote in message
> news:
> > Hola.
> >
> > Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa
> hoy.
> > Espero que nos lo sigas contando.
> >
> > Además de los contadores que indicó Eladio, que están orientados a
buscar
> > problemas de bloqueos, yo le pondría un par de ellos más, los dos del
> mismo
> > objeto:
> > SQLServer Access Method: Page Split/sec
> > SQLServer Access Method: Full Scans/sec
> >
> > El motivo, intentar elucubrar si hay problemas de indexación sin usar
los
> > contadores de disco. Un valor alto en estos contadores puede

indicarnos

> que
> > la indexación no es todo lo buena que debiera. Sería una mala noticia,
ya
> > que en un producto cerrado, tocar la indexación puede traerte otros
> > contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una
traza
> de
> > profiler para traernos consultas con muchas lecturas lógicas y/o mucho
> > tiempo con ciertas garantías.
> >
> > (por cierto, Carlo, hemos tenido mucha suerte con la participación de
> > Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de
> estos
> > de rendimiento y contadores siempre acaba dejándome con la boca

abierta.

> > Eladio, gracias por otra lección más.)
> >
> > qwalgrande
> >
> >
>
>

Hola,

yo he visto algo pero no llego a ver la causa:

Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure cache
pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que el
valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200 MB,
ok?

quitando esa escala de tiempo, si pasamos a la traza completa, tenemos un
máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
está bien.

para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
escala 3000, verás que "valle" hay formado...

otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
fallos de página altísimo: media de 470 fallos de página por segundo y un
máximo de 2613!!! eso indica que en ese momento los disco estaban trabajando
a tope

¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el proceso
de inserción masiva que comentas; deberías poner profiler para ver qué
operaciones llegan al servidor, y si eres capaz de encontrar las más
costosas, creo que estaremos en buen camino...


Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"qwalgrande" wrote in message
news:

Hola.

Yo no le veo nada. Tienes bloqueos, pero muchos. El page Split no es alto
(salvo momentos puntuales) y Full Scan tampoco tiene muchos.

Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que no
vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que

no

se reinicie).

Asumiendo que los problemas son de disco, comentaste que haces backup del
log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de

log?

¿Tienes separados los datos del log en discos diferentes? ¿Y el backup, lo
haces a los mismos discos o a otros distintos?

qwalgrande

qwalgrande


"Carlo Sorrel" wrote in message
news:%
Estiamdos, el archivo es bastante grande para poder postearlo..., lo estoy
comprimiendo en RAR. Aqui va de nuevo.
"Eladio Rincón" escribió en el mensaje
news:
> estos problemas "enganchan" de verdad... luego subes a las tantas a

dormir

y
> tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!"

:-)

>
> lección? por los datos enviados por Carlo, saltaba a la vista que el
> servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
> siguiente traza que nos pase Carlo... eso si será un reto ;-)
>
> Por cierto, gracias a Carlo por poder conseguir los contadores que le
hemos
> pedido porque como sabes, no siempre se puede auditar un servidor como
> desearíamos, ¿verdad? ;-)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "qwalgrande" wrote in message
> news:
> > Hola.
> >
> > Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa
> hoy.
> > Espero que nos lo sigas contando.
> >
> > Además de los contadores que indicó Eladio, que están orientados a
buscar
> > problemas de bloqueos, yo le pondría un par de ellos más, los dos del
> mismo
> > objeto:
> > SQLServer Access Method: Page Split/sec
> > SQLServer Access Method: Full Scans/sec
> >
> > El motivo, intentar elucubrar si hay problemas de indexación sin usar
los
> > contadores de disco. Un valor alto en estos contadores puede

indicarnos

> que
> > la indexación no es todo lo buena que debiera. Sería una mala noticia,
ya
> > que en un producto cerrado, tocar la indexación puede traerte otros
> > contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una
traza
> de
> > profiler para traernos consultas con muchas lecturas lógicas y/o mucho
> > tiempo con ciertas garantías.
> >
> > (por cierto, Carlo, hemos tenido mucha suerte con la participación de
> > Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de
> estos
> > de rendimiento y contadores siempre acaba dejándome con la boca

abierta.

> > Eladio, gracias por otra lección más.)
> >
> > qwalgrande
> >
> >
>
>

Hola.

Lo que no veo es un motivo para la ralentización "en general". Si estamos
hablando de un periodo de 1 minuto que coincide con una hora en punto, es la
típica hora en que se lanzan las cosas gordas, pero tendríamos un problema
de rendimiento puntual, no una sensación de lentitud en general. La verdad,
yo no le saco punta a esto.

Carlo, ¿sería posible que pusieras una traza con profiler para traerte las
consultas que tarden más de 2000 milisegundos? Igual nos encontramos con que
hay alguna consulta que se repite cientos de veces y que habría que tratar
de optimizar al máximo.

qwalgrande


"Eladio Rincón" wrote in message
news:
Hola,

yo he visto algo pero no llego a ver la causa:

Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure cache
pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que el
valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200 MB,
ok?

quitando esa escala de tiempo, si pasamos a la traza completa, tenemos un
máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
está bien.

para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
escala 3000, verás que "valle" hay formado...

otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
fallos de página altísimo: media de 470 fallos de página por segundo y un
máximo de 2613!!! eso indica que en ese momento los disco estaban trabajando
a tope

¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el proceso
de inserción masiva que comentas; deberías poner profiler para ver qué
operaciones llegan al servidor, y si eres capaz de encontrar las más
costosas, creo que estaremos en buen camino...


Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"qwalgrande" wrote in message
news:

Hola.

Yo no le veo nada. Tienes bloqueos, pero muchos. El page Split no es alto
(salvo momentos puntuales) y Full Scan tampoco tiene muchos.

Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que no
vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que

no

se reinicie).

Asumiendo que los problemas son de disco, comentaste que haces backup del
log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de

log?

¿Tienes separados los datos del log en discos diferentes? ¿Y el backup, lo
haces a los mismos discos o a otros distintos?

qwalgrande

qwalgrande


"Carlo Sorrel" wrote in message
news:%
Estiamdos, el archivo es bastante grande para poder postearlo..., lo estoy
comprimiendo en RAR. Aqui va de nuevo.
"Eladio Rincón" escribió en el mensaje
news:
> estos problemas "enganchan" de verdad... luego subes a las tantas a

dormir

y
> tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!"

:-)

>
> lección? por los datos enviados por Carlo, saltaba a la vista que el
> servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
> siguiente traza que nos pase Carlo... eso si será un reto ;-)
>
> Por cierto, gracias a Carlo por poder conseguir los contadores que le
hemos
> pedido porque como sabes, no siempre se puede auditar un servidor como
> desearíamos, ¿verdad? ;-)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "qwalgrande" wrote in message
> news:
> > Hola.
> >
> > Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa
> hoy.
> > Espero que nos lo sigas contando.
> >
> > Además de los contadores que indicó Eladio, que están orientados a
buscar
> > problemas de bloqueos, yo le pondría un par de ellos más, los dos del
> mismo
> > objeto:
> > SQLServer Access Method: Page Split/sec
> > SQLServer Access Method: Full Scans/sec
> >
> > El motivo, intentar elucubrar si hay problemas de indexación sin usar
los
> > contadores de disco. Un valor alto en estos contadores puede

indicarnos

> que
> > la indexación no es todo lo buena que debiera. Sería una mala noticia,
ya
> > que en un producto cerrado, tocar la indexación puede traerte otros
> > contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una
traza
> de
> > profiler para traernos consultas con muchas lecturas lógicas y/o mucho
> > tiempo con ciertas garantías.
> >
> > (por cierto, Carlo, hemos tenido mucha suerte con la participación de
> > Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de
> estos
> > de rendimiento y contadores siempre acaba dejándome con la boca

abierta.

> > Eladio, gracias por otra lección más.)
> >
> > qwalgrande
> >
> >
>
>